Xamarin.Forms Is Dead. Here’s How to Migrate in 2026

Who this is for: Mobile developers and team leads who still have Xamarin.Forms apps in production and need to decide on a migration path, scope the effort, and build a plan.

The Hard Deadlines You Cannot Ignore

Let's be direct about what "end of support" means in practice. It is not a theoretical risk. It is a set of concrete, escalating problems that get worse every month you wait.

No More Security Patches

Microsoft shipped the final Xamarin security update before the May 1, 2024 cutoff. Every vulnerability discovered since then in the Xamarin stack, its dependencies, or its bindings to native SDKs is your team's problem to patch. For regulated industries (healthcare, finance, government), running an unsupported framework may violate compliance requirements outright.

App Store Submission Failures

This is the wall most teams hit first. Both Apple and Google continuously raise the minimum SDK requirements for app submissions:

• Google Play Store: As of August 31, 2025, all new apps and updates must target Android 14 (API 34) at minimum, with API 35 required for new submissions. Xamarin's final supported SDK targets API 34, which means you are at the absolute edge. Future API level bumps will lock you out entirely.
• Apple App Store: Starting April 28, 2026, all submissions must be built with the iOS 26 SDK using Xcode 26. Xamarin cannot target this. If you need to push an update after that date, you cannot.

These are not soft guidelines. They are hard submission gates. If your app needs a critical bug fix or a security patch after these deadlines, you will not be able to ship it through official channels.

OS Compatibility Drift

Even if you never update your app in the store, users are updating their phones. New versions of iOS and Android change behavior in ways that break older apps: rendering glitches, permission model failures, deprecated API behavior changes, and crashes on new hardware. There is no one fixing these issues for you.

The Two Mainstream Paths: .NET MAUI vs Uno Platform

When you migrate away from Xamarin.Forms, two production-grade .NET frameworks are the realistic options: .NET MAUI and Uno Platform. Both are actively maintained, both use XAML and C#, and both let you preserve significant portions of your existing business logic. But they differ in meaningful ways that affect which one fits your situation.

Head-to-Head Comparison

Where .NET MAUI Makes Sense

.NET MAUI is the successor path Microsoft recommends. If your app targets only iOS, Android, and Windows, and you want the platform-native look on each OS, MAUI is a solid choice. The migration guides are well-documented, and if your Xamarin.Forms app was straightforward (standard controls, limited custom renderers), the migration can be relatively direct since MAUI's XAML dialect evolved from what you already know.

Where Uno Platform Wins

Uno Platform serves a different set of requirements, and for certain team profiles, it is clearly the better fit. Here is when you should seriously consider it.

You Need WebAssembly

If your roadmap includes deploying to the browser, Uno Platform is the only mainstream .NET option that supports WebAssembly as a first-class target. This means you can ship a full-fidelity version of your app to users via a URL, with no app store required. For internal enterprise tools, B2B SaaS products, or scenarios where you want to reduce app store friction, this is a significant capability that .NET MAUI simply does not offer.

You Need Pixel-Perfect Branding

With Skia rendering as the default in Uno Platform 6.5, your UI renders identically on every platform. The same button, the same shadow, the same animation, the same layout, everywhere. For teams with strong brand guidelines or design systems that require exact visual consistency, this eliminates the per-platform testing and tweaking that native-control frameworks require.

Uno Platform's Skia renderer is hardware-accelerated across all platforms, using Metal on Apple devices, OpenGL on Linux and Android, and WebGL in the browser. Performance benchmarks show up to 60% faster startup times and 30% reduced memory usage compared to the older native rendering path.

You Need Linux Desktop

If your target includes Linux workstations (common in engineering, scientific, and government environments), Uno Platform supports Linux through its Skia rendering layer. .NET MAUI does not support Linux.

You Want AI-Assisted Migration

Uno Platform 6.5 includes two MCP (Model Context Protocol) servers that make AI agents aware of your app's structure:

• Uno Platform MCP: A documentation and API knowledge layer that gives AI agents grounded, up-to-date knowledge of the Uno Platform API surface.
• App MCP: A runtime service that exposes the live UI tree, control properties, and app state to AI agents.

These MCP servers work with any major AI coding assistant, including GitHub Copilot, Claude, Cursor, and others. It is an open protocol, not a proprietary lock-in.

Migration Scope Estimator: Audit Your Xamarin.Forms App

Before committing to a framework, you need to understand the actual scope of your migration. Not every Xamarin.Forms app is the same complexity. Use this checklist to categorize your app and estimate effort.

1 Custom Renderers Count

