• MaboaSoft Engineering Team

You Cannot Migrate This Year: Keeping a Xamarin.Native App Shippable

Most articles about Xamarin store deadlines are written as though the deadline is coming. It is not. Apple stopped accepting Xamarin-built binaries in April 2025 and Google Play stopped accepting Xamarin updates in August 2025. If you are still on Xamarin today, you are already unable to ship — and on 31 August 2026 your published Android app becomes invisible to new users on modern devices. Here is the honest state of play and what you can still do.

You Cannot Migrate This Year: Keeping a Xamarin.Native App Shippable

Most writing about Xamarin and app store deadlines has the tense wrong. It talks about a deadline that is coming, a decision you need to make, a window that is closing.

The window closed. Here are the dates, verified against Apple, Google and Microsoft on 6 August 2026:

  • Apple stopped accepting Xamarin-built binaries on 24 April 2025.
  • Google Play stopped accepting Xamarin new apps and updates on 31 August 2025.

If you are still running a Xamarin.Native app in production, you have not been able to ship an update to either store for roughly a year. Some teams reading this already know that and have been quietly not shipping. Others are about to discover it during their next release.

This post is not a countdown. It is an honest account of where you actually stand, what is still possible, and what changes in twenty-five days.

The arithmetic

Microsoft’s Xamarin support policy states the ceiling plainly:

Xamarin support ended on May 1, 2024 for all Xamarin SDKs including Xamarin.Forms. Android API 34 and Xcode 15 SDKs (iOS and iPadOS 17, macOS 14) are the final versions Xamarin targets from existing Xamarin SDKs (that is, no new APIs are planned).

Now put that against the store floors.

Apple

DateRequirementXamarin ceiling
29 Apr 2024Xcode 15 / iOS 17 SDKXcode 15 — exactly compliant
24 Apr 2025Xcode 16 / iOS 18 SDKXcode 15 — blocked
28 Apr 2026Xcode 26 / iOS 26 SDKXcode 15 — two generations below

April 2024 was the last month a Xamarin.iOS app was compliant. The ceiling and the floor met exactly, and then the floor kept rising.

Apple’s current wording: “Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26.” There is no extension process and no exemption.

Google

DateRequirementXamarin ceiling
31 Aug 2025API 35, new apps and updatesAPI 34 — blocked
31 Aug 2026API 36, new apps and updatesAPI 34 — two levels below

Google does offer an extension to 1 November 2026 for the API 36 requirement, but it is irrelevant here: an app that cannot reach API 35 gains nothing from more time to reach API 36.

One useful correction to a common misreading — Apple’s requirement governs the SDK you build with, not the minimum iOS version you support. Xcode 26 still permits a deployment target as low as iOS 15. Dropping old iOS versions was never the issue. The build toolchain is.

What happens on 31 August 2026

Twenty-five days from this article’s date, and this is the part most teams have not modelled.

Your published Android app is not removed. Google is explicit:

Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app’s target API level. Apps that target Android 14 (API level 34) or lower … will only be available on devices running Android OS that are the same or lower than your app’s target API level.

And:

Users who have previously installed the app from Google Play will continue to be able to discover, re-install and use the app on any Android OS version that the app supports.

Read carefully, that is three separate consequences that teams routinely collapse into one:

  1. The app is not delisted. It stays in the store.
  2. New users on Android 15 and Android 16 devices cannot install it. Your addressable market silently shrinks to older devices, and keeps shrinking as the fleet turns over.
  3. You cannot ship any update at all. That has been true since August 2025 and is unrelated to points 1 and 2.

Point 2 is the one that shows up in a business review rather than an engineering review. Nobody gets an alert. Installs simply decline, and the decline is structural rather than seasonal.

On iOS the situation is simpler and worse: the published app stays available to everyone, and you can never change it again. Not a bug fix, not a certificate rotation, not a backend URL. Nothing.

What you can still do

Being unable to ship is not the same as being unable to act. In rough order of value.

1. Confirm the diagnosis before you act on it. If you are not completely certain whether you are on Xamarin.Native or Xamarin.Forms — and a surprising number of teams are not — settle it first with Xamarin.Forms or Xamarin.Native? Which Migration You Are Actually Facing. The two have different destinations and different costs, and the wrong answer wastes the quarter you no longer have.

2. Fix everything that is not in the app binary. This is the largest category of remaining leverage and it is frequently overlooked. Backend APIs, server-side configuration, feature flags, content, push payloads, third-party SDK settings changed through a dashboard rather than a package — all of it is still fully under your control. A meaningful share of the bug reports sitting in your backlog can be resolved without touching the client at all. Go through them with that filter before assuming you are frozen.

3. Establish your actual security exposure. Support ended 1 May 2024. As of today that is more than two years with no patch for the runtime, the bundled BCL, or the platform bindings. That is a statement about the platform, not about your app — but if you are in a regulated sector, or you answer security questionnaires, or you have a penetration test scheduled, someone will eventually ask. It is much better to have the answer written down before they do than to compose it under pressure. Your dependency inventory is a good place to start: third-party packages on this stack are frequently unmaintained too.

