All you need to know about Xamarin in 2026 starts with one fact: Microsoft ended support for it on 1 May 2024. Nothing new should be built with it, and an existing Xamarin app can no longer be updated in the Apple or Google app stores using supported tools. Its successor is .NET MAUI, and for most apps the move is an upgrade, not a rewrite. This article explains what has stopped, what the replacement is and what the owner of a Xamarin app should do.
What Xamarin was
Xamarin was a toolkit for writing iPhone and Android apps in C#, the main language of Microsoft’s .NET platform. Its attraction was that one team, using one language, could produce apps for both kinds of phone and share most of the code between them. Microsoft bought the company in 2016 and folded the tools into its own.
There were two ways to use it, and the difference matters when planning a move:
- Xamarin.Forms, where the screens were also written once and shared across iPhone and Android.
- Xamarin.iOS and Xamarin.Android, sometimes called Xamarin native, where the business logic was shared but each platform’s screens were built separately.
What the end of support means in practice
Microsoft’s support policy states that Xamarin support ended on 1 May 2024 for all Xamarin tools, including Xamarin.Forms. There are no more fixes, security or otherwise.
For most unsupported software, the practical effect arrives slowly. For a phone app it has a hard edge, because Apple and Google set rules about what they will accept:
- The final Xamarin release can build against Xcode 15 (Apple’s developer tools for iOS 17) and Android API level 34 (Android 14), and nothing newer.
- Since 28 April 2026, Apple has required apps uploaded to the App Store to be built with Xcode 26 or later.
- Since 31 August 2026, Google Play has required new apps and updates to target API level 36 (Android 16) or higher.
Taken together, a Xamarin app cannot now be given an update in either store with the tools Microsoft supported. The version already published keeps working on the phones that have it. But if a bug appears, a login provider changes or a new phone model displays it badly, you cannot ship a fix.
On Android there is a further effect. Under the same Google Play rule, an existing app that targets API level 34 or lower is no longer offered to new users whose phones run a newer version of Android. A Xamarin app will therefore gradually disappear from the store for new users with a recent phone.
.NET MAUI, the successor
.NET MAUI (Multi-platform App UI) is Microsoft’s replacement. Microsoft describes it as the evolution of Xamarin.Forms: a framework for building apps for Android, iOS, macOS and Windows from one shared codebase, written in C# with screens defined in XAML, the same layout language Xamarin.Forms used. It is open source and is part of modern .NET, not a separate product.
Three points matter to an owner:
- It needs yearly attention. Microsoft supports each version of .NET MAUI for a minimum of six months after the next one ships, which so far has meant about 18 months in all. .NET MAUI 10 was released on 11 November 2025 and is supported until 11 May 2027. The next version is due with .NET 11 in November 2026. An app has to move up a version roughly once a year to stay supported, which is a shorter cycle than the .NET support dates that apply to server software.
- The developers’ skills carry over. A team that knows C# and Xamarin.Forms will find .NET MAUI familiar.
- Building for iPhone still requires a Mac, as it did with Xamarin.
What moving an app involves
Microsoft’s migration guidance is clear that projects do not need to be rewritten. What the work looks like depends on which kind of Xamarin app you have.
A Xamarin.Forms app becomes a .NET MAUI app. Microsoft provides a tool, the .NET Upgrade Assistant, which converts the project files, swaps the Xamarin packages for their .NET MAUI equivalents and renames the references in the code. Microsoft’s own documentation says that further effort is needed after the tool has run. Its advice is to update the app to Xamarin.Forms 5 and current versions of its dependencies first, and confirm it still works, before starting.
A Xamarin native app moves to .NET for iOS and .NET for Android. The project files are converted to the current format and the dependencies updated. The platform-specific screens are kept.
In upgrades of this kind, the effort generally collects in a few places:
- Third-party packages. Every library the app uses needs a version that works on modern .NET. Where the author has abandoned one, a replacement has to be found.
- Custom controls. Xamarin.Forms apps often customised controls through what it called renderers. .NET MAUI uses a different mechanism, handlers, so these need reworking.
- Unsupported project types. Microsoft lists Xamarin.watchOS as having no upgrade route, and the Upgrade Assistant does not handle binding projects or iOS extensions.
- Testing. Every screen needs checking on real phones of both kinds, because layout and behaviour can shift.
A small, tidy app with few dependencies can be moved quickly. A large one with many custom controls and old libraries is a project, and should be estimated after someone has looked at the code.
The options for the owner of a Xamarin app
- Upgrade to .NET MAUI. The default when the app is sound and the people maintaining it work in C#. It keeps the business logic and most of the code.
- Rebuild with a different toolkit. Flutter, from Google, and React Native are the two main alternatives for building iPhone and Android apps from one codebase, and both are actively maintained. This is a rewrite, so it makes sense only if the app needs redesigning anyway or the available developers work in those tools.
- Replace it with a web application. Many business apps are forms and lists that would work as well in a phone’s browser, with no app store involved. If the app does not need to work offline or make heavy use of the phone’s hardware, this can be the cheapest route. Our article on native apps and web apps covers how to decide.
- Retire it. If few people use it, switching it off is a legitimate answer.
Doing nothing is also a choice, with a known outcome: the app cannot be fixed, and on Android it fades from view. Our page on unsupported software sets out how to weigh that risk.
What to check this week
Before asking anyone for a price, establish these facts:
- Do you have the source code? Not the app from the store: the project files a developer builds it from.
- Is it Xamarin.Forms or Xamarin native? The project files will say.
- Who holds the Apple Developer and Google Play accounts? They should be in your company’s name, not a former supplier’s or a past employee’s. Without them and the signing keys, nobody can publish an update under the existing listing.
- When was the last store release, and which Android API level does it target?
- How many people use it, and what would they do if it stopped tomorrow?
If the people who built it have gone and the answers are unclear, an independent code audit will establish what you have and what each option would involve. Xamarin is one of several retired technologies on our end-of-support pages, alongside the dates for the platforms a mobile app’s server side usually depends on.