Xamarin Native vs Xamarin.Forms (2026): What Replaced Each and Which to Use

Last updated: October 2026. Written by Josh Hutcheson. This comparison is based on each framework’s official documentation and release notes, the 2025 Stack Overflow Developer Survey and developer discussions, all read in October 2026. See our review methodology.

Xamarin Native and Xamarin.Forms were the two ways to build mobile apps with Xamarin. Xamarin Native (Xamarin.iOS and Xamarin.Android) meant writing a separate C# user interface for each platform. Xamarin.Forms meant writing one shared UI in XAML. Both are now retired, but the choice they represented is alive: each has a direct successor in modern .NET, and teams still have to pick between them. This guide explains the difference, what replaced each, and which to use in 2026.

Version numbers, support dates and platform-stability levels come from the official sources linked in this article, read on 13 October 2026. Frameworks ship new releases every few months, so check the linked release notes before you plan around a specific version.

Xamarin Native

“Xamarin Native” was the informal name for Xamarin.iOS and Xamarin.Android. They exposed each platform’s full SDK to C#, so anything you could do in Swift, Objective-C, Java or Kotlin you could do in C#, with the same native controls and APIs. You shared business logic between platforms (data access, networking, validation) but built each user interface separately, using iOS storyboards or code for iPhone and Android layouts for Android.

Today these live inside .NET as .NET for iOS and .NET for Android. Microsoft’s Xamarin support policy says existing Xamarin.Android and Xamarin.iOS projects “should be upgraded to .NET SDK-style projects for continued support”, and the .NET MAUI support policy covers those Android and iOS SDKs. The programming model is the same as before; the tooling, project format and API levels are current.

Xamarin Forms

Xamarin.Forms added a cross-platform UI toolkit on top of Xamarin Native. You described screens once, in XAML (Microsoft’s XML-based UI language) or in C#, and Forms turned each control into the matching native control on iOS, Android and Windows. Most of an app, UI included, could live in one shared project.

Xamarin.Forms 5.0 was its last version. .NET MAUI is its successor, which Microsoft describes as “the evolution of Xamarin.Forms, extended from mobile to desktop scenarios, with UI controls rebuilt from the ground up for performance and extensibility.” The biggest structural change is that MAUI replaced Forms’ renderers with lighter handlers, and moved from several platform projects to one project with platform folders.

Older versions of this page said Xamarin Native shared “up to 75%” of code and Forms “up to 95%”. We could not find a current source for either number, and real figures vary widely by app, so we have removed them.

Xamarin.Forms vs .NET MAUI: what changed

If you know Forms, most of MAUI will feel familiar. The main differences:

• One project. MAUI uses a single project with a Platforms folder instead of a shared project plus separate iOS and Android head projects.
• Handlers instead of renderers. Customizing a control means changing its handler mapping rather than subclassing a renderer, which is less code and faster at runtime.
• Desktop built in. MAUI targets Windows through WinUI 3 and macOS through Mac Catalyst; Forms’ main desktop target was UWP on Windows.
• Essentials included. The separate Xamarin.Essentials package (device APIs) is part of MAUI.
• Hot reload for XAML and C#. Both are built into the current tooling.
• Control changes. MAUI 10 deprecated ListView, TableView and the cell types in favor of CollectionView, and removed the old compatibility layouts from templates.

Performance

The original argument still holds in a softer form. A Native app talks to each platform’s UI directly, while Forms added a layer that translated shared controls into native ones, which cost some speed on complex screens. Forms apps could feel slower on long lists, deep layouts and startup.

.NET MAUI narrowed that gap. Handlers are thinner than Forms renderers, and MAUI 10 made faster CollectionView and CarouselView handlers the default on iOS. Both MAUI and .NET for iOS apps are fully ahead-of-time compiled on iOS, and both JIT-compile on Android. For typical business screens the difference between a shared MAUI UI and a fully native .NET UI is small. It still shows up in heavy custom drawing, complex animation and very large lists, where platform-specific code has the edge.

Development Time

