Xamarin End of Support: Migration Options

Xamarin end of support arrived on May 1, 2024. Microsoft’s Xamarin support policy confirms the date and names the successors: Xamarin.Forms apps move to .NET MAUI, and Xamarin.iOS and Xamarin.Android apps move to .NET for iOS and .NET for Android. More than two years later, plenty of Xamarin apps are still in production, still earning money, and getting harder to release every quarter.

If you own one of them, the question is not whether to move but where to, and how to do it without freezing the roadmap. This post lays out the realistic options (.NET MAUI, native .NET, Flutter, React Native, Kotlin Multiplatform or fully native), what each costs in effort, and how to choose. When you want a team to run the move, our Xamarin migration services page explains how we approach it, and it sits within our broader cross-platform app development work.

Your app does not stop working on May 2, 2024 or on any later date. Installed copies keep running. What changed is that Microsoft no longer ships fixes, security patches or tooling updates for Xamarin, so every external change now lands on you.

Those external changes are relentless. Since April 28, 2026, Apple requires App Store uploads to be built with Xcode 26 or later against the iOS 26 SDK. From August 31, 2026, Google Play requires new apps and updates to target Android 16 (API level 36). An unsupported toolchain will not be updated to meet requirements like these, which means that, sooner or later, a Xamarin app reaches a release it simply cannot ship. Usually that happens when you most need a fix out.

Third-party libraries add to the squeeze. NuGet packages, payment SDKs and analytics tools drop Xamarin builds over time, so even if you can still compile, you end up pinned to old, unpatched versions. That is a security problem as well as a maintenance one.

For Xamarin.Forms apps, .NET MAUI is the path of least change. You keep C#, XAML, your view models and most business logic. Microsoft’s migration guide is clear on the shape of the work: projects must be converted to the SDK-style format, but the app does not need a rewrite, and multi-project solutions do not need to become a single project. Native dependencies move to .NET 8 or later. The .NET Upgrade Assistant helps with multi-project Xamarin.Forms apps, though Microsoft says manual work remains in most cases.

Expect the manual work in three places: custom renderers (which become handlers), third-party controls and plugins that need MAUI equivalents, and platform-specific code. Apps with heavy custom rendering take noticeably longer than apps built from standard controls.

Two exceptions to know early: Xamarin.watchOS and iOS OpenGL cannot be upgraded. If your app has an Apple Watch extension or OpenGL rendering on iOS, those parts need rebuilding with different technology regardless of where the rest goes.

Then factor in MAUI’s own cadence. Per Microsoft’s .NET MAUI support policy, MAUI ships with each .NET release, and a major version is supported for at least six months after its successor ships. MAUI 10 (released November 11, 2025) is supported until May 11, 2027, and MAUI 9 went out of support on May 12, 2026. Choosing MAUI means committing to a yearly upgrade rhythm. If Flutter is also on your shortlist, our .NET MAUI vs Flutter comparison sets the two side by side. See our .NET MAUI app development page for how we handle it.

If your app was built with Xamarin.iOS and Xamarin.Android (the “traditional” Xamarin, with native UI per platform) rather than Xamarin.Forms, the direct successors are .NET for iOS and .NET for Android. You keep the native UI approach and your shared C# logic, and the work is mostly project conversion, dependency updates and API changes.

This is often the cheapest move for traditional Xamarin apps, because nothing about the architecture changes. It also keeps you tied to the .NET release cycle. .NET 10 is an LTS release supported until November 14, 2028, while .NET 8 and .NET 9 both reach end of support on November 10, 2026, according to the .NET support policy. If you migrate now, target .NET 10, not 8 or 9.

Sometimes the end of Xamarin is the moment to reconsider the stack. This is a rewrite, not a migration, so it only makes sense when there is a strong reason beyond “MAUI is new”.

Flutter suits teams that want one UI codebase with strong design control and are willing to move from C# to Dart. React Native suits organisations with a strong TypeScript and web team. Kotlin Multiplatform suits Android-led teams who want shared logic with native or shared UI. Fully native Swift and Kotlin suits apps that live close to the OS, such as wearables, heavy media or deep hardware integration.

Good reasons to switch: the app is due a full redesign anyway, the C# team has left and you are hiring fresh, the Xamarin codebase is in poor shape, or your product needs native capabilities MAUI handles awkwardly. Bad reasons: a framework trend, or an estimate that ignores how much business logic you would rewrite.

Start with an audit, not an opinion. In one to two weeks you can answer the questions that decide the route: Is this Xamarin.Forms or traditional Xamarin? How many custom renderers and platform-specific services are there? Which NuGet packages and native SDKs does it depend on, and do they have .NET 8+ or MAUI builds? Is there test coverage you can lean on? How healthy is the code?

A rough rule from those answers: if the code is reasonably clean and most dependencies have successors, migrate to MAUI or native .NET. If the code is fragile, dependencies are abandoned and a redesign is on the roadmap anyway, a rewrite on a new framework can cost less over three years than migrating and then fixing.

Do not forget the backend. Many Xamarin apps sit on older ASP.NET APIs that need attention at the same time. Our legacy app modernization work often covers both sides together.

• Migrating and redesigning at once. Change the platform, then change the UI. Doing both doubles the variables when something breaks.
• Targeting .NET 8 or 9. Both reach end of support on November 10, 2026. Go straight to .NET 10 LTS.
• Ignoring the Watch app. Xamarin.watchOS cannot be upgraded, so a watch extension is new work. Scope it separately.
• No baseline tests. Without them, nobody can prove the new build behaves like the old one, and QA becomes guesswork.
• Losing control of store accounts and signing keys. Make sure your company owns the Apple and Google accounts and the keystore before any vendor starts work. Our guide on protecting your app idea and IP when outsourcing covers the essentials.