Custom renderers are the single biggest migration cost driver. Each one requires translation:

• In .NET MAUI: Renderers are replaced by the handler architecture. MAUI still supports a renderer compatibility layer for initial migration, but you should plan to rewrite them as handlers for performance.
• In Uno Platform: Custom renderers map to templated controls or custom controls using WinUI XAML. Uno Platform's SDK surface often covers scenarios that previously required custom renderers in Xamarin.Forms, reducing the total count.

Action item: Run a search across your solution for classes inheriting from ViewRenderer, PageRenderer, VisualElementRenderer, or any platform-specific renderer base class. Count them. Each one is a discrete migration work item.

2 Effects Usage

Xamarin.Forms Effects have no direct equivalent in WinUI XAML. They need to be replaced:

• Attached properties: For Effects that modify visual properties, create attached dependency properties in Uno Platform that apply the behavior when set.
• ControlTemplates: For Effects that alter the visual tree of a control, define a custom ControlTemplate.
• Behaviors: For Effects that respond to events or add interactivity, use XAML Behaviors.

Action item: Search for classes inheriting from PlatformEffect or RoutingEffect. Each one needs a replacement strategy.

3 DependencyService Bindings

Xamarin.Forms' DependencyService was the built-in service locator. Both .NET MAUI and Uno Platform replace this with Microsoft.Extensions.DependencyInjection, the standard .NET DI container.