4. Stop new feature work on the Xamarin codebase. It cannot ship. Any feature built there is inventory that will need re-testing after migration, on a runtime it has never run on. Redirect that capacity into migration preparation — dependency inventory, binding project triage, the IntPtr handle audit described in Xamarin.Native to .NET for iOS and .NET for Android. That work is not wasted; it is the migration’s first phase, and doing it early shortens the critical path once budget arrives.

5. Model the install decline. For Android, pull your installs segmented by OS version. The proportion running Android 15 or 16 is the share of new-install demand you lose from 31 August. That number, plotted forward against normal device turnover, is the most persuasive artefact you can put in front of whoever controls the budget — considerably more persuasive than a technical explanation of API levels.

6. If your app is genuinely internal, check the one exemption. Google’s target API level policy exempts “permanently private apps that are restricted to users in a specific organization and intended for internal distribution only.” If that describes your app, your situation is materially less urgent than this article assumes and enterprise distribution changes the calculus. It does not, however, change the security position.

What does not work

Raising targetSdkVersion by hand in AndroidManifest.xml. This gets suggested in every thread on the topic. We could not confirm from any authoritative source that it produces a Play-accepted, functionally correct build on Xamarin.Android 13, and we are not going to recommend it on that basis. Declaring a target API level does not implement the platform behaviours that come with it — Android 15’s edge-to-edge enforcement and 16 KB page size support among them — so the realistic outcome is a build that either fails pre-launch checks or breaks at runtime for users. It is unsupported by Microsoft regardless.

Waiting for Microsoft. The support policy says the final SDKs target Android API 34 and Xcode 15, “that is, no new APIs are planned.” This is not a roadmap gap that might close. It is a completed end-of-life.

Waiting for the stores to relax. Apple has raised its floor in late April for four consecutive years, with roughly two to three months’ notice each time. Google runs on an annual August cycle. Neither has ever moved backwards.

The decision this actually forces

Because the deadlines have passed rather than approached, the question is no longer when do we start. It is what does being unable to ship cost us per month, and how does that compare to the migration.

That is a better question, and it is usually easier to answer. It is also one where the numbers tend to favour acting, because the cost of being frozen is continuous while the cost of migrating is one-off.

Three inputs are enough for a first pass:

  • Bugs you cannot fix. Count the client-side issues in your backlog that survived filter 2 above. Multiply by whatever a support escalation costs you.
  • Revenue or adoption from new installs on modern Android devices. This goes to zero on 31 August 2026 and is currently non-zero.
  • The compliance answer you cannot currently give. Harder to price, but if a deal has ever stalled on a security review, you already know the number is not zero.

Against that, the migration is bounded, and — for a Xamarin.Native app specifically — smaller than most teams assume, because the UI layer carries over. That is the part worth internalising before the budget conversation: you are not rebuilding the app.

How MaboaSoft helps

We work with teams whose apps are in exactly this position — shipped, in production, generating revenue, and structurally frozen. Usually the immediate need is not the migration itself but a defensible account of the exposure: what still works, what cannot be fixed, what it costs per month, and what the migration actually involves for this specific codebase.

If that is where you are, book a 20-minute call. We will tell you what we would do first.

FAQ

Can a Xamarin app still be submitted to the App Store?

No. Since 24 April 2025 Apple has required uploads to App Store Connect to be built with Xcode 16 or later, and since 28 April 2026 with Xcode 26 and an iOS 26 SDK. Microsoft states that Xcode 15 SDKs are the final versions Xamarin targets, with no new APIs planned. Xamarin’s ceiling and Apple’s floor no longer overlap, and there is no extension or exemption process.

Can a Xamarin app still be updated on Google Play?

No. Since 31 August 2025 both new apps and updates have had to target Android 15, API level 35, and from 31 August 2026 the requirement rises to Android 16, API level 36. Xamarin caps at API 34. An extension to 1 November 2026 exists for the API 36 requirement, but it does not help an app that cannot reach API 35 either.

Will my published app be removed from the stores?

No, and this distinction matters. Google states that existing apps are not removed, but from the deadline they are only available on devices running an Android OS version equal to or lower than the app’s target API level, so they become invisible to new users on newer devices. Users who previously installed the app can still discover, re-install and use it. On iOS the published app remains available; you simply cannot ship it any updates.

Can I raise targetSdkVersion in AndroidManifest.xml to get past the Google deadline?

This is commonly discussed and we cannot confirm it produces a Play-accepted, functionally correct build, so we do not recommend it. Declaring a target API level without the corresponding platform behaviours — Android 15 edge-to-edge enforcement and 16 KB page size support among them — risks runtime breakage and pre-launch report failures. It is unsupported by Microsoft in any case.

How long has Xamarin been without security patches?

Support for all Xamarin SDKs, including Xamarin.Forms, ended on 1 May 2024. As of August 2026 that is more than two years during which no security fix has shipped for the runtime, the BCL as delivered by Xamarin, or the platform bindings. Any vulnerability disclosed in that period has no vendor patch on this stack.

Resources

All dates and requirements verified against the primary sources above on 6 August 2026. Google’s API 36 requirement takes effect on 31 August 2026; this article was written before that date and describes it as forthcoming.