.NET MAUI vs React Native: Choosing a Xamarin Migration Target

Start here: the decision in one table

Most of this guide is nuance. This table is the summary, and for a large number of teams it is sufficient.

The support lifecycle nobody reads

This is the factor most comparisons omit, and it changes budgets.

.NET MAUI is not supported like .NET

It is easy to assume that because .NET 10 is a Long Term Support release, a .NET MAUI 10 app is good until November 2028. It is not.

Microsoft’s .NET MAUI support policy states that a major version of .NET MAUI receives support for a minimum of six months after its successor ships. .NET MAUI 10 shipped on 11 November 2025. Its end of support is 11 May 2027, roughly eighteen months later, while the .NET 10 runtime underneath it runs to November 2028.

Microsoft is explicit about why: .NET MAUI ships as a workload that depends on external moving parts such as Xcode and the Android SDK tools, and those cannot be frozen for three years. The policy also requires you to be on the latest servicing update to receive technical support at all.

The practical consequence is straightforward. Choosing .NET MAUI means committing to a major framework upgrade roughly every twelve months, indefinitely. That is not a reason to avoid it, but it must be in the maintenance budget rather than discovered in year two.

React Native’s cadence is faster, and more honest about it

React Native does not pretend to offer long-term support. The React Native releases support policy maintains the latest stable version plus the previous two minor versions, moving older ones through an “end of cycle” stage to unsupported.

Minor releases arrive several times a year, so in practice you are upgrading more often than annual, in smaller increments. Teams often find frequent small upgrades less disruptive than an annual large one, but it is continuous work either way.

Neither framework lets you build a mobile app and leave it alone for three years. Any vendor or internal plan that assumes otherwise is wrong about both options, and mobile platform requirements from Apple and Google would force movement regardless.

What actually carries over from Xamarin

The migration-cost argument for .NET MAUI is real, but narrower than it is usually presented.

From Xamarin.Forms to .NET MAUI

This is the case where MAUI earns its reputation. Genuinely reusable:

• Business logic and services. C# is C#. Models, validation, API clients, and services move with minimal change.
• XAML pages. Namespaces change and some control APIs differ, but the structure survives.
• MVVM view models. Data binding concepts are unchanged.
• NuGet packages, where a MAUI-compatible successor exists, such as CommunityToolkit.Maui in place of Xamarin.CommunityToolkit.

What does not carry over cleanly:

• Custom renderers. These must be rewritten as handlers, which is a different architecture rather than a rename. This is the single biggest driver of migration cost, and it scales with renderer count, not screen count.
• Platform-specific effects and behaviours, which need reworking against the handler model.
• Anything depending on a package with no MAUI successor, which needs replacing or writing.

Our Xamarin to .NET MAUI migration guide covers the phased mechanics of this in detail, including a renderer count to effort mapping.

From Xamarin.Native to anything

Here the MAUI advantage largely evaporates, and this is where teams make expensive assumptions.

A Xamarin.Native app has separate iOS and Android UI code written against the platform APIs. There is no shared XAML layer, because that was the thing Xamarin.Forms added. Moving to .NET MAUI therefore means writing the shared UI layer for the first time, not migrating one.

Your C# business logic still moves across, which is not nothing. But if the UI is being rebuilt regardless, the decision should be made on team skills, hiring, and ecosystem rather than on a migration-cost advantage that does not exist in this case.

From PhoneGap or Cordova to anything

If you are on PhoneGap or Cordova, the decision is largely made for you.

These are JavaScript applications rendering through a WebView. There is no migration path to .NET MAUI in any meaningful sense, because nothing is shared: not the language, not the rendering model, not the project structure. Choosing MAUI here means writing a new application in a language your team may not use.

React Native is the realistic option of the two. It is still a rebuild of the user interface, because moving from a WebView to native components is a change of rendering model rather than a port. But the language carries over, your business logic is translatable rather than discarded, and your developers keep their existing JavaScript and TypeScript skills.

Adobe discontinued PhoneGap in 2020, so this is not a decision worth deferring further. See our Xamarin and PhoneGap migration playbook for the estate-level view.

From React Native’s side

Nothing carries over. The UI layer is a rebuild because the rendering models are fundamentally different, and the language changes from C# to TypeScript.

Business logic is translatable rather than portable. Data models, validation rules, and API clients convert reasonably well, and this is one of the tasks where AI-assisted development genuinely earns its place. The UI needs human judgement, because a good React component tree is not a transliteration of a XAML page.

Where each one is genuinely better

.NET MAUI advantages

• One language across the stack. If your backend is ASP.NET Core, sharing C# models and validation between server and app is a real, ongoing saving, not just a migration convenience.
• Existing team productivity. A C# team is productive on day one rather than week four.
• Windows as a first-class target. MAUI targets Windows natively. If a desktop client is in scope, this is a significant advantage.
• Direct Microsoft alignment. For organisations already deep in the Microsoft stack, procurement, support, and tooling all sit in one place.
• Single-project structure. The .NET MAUI project model is genuinely simpler than the Xamarin.Forms multi-project layout.

React Native advantages