Shared UI is faster to build. With Xamarin.Forms, and now .NET MAUI, you write each screen once. With Xamarin Native, and now .NET for iOS and Android, you write each screen twice and keep both in sync. For a prototype, a minimum viable product or an internal tool, the shared approach usually wins clearly.

The gap narrows when an app needs different behavior on each platform anyway. If half the screens need platform-specific work, a shared UI saves less, and the time spent working around the abstraction can cancel out the savings.

Development Costs

Costs follow time and skills. A shared-UI app needs fewer total developer hours, and most C# developers can work on it without deep iOS or Android experience. A native-UI app needs developers who understand UIKit and Android views as well as C#, a rarer and more expensive mix.

• Tools. Visual Studio Community is free for individuals and up to five users in non-enterprise organizations; larger companies need a paid license. VS Code with the .NET MAUI extension is another option.
• Store fees. Apple’s developer program is US$99 a year, and Google Play’s registration is a one-time US$25, whichever approach you use.
• Upgrades. Each MAUI version is supported for about 18 months, so budget for a yearly upgrade with either approach.

For a startup or a tight budget, the shared approach is usually cheaper. For an app whose value depends on a polished, platform-specific experience, the extra cost of native UI can pay for itself.

UI Complexity

Native UI gives full control. Each widget is the platform’s own, so you can match Apple’s and Google’s design guidelines exactly and build complex, platform-specific interactions.

This page used to say a Forms app could never look native, that its animations were hard, and that “you could develop a 2D game in Xamarin Native but you can’t do that in Forms.” Those claims went too far. Forms and MAUI render real native controls, so standard screens do look native, and both support animation APIs. Custom drawing and simple 2D games are possible in a shared UI with SkiaSharp, the open-source 2D graphics library for .NET. What remains true: highly custom, platform-specific designs and heavy animation take more effort through a shared layer, and some teams find a native UI simpler for them.

App Functionalities

Native has no ceiling: the full iOS and Android SDKs are available from C#. A shared UI was more limited in Xamarin.Forms days, when platform features meant writing custom renderers or dependency services.

.NET MAUI makes this much easier. It includes cross-platform APIs for common device features (sensors, connectivity, file pickers, secure storage), and you can invoke platform code directly from the shared project using conditional compilation or partial classes. You can also embed native views in a MAUI page. So “if your app has a lot of platform-specific features, your only option is Native” is no longer true; it is a question of how much platform code you are willing to write inside a shared app.

Updates & Maintenance

A single shared codebase is easier to update: fix a bug once and ship it everywhere. Native-UI apps need each platform’s UI changed separately, which takes longer and risks the two versions drifting apart.

Maintenance now has another dimension: framework support. Every Xamarin app, Native or Forms, is frozen at Android API 34 and Xcode 15. Google Play has required API 35 for new apps and updates since 31 August 2025, and from 1 February 2027 Play will block updates that do not support 16 KB memory page sizes. Apple requires uploads built with Xcode 26. Developer forums in 2026 show teams struggling to keep Xamarin.Forms apps in the stores with workarounds. Migration to .NET is the durable fix.

Pros and cons at a glance

When to use .NET MAUI and when to go native

A few common scenarios, and the approach that usually fits:

• An internal inspection or field-service app with forms, photos, offline data and sync to a .NET backend: .NET MAUI. Shared UI, shared models with the server, and Windows tablets come for free.
• A consumer app whose design differs on iPhone and Android, with platform-specific navigation and gestures: .NET for iOS and .NET for Android, or a fully native Swift and Kotlin build.
• A Windows desktop tool that now needs a mobile companion: .NET MAUI, since one project covers Windows, macOS, iOS and Android.
• An existing Xamarin.Forms app: .NET MAUI, migrating screen by screen and dropping to platform code only where a screen needs it.
• An existing Xamarin.iOS or Xamarin.Android app with mature native UIs: upgrade each to .NET for iOS and .NET for Android rather than rewriting the UI in MAUI.