Action item: Search for DependencyService.Get< and [assembly: Dependency(typeof( across your solution. Each registration needs to be moved to the DI container's ConfigureServices method.

4 Platform-Specific Code Volume

Assess how much code lives in your platform-specific projects (the .iOS, .Android, .UWP folders). This code needs the most attention during migration:

• Pure business logic: If it is platform-specific only for historical reasons, it may move to shared code.
• Native API calls: These need new bindings or conditional compilation.
• Native UI code: This needs translation to the target framework's approach.

5 Third-Party Package Dependencies

Audit every NuGet package your Xamarin.Forms app uses. For each one, determine:

Complexity Categories

Based on your audit results, your app likely falls into one of these categories:

The AI-Assisted Migration Approach

One of the practical advantages of choosing Uno Platform is the ability to use AI agents that understand both your codebase and your target framework. This is not about generating boilerplate; it is about having an agent that can reason about the mapping between Xamarin.Forms patterns and their Uno Platform equivalents.

How It Works

The workflow leverages MCP integration to give your AI coding assistant deep context about both your existing code and the target platform:

Step 1: Solution Scan

Point your AI agent at your Xamarin.Forms solution. Using standard code analysis, the agent inventories all custom renderers, Effects, DependencyService registrations, platform-specific code files, and NuGet package dependencies.

Step 2: Mapping Generation

With the Uno Platform MCP server providing current API documentation and control mapping knowledge, the agent generates a mapping table:

• CustomEntryRenderer maps to a templated TextBox with specific ControlTemplate modifications
• ShadowEffect maps to ThemeShadow or a Skia-rendered shadow via the compositor
• DependencyService.Get<IFileService>() maps to constructor injection via Microsoft.Extensions.DependencyInjection
• Third-party package X maps to package Y (version Z) or needs a custom replacement

Step 3: Prioritized Task List

The agent outputs a ranked migration task list ordered by dependency and risk. Each task includes the source files affected, the target pattern or API, estimated complexity, and blocking dependencies.

Step 4: Iterative Migration with Live Validation

As you work through the task list, the App MCP server lets the AI agent inspect your running app in real time, verifying that migrated controls render correctly, data bindings resolve, and navigation flows work. This tightens the feedback loop from "write, build, deploy, manually test" to "write code, agent validates against live app."

What This Means in Practice

For a medium-complexity app (20 pages, 5 custom renderers, a handful of Effects), the AI-assisted approach compresses the audit and planning phase from a week to a day or two, and cuts standard page migration roughly in half. The actual code migration still requires developer judgment for complex custom renderers. But the repetitive mapping work, the DI rewiring, and the boilerplate control translation are exactly where AI agents deliver real time savings. Where these tools help least is integration testing and platform-specific regression — you still need to run the app on real devices and exercise real user flows.

Migration Timeline Expectations

Every team wants to know: how long will this take? The answer depends on your app's complexity, your team's familiarity with WinUI XAML or MAUI XAML, and how much technical debt has accumulated.

The timelines below assume you are using AI-assisted tooling (MCP-connected agents for audit, mapping, and validation). Without AI tooling, expect roughly 2–3x the duration for audit, planning, and standard page migration phases.

Small App (5–10 Pages)

Characteristics: Few custom renderers (0–2), minimal Effects, standard navigation, limited platform-specific code, straightforward NuGet dependencies.

Testing is the phase AI compresses least. App MCP live validation helps catch binding and layout issues early, but platform-specific regressions still require device testing.

Medium App (15–30 Pages)

Characteristics: Several custom renderers (3–8), some Effects, DependencyService usage, moderate platform-specific code, mixed navigation patterns, third-party package dependencies that may need alternatives.

The biggest time savings are in audit (days → hours) and page migration (weeks → days). Integration testing remains the longest phase because it requires exercising real user flows on real platforms.

Large App (50+ Pages)

Characteristics: Heavy custom rendering (10+), extensive Effects usage, complex navigation (master-detail, deep linking, modal stacks), significant platform-specific code, many third-party dependencies.

For large apps, AI tooling compresses the calendar but doesn't eliminate phases. The biggest gain is that repetitive translation work (pages, services, DI wiring) that used to dominate the schedule now runs in parallel with the harder architectural decisions.

Building Your Migration Decision Document

Here is the deliverable you should produce before committing resources.

1. Current State Assessment — Xamarin.Forms version, target platforms, page/view count, custom renderer count, Effects count, DependencyService registrations, platform-specific code percentage, third-party package list with migration status.

2. Target Framework Recommendation

Choose .NET MAUI if:

• You target only iOS, Android, macOS, and Windows
• You prefer platform-native UI appearance per OS
• You want the most direct migration path from Xamarin.Forms XAML

Choose Uno Platform if:

• You need WebAssembly or Linux as a target platform
• You need pixel-perfect UI consistency across all platforms
• You want AI-assisted migration using MCP integration
• You want Hot Design for runtime visual editing

3. Scope Estimate — Complexity category (small / medium / large), estimated timeline range, key risk items, team skill gaps.

4. Migration Plan — Phased milestones with deliverables, go/no-go criteria per phase, testing strategy, rollback plan.

Frequently Asked Questions

Will my Xamarin.Forms app stop working if I don't migrate?

Your app will continue to function on devices where it is already installed. The immediate risk is not that installed apps break, but that you lose the ability to update them. Once app store submission requirements exceed what Xamarin can target (which is happening now), you cannot push updates. Over time, OS changes will cause compatibility issues on newer devices.

Can I migrate incrementally, or is it all-or-nothing?

Both frameworks support incremental migration. .NET MAUI provides a compatibility layer for running Xamarin.Forms renderers alongside new handlers. With Uno Platform, you can migrate shared business logic first, then move UI screens in batches. Large apps especially benefit from a phased approach.

How different is WinUI XAML from Xamarin.Forms XAML?

There are real differences. WinUI XAML (used by Uno Platform) has a different control set, different property names in some cases, and a different styling system (based on Style and ControlTemplate rather than Xamarin.Forms' simpler styling). However, the core concepts of data binding, layouts, and MVVM are the same. The learning curve is moderate, not steep, especially if your team has any WPF or UWP experience.

What happens to my Xamarin.Forms custom renderers?

In .NET MAUI, custom renderers are replaced by handlers. MAUI includes a compatibility layer for old-style renderers, but you should rewrite them as handlers for performance. In Uno Platform, custom renderers become templated controls, custom controls, or attached properties. The Uno Platform SDK surface is broad enough that some renderers simply become unnecessary because the functionality is built in.

Is the AI-assisted migration approach production-ready?

The MCP servers shipped with Uno Platform 6.4 and are available in 6.5. They are production tooling, not experimental. Output quality depends on the agent and your code's complexity, but the MCP integration gives any compatible agent significantly better context about both the Uno Platform APIs and your running app's state. The discovery and planning phases see the most time savings.

How does Uno Platform's Skia rendering affect performance?

Skia rendering in Uno Platform 6.5 is hardware-accelerated on all platforms (Metal on Apple, OpenGL on Android and Linux, WebGL in the browser). The rendering pipeline runs off the UI thread, with benchmarks showing up to 60% faster startup and 30% lower memory usage. For most apps, Skia rendering is as fast or faster than native controls, with the added benefit of visual consistency.

Can I use Uno Platform with my existing MVVM framework?

Yes. Uno Platform works with standard .NET MVVM frameworks including CommunityToolkit.Mvvm, Prism, and ReactiveUI. It also offers MVUX, its own reactive pattern, if you want a more modern approach. Your existing ViewModels and business logic transfer with minimal changes.