• Hiring pool. This is the one that compounds. React developers are far more numerous than MAUI developers, and React skills transfer from your web team.
• Third-party SDK ecosystem. Payment providers, analytics vendors, mapping, and customer support tools generally ship a React Native SDK first and a MAUI one later, if at all. If your app depends on vendor SDKs, check their MAUI support before committing.
• Shared skills with web. A team that builds both a web app and a mobile app in React shares patterns, libraries, and people.
• Over-the-air updates. Expo’s update tooling lets you ship JavaScript-layer fixes without an app store review cycle. There is no clean MAUI equivalent, and for a consumer app this changes incident response.
• Maturity of the New Architecture. The Fabric renderer and TurboModules became the default in React Native 0.76, having been available to opt into since 0.68 in March 2022. The serialised bridge that caused most historical performance complaints is no longer on the default path.

Where each one hurts

Honest weaknesses matter more than feature lists when you are living with the decision for five years.

.NET MAUI weaknesses

• Smaller community. Fewer Stack Overflow answers, fewer blog posts, fewer worked examples. When you hit an obscure platform bug, you are more often first.
• Third-party SDK gaps. Covered above, and worth repeating because it is the most common late-stage surprise.
• Annual upgrade commitment. Covered above.
• Hiring. A smaller candidate pool, and one that overlaps heavily with general .NET hiring rather than expanding it.

React Native weaknesses

• The language change is a real cost. Two to four weeks per developer to basic productivity is a reasonable planning figure, and confident autonomy takes longer.
• Dependency churn. The JavaScript ecosystem moves fast, and a React Native project accumulates more third-party dependencies than a MAUI one. That is more supply-chain surface to keep patched.
• Native modules still need native skills. When you need something outside the ecosystem, someone writes Swift or Kotlin. React Native does not remove that requirement, it defers it.
• Windows and desktop are weaker. React Native for Windows exists but is a separate, smaller effort than the mobile targets.

On performance, briefly

Performance is the factor teams ask about first and the one that should influence the decision least.

Both frameworks are fast enough for business applications. .NET MAUI compiles ahead of time to native code, which gives it an advantage in CPU-bound work. React Native’s New Architecture removed the serialised bridge that generated most of the historical criticism, and the remaining gap on typical workloads is not something users notice in a forms-and-lists application.

Two situations are exceptions worth taking seriously:

• Heavy on-device computation, such as image processing, real-time graphics, or large local datasets. Here the ahead-of-time compilation advantage is real.
• Complex animated list rendering, where both frameworks can struggle and the answer depends heavily on implementation quality rather than framework choice.

If you have a genuinely performance-critical requirement, prototype the specific hard part on both. A two-week spike answers the question for your workload better than any published benchmark, which will have been run on a different app than yours.

What about Flutter?

Flutter is a credible framework, and it is the wrong answer for most Xamarin migrations.

The reason is not technical quality. It is that Flutter shares nothing with the stack you already have. Dart is used almost exclusively within the Flutter ecosystem, so neither your C# developers nor any web developers transfer their language skills, and none of your business logic carries over. You would be adding a third language to your organisation to solve a problem that two frameworks you can already staff will solve.

Consider it if you are starting genuinely fresh, have no existing .NET or JavaScript investment, and value its rendering consistency across platforms. For a team leaving Xamarin, that describes almost nobody.

The factor that usually decides it

After the assessments are done, most of these decisions come down to one question: which of these can you still staff in three years?

Framework benchmarks change. Rendering performance differences on modern hardware rarely determine whether a business app succeeds. What determines it is whether, in 2029, you can hire someone to fix a production issue without a three-month search.

That question has different answers for different organisations. A Microsoft-partner consultancy with twelve C# developers and a Microsoft-heavy client base should probably choose .NET MAUI. A product company with a React web app and a shared front-end platform team should probably choose React Native. Both answers are correct, and they are correct for reasons that have nothing to do with the frameworks.

Be sceptical of any recommendation that arrives before someone has asked about your team.

How to decide, in order

1. Establish what you are actually migrating. Xamarin.Forms or Xamarin.Native. This single fact changes the cost model more than anything else, and a surprising number of teams are unsure.
2. Count your custom renderers. This is the concrete migration-cost driver for the MAUI path. Under five is straightforward. Over thirty and you should be pricing a rebuild against a migration honestly.
3. Audit your third-party SDK dependencies. For each one, check whether a supported .NET MAUI package exists today. Not a community port, not an open issue, a supported release. This kills more MAUI plans late than any other factor.
4. Look at your team as it will be, not as it is. Who maintains this in three years, and can you hire them?
5. Put the upgrade cadence in the budget. An annual MAUI major upgrade, or continuous smaller React Native upgrades. Whichever you choose, it is a line item.
6. Check the desktop requirement. If Windows is genuinely in scope, this may settle it on its own.

If the answer is still not obvious after those six, it is genuinely close, and you should pick the one your team is more enthusiastic about. Enthusiasm is a real maintainability factor and is routinely ignored.

Where to go next

• If you have settled on MAUI: Xamarin to .NET MAUI migration guide
• If you have settled on React Native: Migrating from Xamarin or PhoneGap to React Native
• If your estate is broader than one app: Xamarin and PhoneGap mobile migration playbook
• If you are not sure a rebuild is warranted at all: Modernise, rebuild, or replace legacy systems

For an assessment of your existing Xamarin estate and a costed recommendation, see our legacy modernisation service or book a consultation.