Xamarin migration: .NET for iOS, .NET for Android and .NET MAUI
Xamarin support ended on 1 May 2024 for all Xamarin SDKs, including Xamarin.Forms. Every Xamarin app still in production now has a destination it has to reach — but not the same one. Xamarin.Forms apps go to .NET MAUI. Xamarin.iOS and Xamarin.Android apps go to .NET for iOS and .NET for Android. Most providers only talk about the first path. We run both, and we start by telling you which one you are on.
Choose the path
Which migration path is yours?
It depends on how your app renders its UI. If you built shared UI in XAML with Xamarin.Forms, your destination is .NET MAUI. If you built separate iOS and Android UI against the platform SDKs with Xamarin.iOS and Xamarin.Android, your destination is .NET for iOS and .NET for Android — a different migration with different risks.
| Your current stack | Destination | What it involves |
|---|---|---|
| Xamarin.Forms | .NET MAUI | Shared XAML and code move across. The work concentrates in custom renderers, third-party controls and NuGet packages with no supported successor. |
| Xamarin.iOS | .NET for iOS | Project system and build tooling change; your platform-specific C# and business logic largely stay. Toolchain and dependency work dominates. |
| Xamarin.Android | .NET for Android | Same shape as iOS: SDK-style project migration, binding libraries and build pipeline rather than a UI rewrite. |
| Any of the above | Flutter | Only when a rewrite genuinely beats a migration — a UI that needs replacing anyway, or a team already moving to Dart. We say so when it is the honest answer. |
The terms, defined
- Xamarin.Native
- Xamarin.Native is the collective name for Xamarin.iOS and Xamarin.Android — Xamarin projects that build a separate user interface per platform against the native SDKs in C#, rather than sharing one cross-platform UI.
- Xamarin.Forms
- Xamarin.Forms is the Xamarin UI framework that renders a single XAML user interface on both iOS and Android through platform-specific renderers. Its supported successor is .NET MAUI.
- .NET for iOS
- .NET for iOS is the supported successor to Xamarin.iOS: the same C# bindings to Apple’s native APIs, delivered as a workload of modern .NET with SDK-style projects and current Xcode toolchain support.
- .NET for Android
- .NET for Android is the supported successor to Xamarin.Android: C# bindings to the Android SDK delivered as a modern .NET workload, with SDK-style projects and current Android API-level support.
- .NET MAUI
- .NET MAUI (Multi-platform App UI) is Microsoft’s cross-platform UI framework and the supported successor to Xamarin.Forms, targeting iOS, Android, macOS and Windows from one codebase.
- Custom renderer
- A custom renderer is Xamarin.Forms code that overrides how a shared control is drawn on a specific platform. .NET MAUI replaces the pattern with handlers, which is why custom renderers are the usual source of unplanned cost in a Forms migration.
Do we have to rewrite the app from scratch?
No. In the great majority of cases the business logic, data layer, service integrations and platform-specific code carry over. A Xamarin migration is a project-system and dependency migration, not a blank-page rewrite. Where the code does need replacing — most often custom renderers and abandoned third-party controls — we identify it in the audit before any work starts, so it is a budgeted line item rather than a surprise.
The exception is honest to name: if the app's UI was already due for replacement, or the codebase has degraded past the point where preserving it is a saving, a rewrite can be the cheaper option. That is a finding of the audit, not a default position.
Can we keep shipping features while the migration runs?
Yes — that is how we structure it. The migration runs in stages, module by module, with a buildable, releasable app at the end of each stage. We do not ask for a multi-month feature freeze, because in practice nobody can hold one: support issues and commitments do not pause for a re-platforming project.
- ✓ A migration branch that merges back on a regular cadence, not one long-lived fork
- ✓ Release-critical paths covered by regression tests before the module they touch is migrated
- ✓ Store compliance kept green at every stage, not restored at the end
- ✓ A clear rollback position at each stage boundary
Start here
What happens first: the readiness audit
Before quoting a migration, we run a fixed-scope readiness audit and give you a written recommendation — migrate, rewrite, or controlled freeze — with an effort range you can take to a budget conversation. If you then run the migration with us, the audit folds into it.
- 01
Dependency and package inventory
Every NuGet package and third-party SDK classified: has a supported successor, needs replacing, or has no path and must be built. This is where migration estimates usually go wrong.
- 02
Platform-code and custom-renderer inventory
For Forms apps, every custom renderer and effect mapped to its MAUI handler equivalent. For Native apps, the platform-specific surface that has to be revalidated against the new project system.
- 03
Build, signing and CI/CD assessment
Pipelines, signing identities, provisioning, and what breaks when the project format changes. Azure DevOps, Bitrise, GitHub Actions or whatever you run today.
- 04
Store compliance check
Current submission requirements against your current toolchain, and how much runway you actually have.
- 05
Written recommendation
The path, the sequence, the risk register, and an effort range — in a document your CTO can read and your CFO can act on.
What happens if we do nothing?
The app keeps running, but it stops being updatable. Xamarin left support on 1 May 2024, which means no fixes, no updates and no technical assistance from Microsoft. The pressure does not come from Microsoft, though — it comes from the app stores.
Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later, using the iOS 26 SDK or later. Google Play enforces its own rolling target-API requirement on the same principle. An unsupported SDK that no longer ships toolchain updates eventually cannot produce a build the stores will accept — and at that point you have not lost features, you have lost the ability to ship a security fix.
The practical consequence: the decision has a deadline set by Apple and Google, not by you. Teams that start with an audit while they still have runway get to choose their path. Teams that start after a rejected submission do not.
Sources: Microsoft Xamarin support policy, Apple upcoming requirements, and Google Play target API level requirements — the store levels rise on a schedule, so check the current requirement before you plan a submission.
Track record
Why MaboaSoft for this
Because we have run the Native path, not just the Forms one. Our public reference on this work is a six-year dedicated engagement with a North American enterprise SaaS vendor covering five production cross-platform apps on iOS and Android, built on Xamarin.Native, .NET for iOS, .NET for Android, .NET MAUI, C# and MvvmCross.
That matters because the two migrations are not interchangeable. Xamarin.Forms → .NET MAUI is a crowded offering; almost every .NET consultancy sells it. Xamarin.iOS and Xamarin.Android → .NET for iOS and .NET for Android is a narrower, harder problem with far fewer providers who have actually shipped it.
We also build new products in Flutter — which is why we can tell you when a rewrite beats a migration without it costing us the project.
Read the enterprise engagement case studyCapabilities relevant to this work
Read further
- Xamarin.Forms or Xamarin.Native? Which migration you are actually facing
- Xamarin.Native to .NET for iOS and .NET for Android: the migration nobody writes about
- The Xamarin to .NET MAUI migration readiness checklist (with runnable commands)
- What a Xamarin to .NET MAUI migration actually costs
- Still on Xamarin in 2026? Your four realistic options
- MvvmCross in 2026: what happens to apps built on it
FAQ
Frequently asked questions
What is the difference between Xamarin.Forms and Xamarin.Native migration?
Xamarin.Forms shares one XAML UI across platforms and migrates to .NET MAUI. Xamarin.Native (Xamarin.iOS and Xamarin.Android) builds separate platform UIs and migrates to .NET for iOS and .NET for Android. The Forms path is mostly UI-layer work concentrated in custom renderers; the Native path is mostly project-system, dependency and build-pipeline work. Different risks, different effort profiles, different specialists.
Do we have to rewrite the app from scratch?
Usually not. Business logic, data access and platform-specific code carry over in most projects. The work concentrates in dependencies without supported successors and in custom renderers. A rewrite only makes sense when the UI needed replacing anyway — which the readiness audit establishes before any budget is committed.
Can we keep releasing features during the migration?
Yes. We migrate module by module with a releasable app at every stage boundary, rather than asking for a feature freeze that nobody can actually hold.
How long does a Xamarin migration take?
It depends on dependency count, custom-renderer count and test coverage far more than on lines of code — which is why we do not quote a duration before the audit. The audit itself is fixed-scope and produces an effort range you can budget against.
What happens if we do nothing?
The app keeps running but gradually loses the ability to be updated. Xamarin left support on 1 May 2024, and app-store SDK requirements tighten on a schedule you do not control — Apple has required Xcode 26 and the iOS 26 SDK for App Store Connect uploads since 28 April 2026. Eventually a security fix cannot be shipped.
When does Flutter make more sense than .NET MAUI?
When the UI is being replaced regardless, when the team is already moving toward Dart, or when the app is small enough that a rewrite costs less than untangling years of platform-specific workarounds. When none of those apply, migrating within the .NET ecosystem is almost always cheaper and lower-risk.
Do you work with our existing team, or take the whole project?
Both. We run migrations end-to-end, and we also embed alongside an in-house team that owns the product and needs the migration expertise it does not have on staff.
Next step
Start with the audit, not the estimate
A fixed-scope readiness audit tells you which path you are on, what it will take, and whether migrating is even the right call — before anyone commits a budget.