Smartware DesignSoftware consulting · est. 2011

Xamarin end-of-life: your migration options

By Michael Barton ·

If your company still ships a Xamarin app, you are running on a framework Microsoft stopped supporting more than two years ago. The app probably still works. That is why this keeps getting pushed down the list, and why it is now getting expensive to ignore.

I have built production apps in Xamarin (emergency-response software that talked to barcode scanners and medical devices), alongside native Swift and Kotlin. Here is how I help clients think through the move.

The short answer

  • Xamarin is finished. Microsoft ended support for all Xamarin SDKs, including Xamarin.Forms, on May 1, 2024.
  • Your realistic options are an in-place upgrade to .NET (keeping native screens), a move from Xamarin.Forms to .NET MAUI, a native rewrite in Swift and Kotlin, or a rewrite in another cross-platform framework.
  • Whatever you pick, target .NET 10 and MAUI 10, not 8 or 9. The older versions are already out of support.
  • The best first step is a short assessment of what your app actually depends on, before anyone picks a framework.

What “end of life” actually means

Microsoft defines it plainly: end of support is “the date when Microsoft no longer provides fixes, updates, or online technical assistance.” The last supported releases were Xamarin.Forms 5.0, Xamarin.Android 13 and Xamarin.iOS 16, all ending on May 1, 2024.

Microsoft also retired Visual Studio for Mac, the IDE a lot of Xamarin teams worked in, on August 31, 2024.

Your installed app does not stop working. What stops is everything around it: security fixes, compatibility with new operating systems, and a supported toolchain for your developers.

Why it is urgent now

The real pressure comes from Apple and Google, who keep raising the bar for what they will accept.

Xamarin.Android 13 and Xamarin.iOS 16 are several operating-system generations behind both. Microsoft ships no updates to build against newer SDKs, so keeping a Xamarin app releasable means relying on unsupported workarounds. Even if you find one today, it can break with the next Xcode or Android release, and you would have nobody to call.

One more date worth knowing: .NET 8 and .NET 9 reach end of support on November 10, 2026. Microsoft recommends .NET 10, which is supported through November 2028.

Your options

Option What you keep Effort Best when
1. Upgrade in place to .NET for iOS / Android Your native Xamarin.iOS and Xamarin.Android screens and C# code Lower You have separate native UIs and want the quickest route to a supported toolchain
2. Xamarin.Forms to .NET MAUI Most of your C# logic, view models and XAML structure Medium to high You have a healthy Forms codebase and a C# team
3. Rewrite native (Swift/SwiftUI, Kotlin/Compose) Your backend, API contracts and product design High The app depends heavily on device hardware, or it is a long-term core product
4. Rewrite in Flutter or React Native Your backend, API contracts and product design High Your team is moving off C# and you want one codebase

Effort is my own judgment, not a benchmark. It depends on your code far more than on the option.

Option 1: upgrade in place to .NET

This is the most overlooked path. Microsoft’s upgrade guide says Xamarin.Android, Xamarin.iOS and Xamarin.Mac projects can be upgraded to .NET, and that “projects don’t need to be rewritten.” Each project does have to become SDK-style first, and your dependencies need to be updated to match.

If your app is mostly native screens with a shared C# core, this gets you onto a supported runtime and current SDKs without redesigning anything.

Option 2: Xamarin.Forms to .NET MAUI

.NET MAUI is Microsoft’s official successor to Xamarin.Forms, and for a healthy Forms app it is the natural destination. It is not a version bump, though. Expect real work in these places:

  • Project structure. Projects become SDK-style, and you can move to a single-project layout.
  • Custom renderers. These need to be reworked to MAUI’s handler model.
  • Third-party libraries and UI controls. Every package needs a maintained .NET version. This is where most surprises show up.
  • Native binding libraries. Android and iOS binding projects have their own migration steps.
  • Unsupported features. Microsoft’s guide lists Xamarin.watchOS as not upgradable, and OpenGL on iOS as removed.

About the tooling: you will find older advice recommending the .NET Upgrade Assistant. Microsoft has since officially deprecated it in favor of the GitHub Copilot modernization agent in Visual Studio 2026. Its Xamarin.Forms XAML transformation only covers namespaces. Automated tools remove some drudgery, but they do not finish the job. Plan for developer time and thorough testing.

About the version: MAUI 8 stopped receiving support in May 2025 and MAUI 9 in May 2026. MAUI 10 is supported until May 11, 2027. MAUI has a shorter support window than .NET itself, so expect to upgrade about once a year even after you arrive.

Option 3: rewrite native

Going native means Swift and SwiftUI for iOS and Kotlin and Jetpack Compose for Android. It costs more up front because you are building two apps, but it removes a framework dependency and gives you first-day access to every new OS feature. I recommend it for hardware-heavy apps, such as scanners, Bluetooth peripherals, background location or medical devices, and for apps that are the core of the business. I cover the trade-offs in native vs. Flutter vs. React Native.

Option 4: rewrite in another cross-platform framework

Flutter and React Native are both sensible if your team is leaving C#. None of your C# carries over, so budget this as a rewrite of the app, not a migration. What you do keep is your backend, your API contracts and everything you have learned about your users.

How I decide

These are the questions I ask in the first conversation:

  1. How much of the C# is business logic, and is it separated from the UI? Clean separation makes every option cheaper.
  2. What native SDKs, bindings and hardware does the app touch? This is the hardest part to move, and the most likely to rule options in or out.
  3. Which third-party packages and UI toolkits are you using, and are they still maintained for .NET 10?
  4. How long does this app need to live? An app being retired in 18 months deserves a very different answer than your flagship product.
  5. Who will maintain it in three years? Pick a stack your team, or the market, can actually staff.

A sequence that keeps risk low

  1. Assess. Inventory the projects, dependencies, bindings and store accounts. Run the build on current tooling to see what actually breaks.
  2. Prove the pipeline. Get one small slice building, signing and installing on a real device with current SDKs before touching the rest.
  3. Upgrade the native projects first (Microsoft’s own recommended two-step order), then the shared Forms library.
  4. Target .NET 10 from the start. Do not migrate to an old version because an older tutorial says to.
  5. Test on real devices, with regression tests on the flows that matter, then release in stages.

Common mistakes

  • Waiting for a deadline. The store requirements above are not negotiable, and an emergency migration costs more than a planned one.
  • Picking the framework first. The right answer depends on your code and your hardware, so look at those before you choose.
  • Underestimating dependencies. An abandoned plugin can turn a small migration into a large one.
  • Treating it as a port with no testing. Microsoft’s own guidance ends with “test it thoroughly” for good reason.

Where to start

If you have a Xamarin app and you are not sure which path fits, the quickest useful step is a fixed-price App & Codebase Health Check. In one to two weeks you get a written report covering what depends on what, which options are realistic and what each would cost, and it is yours to keep whether or not you hire me.

Tell me about your app and I will give you a straight recommendation.

Sources

Dates and requirements checked against these pages on November 10, 2026. Platform policies change often, so confirm against the sources before you plan.

Have a project, or a project in trouble?

Tell me what you are building or what is broken. You will get a straight answer on whether I can help, how I would approach it, and a ballpark cost, usually within one business day.

Book a free intro callSend project details