Xamarin End of Support

Microsoft ended support for Xamarin in May 2024. If you are reading this because somebody forwarded you that sentence with a question mark attached, here is the practical version.

What "end of support" actually means

Your app did not stop working on the day support ended, and it will not stop working on any particular day in the future. Nothing was switched off. What ended is the flow of fixes and updates: no security patches, no compatibility work for new iOS and Android releases, no support for new SDK versions, and no one to escalate a framework bug to.

That matters because the platforms underneath the app keep moving whether the framework does or not.

The three ways it actually bites

1. Store requirements. Apple requires apps to be built against a reasonably current iOS SDK, and Google Play requires updates to target a recent Android API level. Both raise the bar on a published schedule. An unsupported framework eventually cannot be built to meet them, and at that point you cannot ship updates at all — not new features, not bug fixes, not a security patch.

2. OS behaviour changes. Each iOS and Android release changes something about permissions, background execution, storage or notifications. A supported framework absorbs some of that for you. An unsupported one does not, so the first sign is often a support ticket from users on the newest OS.

3. Security and compliance review. An unsupported framework in a dependency inventory is a finding. It tends to surface during a customer security review, an insurance renewal, or an audit, and the deadline is set by someone outside engineering.

What did not end

The C# is fine. The business logic, the view models, the service clients, the models and the tests — the part of the codebase that represents actual investment — moves forward largely intact. What has to change is the UI layer and the project structure.

That is worth saying plainly, because "the framework is unsupported" is often heard as "the code is worthless", and the two are very different budget conversations.

Deciding what to do

There are three honest answers, and which one applies is a question about your repository and your calendar.

Rescue first. If a store deadline or a live rejection lands before any realistic migration date, get one more compliant release out first. It buys a release cycle and it does not waste the work.

Migrate. Move to .NET MAUI incrementally, in releasable slices, keeping the shared logic and converting the UI layer. This is the answer for most apps that are still carrying real usage.

Retire. Some of these apps should not be migrated. If the analytics show one flow in use, or the process the app was built around has changed, replacing it with something small — or with nothing — is the cheaper and more honest answer. We will tell you when we think that is the case.

Where to start

An assessment answers which of the three applies, with the evidence attached, and it is deliberately a document you can act on without us.