If you are not tied to C#, it is worth comparing other cross-platform options before you commit. Flutter and React Native both have larger communities than MAUI; our Xamarin vs Flutter guide compares MAUI with Flutter directly, and React Native vs React explains the JavaScript route. If you are leaning native, start with Android vs iOS development, Kotlin vs Java and our best Swift tutorials; web-first teams can look at Ionic.

How to migrate Xamarin Native and Xamarin.Forms apps

Microsoft’s upgrade guide covers both paths, and nearly every project type can move.

• List every NuGet package and confirm it has a .NET MAUI or .NET 10 version. Developers report this as the most common blocker.
• Rewrite custom renderers as handlers, or use built-in MAUI features that make them unnecessary.
• Replace controls that MAUI 10 deprecated, such as ListView and TableView, with CollectionView.
• Test on current devices, including Android devices with 16 KB page sizes.

3 reasons to choose a native UI (and when not to)

This page used to argue that Xamarin Native always produced better apps. A fairer version for 2026:

• Platform-exact UI. A native UI with .NET for iOS and Android matches each platform’s design and behavior with no translation layer. Choose it when platform fidelity is the product.
• Fewer abstraction surprises. Complex, platform-specific screens are often simpler to build and debug without a shared layer in between.
• Possibly smaller apps. Without the MAUI controls library, a native .NET app can be smaller, though both still carry the .NET runtime.

When not to: if your app is mostly forms, lists and data, if you need Windows or macOS desktop builds, or if your team has C# skills but little iOS and Android experience, .NET MAUI will get you to a good app faster and cheaper.

Best courses to learn .NET MAUI and C# mobile development

Checked live in October 2026.

See the C#/.NET Bootcamp at Zero To Mastery →

Most Xamarin-era courses on Udemy and elsewhere teach Xamarin.Forms and have not been updated for MAUI, so check a course’s last-updated date before buying. For broader options, see our guide to mobile app programming languages and our comparisons of React Native vs Xamarin, Xamarin vs Flutter and Xamarin vs Ionic.

Conclusion

Xamarin Native vs Xamarin.Forms was a choice between native UIs per platform and one shared UI. That choice survives in modern .NET as .NET for iOS and Android vs .NET MAUI, while Xamarin itself is retired and can no longer ship store updates. For most apps, MAUI’s shared UI is the faster, cheaper and easier-to-maintain option. Pick native .NET UIs when platform-exact design or heavy platform-specific work is the core of the app, and remember you can combine both in one MAUI project.

Frequently asked questions

What is the difference between Xamarin Native and Xamarin.Forms?

Xamarin Native (Xamarin.iOS and Xamarin.Android) required a separate C# user interface for each platform, sharing only business logic. Xamarin.Forms added a shared UI written once in XAML or C#, which it mapped to native controls on each platform.

Is Xamarin.Forms still supported?

No. Microsoft ended support for Xamarin.Forms and all other Xamarin SDKs on 1 May 2024. Its successor is .NET MAUI.

What replaced Xamarin Native?

Xamarin.iOS and Xamarin.Android became .NET for iOS and .NET for Android, which are part of modern .NET and use SDK-style projects. The programming model is the same: C# with full access to each platform SDK.

Is .NET MAUI the same as Xamarin.Forms?

It is the evolution of Xamarin.Forms. The concepts and XAML are similar, but MAUI uses a single project, replaces renderers with lighter handlers, adds macOS and Windows desktop, and deprecates some Forms controls such as ListView in favor of CollectionView.

Can a .NET MAUI app use native platform code?

Yes. MAUI apps can call iOS and Android APIs directly from the shared project, include native views, and use platform-specific folders, so you are not limited to what the shared controls offer.

Should I migrate a Xamarin.Forms app to .NET MAUI or rewrite it?

Migrating to .NET MAUI is usually faster because your C# logic and much of your XAML carry over. A rewrite in another framework can make sense if the app is small, its UI is being redesigned, or key third-party packages never moved to .NET MAUI.

Can I still update a Xamarin app on Google Play?

Not with a standard Xamarin toolchain. Google Play requires apps to target Android 15 (API 35) or higher, and Xamarin stops at API 34. From 1 February 2027, Play will also block updates that do not support 16 KB memory page sizes.