Moving from Xamarin to .NET MAUI: a practical migration guide

Some Xamarin apps have simply kept working. The app is on the phones of the people who use it, nobody has complained, and the codebase has not been opened in a while. Then someone asks whether Xamarin is still supported, and the honest answer is that it is not.

This guide is for teams in that position. It covers what unsupported means for a mobile app, the migration path Microsoft documents, the places migrations usually get stuck, and a way to time-box the work so you know when to carry on and when to choose a different route. It is written on 5 November 2026, so the target is .NET 10 and .NET MAUI 10; .NET 11 is not yet released. Details are as of that date.

What "unsupported" means for a mobile app

Microsoft's Xamarin support policy says support ended on 1 May 2024, for all Xamarin SDKs including Xamarin.Forms. It defines end of support as the date when Microsoft no longer provides fixes, updates or online technical assistance. The policy also lists the final versions Xamarin targets: the Android API 34 and Xcode 15 SDKs.

For a mobile app, that has particular consequences, because the app stores keep moving:

Store requirements. Apple's upcoming requirements page says that, since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later. Google Play's target API level policy has required new apps and app updates to target Android 16 (API level 36) since 31 August 2026, and the extensions developers could request ran only to 1 November 2026. Xamarin's last supported targets are older than both. Whether you can still publish an update depends on the exact build, so check the current rules before you assume you can.
No fixes. A bug in the framework, or a security issue in a Xamarin component, will not be corrected.
Libraries stop moving. Third-party packages gradually drop Xamarin targets, so the dependency list ages with the framework.

None of this means the app stops working on users' phones tomorrow. It means your ability to update it, and to respond if something goes wrong, is steadily narrowing.

The official path

Microsoft's support policy and upgrade guidance set out the shape of it:

Xamarin.Android and Xamarin.iOS moved into .NET as .NET for Android and .NET for iOS (with Xamarin.Mac following the same route to .NET for macOS).
Xamarin.Forms moved to .NET MAUI.
All projects must become SDK-style projects, but you do not have to rewrite the app, and a multi-project solution does not have to become a single project.

So this is an upgrade in structure and APIs, not a new application. Most of your C# business logic, view models and XAML pages carry over with changes.

One practical note: Microsoft's migration hub still refers to .NET 8 in places, for example when it tells you to update dependencies. Use the same approach but target .NET 10, and read any net8.0-* framework names as their net10.0-* equivalents.

For how MAUI is put together, see How .NET MAUI works, and for the decision of whether it suits your product at all, .NET MAUI explained.

The steps

Inventory. List every project, target platform, NuGet package, custom renderer, effect and platform-specific piece of code. This is the work that makes the estimate honest.
Convert to SDK-style projects. Required for everything. Start with the shared libraries: they can move to the new project format on netstandard and keep running under the Xamarin app, which makes a good first milestone. The Android and iOS app projects come next, and converting them is the point where they become .NET for Android and .NET for iOS rather than Xamarin.
Update packages. Check each package on NuGet for a modern target (for example net10.0-android or net10.0-ios). Packages that target only Xamarin.iOS or Xamarin.Mac will not work. Android packages that target only monoandroid may still restore, but treat them as a warning sign: .NET 11 starts warning about them. Where there is no compatible version, replace it. The Xamarin Community Toolkit is a common case; its counterpart is the .NET MAUI Community Toolkit, although the two are not drop-in equivalents, so treat it as a package to replace and test.

Convert custom renderers to handlers. MAUI replaces renderers with handlers. Microsoft's guides say existing renderers can be reused in MAUI or migrated to handlers; handlers are the better end state. A typical customisation looks like this (illustrative, not tested against your app):

// In MauiProgram.cs, before building the app
Microsoft.Maui.Handlers.EntryHandler.Mapper.AppendToMapping("NoUnderline", (handler, view) =>
{
#if ANDROID
    handler.PlatformView.BackgroundTintList =
        Android.Content.Res.ColorStateList.ValueOf(Android.Graphics.Color.Transparent);
#endif
});

Update namespaces and XAML. Xamarin.Forms becomes Microsoft.Maui and Microsoft.Maui.Controls, and the XAML namespace changes:

<!-- Before -->
xmlns="http://xamarin.com/schemas/2014/forms"
<!-- After -->
xmlns="http://schemas.microsoft.com/dotnet/2021/maui"

Resources. Images, fonts, splash screens and app icons move into a Resources folder structure with their own build actions, and are resized at build time. This tends to simplify things, but it touches many files.
Platform code. Move code from MainActivity, AppDelegate and the like into the matching places in the new project, and re-apply manifest settings.
Build, signing and pipeline. Update CI images and tooling, certificates, provisioning profiles and keystores. This is where "works on my machine" problems surface.
Test on real devices. Emulators miss things that real phones do not, especially around permissions, camera, location and background behaviour.

Tooling, and where a person must review

Microsoft's porting documentation describes the .NET Upgrade Assistant as officially deprecated, and names the GitHub Copilot app modernization agent as the recommended tool for new upgrade work. The migration hub still describes the Upgrade Assistant for Xamarin.Forms, so check which applies to your situation before you start.

AI tools can speed the mechanical parts: namespace changes, project file conversion, a first draft of a handler. They do not understand which of your screens matters most to the business, and they can produce code that compiles and behaves differently. A person must review every change, and the app must be tested before the result is trusted. We say the same about AI assistants in a development team.

Test the riskiest screens first

Before converting, write down a smoke-test checklist for the screens and flows the business cannot do without: sign-in, the main data entry flow, anything involving payments or sync. If you have time, add characterisation tests around the shared logic. Run the checklist on the old build to establish what correct looks like, and again after each stage of the migration.

A realistic time-box

Treat the first phase as a spike, not a commitment. Take the riskiest screen and the most awkward dependency, and migrate those on a branch within a fixed period (a couple of weeks is a reasonable starting point for a small app). At the end, decide with evidence:

Carry on if the spike went broadly to plan and the remaining work looks like repetition.
Re-plan if one dependency or renderer turned out to be a real obstacle that has a known cost.
Choose another route if the app depends heavily on a Xamarin-only component, is small enough to rebuild quickly, or needs a different shape. Options include a rewrite in MAUI, fully native apps, or a web app, and the decision is a business one as much as a technical one.

Target the supported release. MAUI 10 is the supported version as of today, but MAUI 11 is expected with .NET 11 this month. Microsoft's MAUI support policy gives each major version support for at least six months after its successor ships, so MAUI 10 may have only about six months left once 11 arrives. A migration that will finish in 2027 should plan the move to MAUI 11 into the same project rather than treat MAUI 10 as the destination.

If the move has to wait

Some organisations cannot migrate this quarter. That is a legitimate decision if it is made deliberately. Record the exposure (what you cannot fix or publish), the owner, the date you will review it, and what would trigger an earlier move, such as a store rejection. The same logic applies to .NET 8 and .NET 9 as they reach end of support, and the upgrade guide for .NET 8 shows how to time-box a framework move.

If you want some context on where this started, we wrote an older post on whether Xamarin apps are native in 2020, while Xamarin was still supported. Read it as a record of its time.

A sensible first step

Begin with the inventory: projects, platforms, packages, renderers and the date of the last store release. Then check Apple's and Google's current requirements against your last build. That gives you a factual basis for deciding the timing.

We build .NET MAUI apps and migrate Xamarin apps to MAUI, continuing the Xamarin work we did in earlier years, and we look after .NET (C#) applications as part of software care. Our software and integration work covers the build itself. If you would like an independent view of where your app stands, start with a software health audit.