After a long development journey and several delays, Microsoft has announced that .NET MAUI (Multi-platform App UI) will reach general availability next week alongside Visual Studio 2022 17.3 Preview. Having tracked this project since it was first announced at Build 2020, I’m cautiously optimistic — and I emphasize “cautiously” because cross-platform UI frameworks have a long history of promising more than they deliver.
.NET MAUI is the evolution of Xamarin.Forms, Microsoft’s mobile cross-platform framework that has been around since 2014. But MAUI is more ambitious: it targets not just iOS and Android, but also Windows and macOS from a single codebase. It’s built on .NET 6, uses a single project structure, and promises hot reload, modern tooling, and a path forward for the hundreds of thousands of Xamarin.Forms applications already in production.
What MAUI Actually Changes#
If you’ve worked with Xamarin.Forms, MAUI will feel familiar — it’s evolutionary rather than revolutionary. The XAML-based UI definition is still there, the MVVM pattern is still the primary architecture, and the abstraction layer over native controls works the same way conceptually.
The practical improvements are in the developer experience:
Single project structure. Xamarin.Forms required separate platform projects for iOS and Android, each with their own configuration, assets, and startup code. MAUI consolidates this into a single project with platform-specific folders where you need them. It sounds minor, but managing multiple project files was a genuine source of friction and merge conflicts.
Handlers over Renderers. MAUI replaces the Renderer architecture with Handlers — a simpler, more performant mapping between cross-platform controls and native controls. Renderers were one of the most painful parts of Xamarin.Forms development, especially when you needed to customize native behavior. Handlers use a mapper pattern that’s more intuitive and generates less boilerplate.
Blazor Hybrid. This is the sleeper feature. MAUI includes BlazorWebView, which lets you embed Blazor components (web UI built with C# and Razor) inside a native MAUI application. Your Blazor code runs natively — no WebAssembly, no server connection — with full access to native APIs through the host application. For teams that have invested in Blazor for web, this is a compelling path to mobile and desktop.
Hot Reload. Both XAML Hot Reload and .NET Hot Reload are supported, meaning you can modify UI and C# code while the app is running and see changes reflected without restarting. This has been a weak spot for the Xamarin ecosystem compared to frameworks like Flutter and React Native, so it’s good to see it prioritized.
The Competitive Landscape#
MAUI enters a crowded field. Flutter just announced version 3 with six-platform support at Google I/O last week. React Native continues to dominate in mindshare, especially among web developers. Kotlin Multiplatform is gaining traction in the Android-first world. Even Electron, despite its resource overhead, remains the go-to for desktop cross-platform applications.
Each framework has its constituency. React Native has the JavaScript ecosystem. Flutter has Google’s momentum and Dart’s performance story. Kotlin Multiplatform has JetBrains and the Android developer community. MAUI has… the .NET ecosystem.
And that’s not a small thing. There are millions of C# developers in enterprises worldwide. Many of them are building internal tools, line-of-business applications, and customer-facing apps that need to work on multiple platforms. For these developers, MAUI means they can leverage their existing C# skills, their existing business logic libraries, and their existing team expertise without adopting a new language or ecosystem.
The question is whether MAUI can deliver a good enough experience to keep those developers from wandering to Flutter or React Native. Xamarin.Forms had a reputation for rough edges — sluggish performance on Android, limited community components, and an update cadence that lagged behind the native platforms. MAUI needs to break that reputation.
The Migration Question#
For existing Xamarin.Forms applications, migration to MAUI is a necessary conversation because Xamarin support ends in May 2024. Microsoft has published migration guides, and the .NET Upgrade Assistant can automate much of the mechanical conversion.
In practice, the migration complexity scales with how much you’ve customized. Simple apps with standard controls will migrate relatively cleanly. Apps with extensive custom renderers, platform-specific code, and third-party library dependencies will require more work — particularly because not all Xamarin community libraries have MAUI versions yet.
My advice: start your migration planning now, even if you don’t execute immediately. Identify your custom renderers, catalog your third-party dependencies, and test your business logic on .NET 6. The mechanical conversion is the easy part; the hard part is the ecosystem dependencies that aren’t ready yet.
The Enterprise Angle#
Where MAUI might find its strongest footing is in enterprise development. Large organizations running on the Microsoft stack — Azure, SQL Server, Active Directory, Office 365 — have a natural affinity for .NET-based tools. MAUI’s integration with Visual Studio, its support for enterprise deployment scenarios, and its first-class MVVM tooling all align with how enterprise teams work.
I’ve seen this pattern before with WPF. It was never the “cool” choice, but it became the backbone of internal enterprise applications across thousands of companies. MAUI could fill a similar role for cross-platform enterprise apps — not glamorous, but solid, maintainable, and supported by a company that isn’t going anywhere.
My Take#
.NET MAUI is a solid framework for the right audience. If your team lives in the .NET ecosystem, builds business applications, and needs cross-platform reach, MAUI deserves serious evaluation. It’s a meaningful improvement over Xamarin.Forms, the tooling is modern, and the Blazor Hybrid story is genuinely interesting.
If you’re starting from scratch with no .NET investment, I’d still probably recommend Flutter for cross-platform mobile development. The widget library is more mature, the community is larger, and the hot reload experience is slightly better. But “best framework” is always contextual — what your team knows, what your backend looks like, and what platforms you’re targeting all matter more than benchmark comparisons.
The cross-platform framework wars aren’t going to produce a single winner. What we’re getting instead is genuine competition that pushes all the players to improve. And that’s the best outcome for developers regardless of which framework we choose.