If you are still running a Xamarin app in 2026, here is the situation in plain terms. Microsoft ended support for all Xamarin SDKs on 1 May 2024. Your app still runs and still sits in the stores, but it receives no fixes, no security updates, and no technical assistance — and its final SDKs cap at Android API 34 and Xcode 15 (iOS 17), with no new platform APIs coming. The end-of-support date is not the real deadline. The real deadline is the day Apple or Google stop accepting new submissions built on those SDK levels, because that is the day you can no longer ship an update. You have four realistic options: migrate Xamarin.Forms to .NET MAUI, move native projects to .NET for Android/iOS, rewrite in Flutter, or run a controlled freeze while you plan. Here is how to choose.
What “end of support” actually changed
End of support does not mean your app was switched off. It means three specific things:
- No more fixes or updates. Bugs in the Xamarin runtime, including security bugs, will not be patched.
- No new platform APIs. The final Xamarin SDKs target up to Android API 34 and Xcode 15. Newer OS capabilities are simply not reachable.
- No official technical assistance. You are on community support and your own team from here.
None of that removes your app from the stores today. It sets a slow-burning clock, and the clock is driven by the app stores — not by Microsoft.
The one deadline that matters: app-store SDK requirements
Both Apple and Google periodically raise the minimum SDK and target-API level required to submit an app. Google Play enforces a target-API-level requirement that increases every year; Apple requires builds made with a recent Xcode/SDK.
Xamarin’s final SDKs cap at Android API 34 and Xcode 15. So the forcing function is straightforward: at some point, the store minimums move past what Xamarin can produce, and your next update is rejected. Your app does not vanish — it freezes. You can no longer fix a crash, respond to a security disclosure, or ship a feature. For a business-critical app, “we can no longer publish updates” is the moment the cost of waiting becomes unbounded, and it arrives on the store’s schedule, not yours. That is why the decision is a planning problem now, not a firefighting problem later.
Option 1 — Migrate Xamarin.Forms to .NET MAUI
If your app is a typical Xamarin.Forms app and your team is invested in C# and .NET, this is usually the shortest path. Microsoft’s guidance is explicit: projects need to become SDK-style, but they do not need to be rewritten. Business logic, view models, and services move across largely intact. The effort concentrates in the UI layer — specifically custom renderers, which .NET MAUI replaces with handlers — plus third-party dependencies and platform-specific code.
Choose this if: you want to stay in .NET, your app is Xamarin.Forms, and you value keeping your existing codebase. We break down what it costs in the Xamarin to .NET MAUI migration cost and effort guide.
Option 2 — Migrate native projects to .NET for Android / .NET for iOS
If your app is Xamarin.Android or Xamarin.iOS native (not Forms), you do not adopt MAUI at all. Microsoft folded those project types directly into .NET: Xamarin.Android, Xamarin.iOS, and Xamarin.Mac are now .NET for Android, .NET for iOS, and .NET for Mac. You upgrade the projects to SDK-style and retarget onto modern .NET.
Choose this if: you built native rather than Forms, and you want back onto a supported .NET without adopting a new UI framework.
Option 3 — Rewrite in Flutter
Some teams use the forced move as the moment to reconsider the stack entirely. Flutter is a credible target when you want one UI toolkit across mobile and web, when your team is moving away from .NET, or when the Xamarin app is old enough that a clean rebuild is cheaper than untangling it.
Be honest about what this is: a rewrite, not a migration. Your C# business logic does not come with you, and the cost is higher than Options 1 or 2. Choose Flutter for strategic reasons — platform direction, hiring, a genuinely fresh start — not as a shortcut to avoid a MAUI migration. We compare the two directly in our upcoming Flutter vs .NET MAUI piece; for now, treat this as the “changing direction” option, not the default.
Option 4 — Controlled freeze (buying time, deliberately)
Doing nothing is a choice, and occasionally the correct one — but only as a controlled freeze, not neglect. That means: you have measured how much store runway you have left, you have a security-monitoring plan for the unpatched runtime, and you have a funded date to start the real move. A controlled freeze is a planning decision with an end date. An uncontrolled freeze is a risk you have not priced.
Choose this only if: the app is genuinely low-risk or short-lived, and you have written down when the freeze ends.
If you have lost the original team
Many Xamarin apps have outlived the engineers who built them. If nobody can explain why the app behaves the way it does, every option above gets riskier, because a “faithful” migration can faithfully carry over bugs or silently drop undocumented behaviour a user depends on.
Before you migrate or rewrite, recover the product model from the code. We wrote up the method in recovering product knowledge from a legacy repository and the legacy repository discovery checklist. This “Step 0” is what keeps a migration from turning into an expensive archaeology project halfway through.
How to choose
A quick decision guide:
| Your situation | Most likely option |
|---|---|
| Xamarin.Forms app, staying in .NET | .NET MAUI (Option 1) |
| Xamarin native app, staying in .NET | .NET for Android/iOS (Option 2) |
| Rethinking the stack; want mobile + web from one toolkit | Flutter rewrite (Option 3) |
| Low-risk or short-lived app, with a written end date | Controlled freeze (Option 4) |
| Any of the above, but the original team is gone | Run legacy discovery first, then decide |
The wrong move is to let the app-store clock make the decision for you. Once an update is rejected, you are choosing under pressure with no runway — the most expensive way to migrate.
Where MaboaSoft fits
Xamarin modernization and Xamarin-to-MAUI migration are core to what we do, and we work as an embedded senior team rather than a body shop. If you want help deciding between these options — or a scoped plan and estimate once you have decided — book a 20-minute call, read the migration cost and effort guide, or look at how we work.
FAQ
When did Xamarin support end? Microsoft ended support for all Xamarin SDKs — including Xamarin.Forms, Xamarin.Android, and Xamarin.iOS — on 1 May 2024. After that date there are no fixes, security updates, or technical assistance, and the final SDKs target only up to Android API 34 and Xcode 15 (iOS 17).
Can I keep shipping my Xamarin app in 2026? For now, yes — an existing Xamarin app keeps running and stays in the stores. The constraint is that its final SDKs cap at Android API 34 and Xcode 15. As Apple and Google raise the minimum SDK and target-API levels they accept for new submissions, an app that cannot move past those levels will eventually be unable to publish updates. That store requirement, not the end-of-support date itself, is the deadline that forces the decision.
What are my options if I am still on Xamarin? There are four realistic paths. Migrate Xamarin.Forms to .NET MAUI. Migrate Xamarin native apps to .NET for Android and .NET for iOS. Rewrite in a different framework such as Flutter. Or run a controlled freeze while you plan. The right choice depends on how much custom UI you have, whether you want to stay in the .NET ecosystem, and how much runway your store situation gives you.
Should I migrate to .NET MAUI or rewrite in Flutter? If your team is invested in C# and .NET and your app is a typical Xamarin.Forms business app, .NET MAUI is the shorter path because business logic, view models, and services move across without a rewrite. Flutter makes more sense when you are already reconsidering the stack, want a single UI toolkit across mobile and web, or your team is moving away from .NET. It is a rewrite, so the cost is higher — choose it for strategic reasons, not to escape the migration.
Sources (accessed 14 July 2026):
- Microsoft, Xamarin support policy — end of support 1 May 2024; final SDKs at Android API 34 and Xcode 15; Xamarin native project types become .NET for Android / iOS / Mac.
- Microsoft Learn, Upgrade from Xamarin to .NET — SDK-style projects, no rewrite required, Xamarin.Forms to .NET MAUI.
- Google Play, target API level requirements; Apple, App Store submission requirements — store minimums that rise over time.