The New .NET Multi-platform App UI

David Ortinau

With .NET 6 previews starting right around the corner, it is time to start getting excited for the new .NET Multi-platform App UI (MAUI) that was announced at BUILD 2020. This year of .NET has a lot of amazing things for client application developers. Let’s review the highlights and set your expectations for the year ahead.

.NET 6 planning and execution is happening in the open, and we have a beautiful website that summarizes our GitHub epics and user stories across all of .NET. Visit and search on Xamarin to see the high-level details.

.NET 6 and Mobile SDKs

At the heart of this release is the unification of the Xamarin SDKs into .NET. Xamarin has always been a part of .NET, but now it ships as a core workload, shares the same base class library as other workloads like Blazor, and adopts the modern SDK Style project system for consistent tooling experiences. No longer is Xamarin some other thing that is like .NET or has some dependency on .NET, but it IS .NET. This will be made clear as you see the naming aligned in our documentation and product pages as we approach release.

Xamarin.Android and Xamarin.iOS are now additional platform targets you can reach with .NET, so we will refer to them as .NET for Android and .NET for iOS. Those SDKs themselves are .NET bindings to the native SDKs from Google and Apple respectively, and thus no renaming takes place in their API surface.

.NET Multi-platform App UI (MAUI)

.NET MAUI is the evolution of Xamarin.Forms, a cross-platform mobile first framework for Android, iOS, and UWP. Building upon 7 years of experience supporting customers from independent developers to some of the world’s largest companies, we are improving the core of the product, speeding up UI rendering, investing in consistent design systems, and extending from mobile to desktop.

For Xamarin.Forms customers, think of this as the next major version of the same product you know today. For developers new to multi-platform development with .NET, we invite you to take a look at what we are doing to serve you.


Since mid-2020 the core team has been focused on high impact issues in the product, and design the new control architecture to set you up for future success. With Xamarin.Forms 5.0 representing the last major feature release before .NET MAUI, the only work happening there are bug fixes. Xamarin.Forms will continue to receive service releases through November 2022.

There are no new controls planned for this release; our focus is being invested into the heart and soul of the product. We get excited about new features just like you, and for that, we are very pleased to see such a positive response to the Xamarin Community Toolkit which launched 1.0 alongside Xamarin.Forms 5.0 and includes an already impressive set of controls and tidbits.

As you look at the dotnet/maui repository, you’ll notice a much leaner folder organization that makes use of multi-targeting and has a much more consistent naming scheme as compared to Xamarin.Forms. We hope this will be a great benefit to contributors looking for just the right place to make their impact. Active development today is happening in the main-handler branch of the xamarin/Xamarin.Forms repository, and then synced to dotnet/maui.


There are several points in an application where performance can be a critical quality issue, including app startup and UI responsiveness. We have made great progress with AOT, Startup Tracing, and fast renderers to help address these issues. In .NET MAUI we have several tasks that will benefit performance, not least of which is .NET 6 itself!

The new handler architecture in .NET MAUI removes view wrapping, thus reducing the number of UI controls needed to render a view. It also fundamentally decouples the platform controls from the framework itself. In Xamarin.Forms each renderer has a reference to the cross-platform element and often relies on INotifyPropertyChanged to work. Rather than using these renderers, .NET MAUI introduces a new pattern called a handler.

The relationship between the framework and the platform is now inverted, and all the platform control needs to do is handle the needs of the framework. Not only is this more efficient, but much easier to extend or override when needed. Gone will be the days of needing to create custom renderers or effects (though we have made sure those all still work too).

The new architecture also makes the platform handlers much more suitable for reuse by other frameworks such as Fabulous, and experiments like Comet and Blazor. We always have our eyes on the future!


The design requirements for applications that target multiple platforms have changed over the years. In the early days of Xamarin.Forms, most customers wanted their Android app to look very Android, and iOS app to look very iOS. We have introduced in Xamarin.Forms more and more styling and controls that look the same across platforms, and added the Visual control API along with Material Design components for iOS to match what you get on Android. These efforts went part of the way towards satisfying what customers have shown us they require, and in .NET MAUI we are laying the foundation to go even further.

Fluent UI Button

We are enabling full-app themes through styling for Fluent UI and Material Design, filling out the existing controls with the necessary styling APIs and visual states, and adding support for control templates as we are able (see RadioButton for a recent example of this).

On the experiment front, we also have kicked off a new Visual strategy that uses a combination of native controls and drawn controls. We will have more information to share about that later this year. For customers needing the 1:1 design across platforms and looking for even better performance, but also having a requirement for native platform support, we think this will be on target.


.NET MAUI is embracing Android, iOS, macOS, and Windows in .NET 6. We are excited to see what you will build for mobile and desktop! Beyond that, we are also working hand-in-hand with the Blazor team to enable Blazor Desktop in .NET 6.

The Xamarin pedigree is deep in mobile, and that’s certainly where the majority of customers have used it. Xamarin.Mac exists today as the .NET binding to AppKit, Apple’s desktop platform. In .NET 6 this is now referred to as .NET for macOS, however, we see Apple going a different direction for macOS desktop development and we want to make sure we give you the very best experience. For this we are introducing .NET support for Mac Catalyst, a solution from Apple that brings your iOS app built with UIKit to desktop, and augments it with additional AppKit and platform APIs as needed. You can explore several of Apple’s first-party apps to experience this yourself. .NET MAUI will use this approach in .NET 6.

When UWP was targeting Windows Mobile, Xamarin.Forms added a mobile-centric implementation with UWP. In .NET MAUI we are bringing stronger desktop-focused support with WinUI 3 Desktop, the very latest way to build great apps from our Windows team partners. When it comes to UWP and WinUI as it relates to .NET MAUI, the main question we are asked is what “flavor” of XAML will be used in .NET MAUI. Because .NET MAUI controls are multi-platform abstractions rather than Windows-only controls, and because we have a massive catalog of Xamarin.Forms customers with knowledge and projects to bring forward, we are continuing forward with the same “flavor” you have in .NET MAUI.

Single Project

One of the most exciting things we announced with .NET MAUI is the Single Project experience. We find that developers are most productive when doing tasks in the .NET Standard library project rather than bouncing between Android, iOS, macOS, and Windows projects where you need to navigate the idiosyncrasies of each platform.

As part of this experience, we are unifying many experiences such as fonts and image management, and reducing reliance on the complexity of managing multiple platform projects. For developers that enjoy or require multiple platform projects, that’s still supported too!

.NET Hot Reload

One of the biggest productivity boots for .NET developers in the past few years has been the introduction of XAML Hot Reload. As you make changes in XAML, updates are pushed to your running applications, and you get to avoid the tedious build and deploy cycle that interrupts and distracts even the most seasoned developer. In .NET 6 we are expanding this success to C# and introducing it to other workloads as well. We can’t wait for you to experience this later in the year.

Getting Ready for .NET 6 and .NET MAUI

I hope you’re excited about one or more of these highlights. They come directly from talking to customers like you, and we’ve prioritize these themes for the .NET 6 release. If you don’t see updates you’re hoping for, let us know as we will be shortly planning .NET 7 and beyond.

To help you consider what you can be doing to get ready, I’ll share here some frequently asked questions and some replies.

Should I use Xamarin.Forms today, or wait for .NET MAUI?

Use Xamarin.Forms! You’ll have a migration path to .NET MAUI when everything is ready.

What is the migration path from Xamarin.Forms?

First, you do NOT need to rewrite your application. The first step will be to update your project and solution files to use the standardized SDK Style. You’ll then update the namespace from Xamarin.Forms, and update your NuGet packages. Any obsolete or deprecated APIs should be updated at this time since this is a major version release. That’s it!

You may then choose to migrate custom renderers to the new handler architecture in order to reap all of the performance gains possible. This may be done at your own pace.

Before migrating be sure to explore .NET MAUI in a new project.

Will my custom renderers work?

Yes, we are providing adapters to enable renderers to work side-by-side with the new handlers, however, you should consider updating to handlers in order to reap the performance gains. Plus, it’s a lot less code to maintain.

What’s going on with VS Code, Comet MVU, and Blazor Mobile Bindings?

These are experiments at this time as we iterate on them. Check them out here:

We look forward to sharing more about these projects later in the .NET 6 preview cycle and getting your feedback.


Discussion is closed. Login to edit/delete existing comments.

  • Kürşat Konak 0

    I think instead of rushing to make things more complex, Microsoft should focus on solving Xamarin Forms platform problems. There are issues not resolved for 3 years now, its not funny. Needing custom renderers being the only solution (hack) to even some basic problems / requirements is not that productive at all. At this time there are 2.8k issues on Github.

    • anonymous 0

      this comment has been deleted.

    • Ferhat Macak 0


    • David OrtinauMicrosoft employee 0

      Where are you seeing additional complexity?

      We are moving forward with the same set of controls and layouts, not adding new features so we can focus as well on the fundamentals, all while reducing the complexity of tight coupling of renderer to framework and the heavy reliance on custom renderers and effects. Perhaps review the architecture of the mappers/handlers. There are several presentations showcasing this on YouTube.

      Also, don’t underestimate the value of unification with .NET 6 in terms of a consistent BCL, SDK style projects, and more.

  • Iain Stanford 0

    For those of us who are not Forms developers and do everything in Xamarin Native, can we just happily continue to work like that with using .Net 6 onwards and have our Core, iOS and Android projects using Xamarin Native directly and ignore MAUI?

    • Nathan Williams 0

      From what I understand Xamarin Native is being merged into .NET itself, and then MAUI builds on top of .NET in the same way Xamarin.Forms builds on top of Xamarin Native. So your migration paths are:

      netstandard -> net6.0
      Xamarin.iOS -> net6.0-ios
      Xamarin.Android -> net6.0-android
      Xamarin.Forms -> MAUI

      • Iain Stanford 0

        I guess my concern is I feels there’s been a lack of clarity from the Xamarin/Microsoft Team itself over its commitment to Xamarin Native on its own. Its always about Forms/MAUI.

        My worry is that sometime in the future there will be restrictions on how you use netX.0-ios and netX.0-android that require you to buy in to MAUI framework.

        I’m yet to see a an article, announcement or comment from Microsoft that basically says, ‘MAUI will always be optional’

        • Charles Roddie 0

          Clearly MAUI will be optional because it depends on Xamarin.Android/Mac/iOS and WPF/UWP/etc. to deploy to platforms, just as Xamarin.Forms does.

          Xamarin.Native isn’t being merged into the .Net runtime (which wouldn’t make any sense) but MonoVM has been merged in, and you can see in the Xamarin.Android and Xamarin.MacIOS repos a lot of work to update to dotnet6 which will bring huge improvements.

  • Michael Dietrich 0

    I have seen that the GitHub issue that related to the wish to align the XAML dialects was closed with the reason that a servey has shown that the majority of developers wish to not align it. I have never seen any servey.
    Too bad this was the only chance to align the dialects, once and for all for easier transition from/to WinUI/WPF. For devs coming from Xamarin it’s a breaking change anyway, namespaces need to be adjusted at least.
    But with this decision being now settled, the difference in the dialects will stay forever.. unfortunately this is really disappointing.

    • Stevie White 0

      Agreed on this one, I never saw such a survey either and it’s very disappointing.

      I don’t mean to insult the efforts of the hard-working people at Microsoft, but this continued scatter brained, halfhearted approach to solving the problems with XAML’s messy eco-system are not very reassuring. I think a lot of people would appreciate it if you could do something far more ambitious instead of just making a new Xamarin. For example, a lot of the Windows specific developers seem to still be yearning for a true successor to WPF that can handle the cross-platform dream (I am not one of those, but I would like to see WPF get an improved successor or face lift). Yes, there is Avalonia, but that isn’t an official MS product, so I do not see the buy in level being that strong 🙁

    • Charles Roddie 0

      It’s not closed; there is such an issue in MAUI discussions. When it comes to XAML they should just leave it to the community. The core of MAUI/Xamarin is .Net types and XAML is just one projection of that. But if they type don’t match (and why should they), then you’d be very unlikely to want the XAML to match.

      • David OrtinauMicrosoft employee 0

        The customer research informing our plans for XAML features and control naming is more than a single survey. It’s 7 years of platform feedback, 1:1 developer and customer interviews, market research, and (yes) multiple surveys.

  • Seyyid Ahmed Çiftçi 0

    The basic idea is absolutely correct, what I just think is a shame is the timing. For 7 years, the Xamarin team has barely lifted a finger to really expand the platform. Of course there were always little things, but without them the community would escalate. I think it’s a shame that a React Native and Flutter were necessary before you realized that you were on a sinking ship.

    The whole thing was promised actually pushed with .NET 5. A uniform .NET. The whole thing was postponed a year, which can be done, but then please use the time for more meaningful things.
    New control elements should not come with the version. One of the biggest problems with XF is its limitation. Furthermore, the complexity and working method should be questioned.

    A piece of advice from me that comes really deep from the heart. Put your project aside. All of you developers. Download Flutter and learn. Then you will know exactly what is still missing and that this gap cannot be reached with Maui. Much more must be needed. Xamarin is losing more and more parts of the community to other platforms and rightly so.

    • Boris Krit 0

      Agree, sad that it true

    • Tony Gomez 0

      Or react native! Proven.

  • Paulo Pinto 0

    By deciding to keep a fork in XAML you just made Uno more attractive to those of us on Windows wanting to go cross-platform with .NET.

    I really don’t get modern Microsoft where the cross platform offerings for C++ and .NET offered by third parties are more welcoming to us.

    It is hardly to keep believing, when we keep being told just to rewriting everything.

    • David OrtinauMicrosoft employee 0

      If a Windows/centric XAML dialect is a key factor for you, then it makes sense that Uno Platform would be attractive.

      What are you anticipating rewriting? Xamarin and Xamarin.Forms -> .NET MAUI does not require a rewrite.

  • Francisco 0

    To be a true multiplatform framework, Linux support is necessary and, above all, support to be able to generate a web application. Regarding this last point, I am referring to generating an application that works within a browser using WebAssembly, without using HTML or CSS, only using XAML and C#. Companies that have been working with desktop technologies for years (WinForms, WPF, UWP, etc.) do not want to have to use / learn any of the web-related technologies (HTML, CSS, JavaScript, etc.) because this supposes us more investment and learning time and a very inefficient development team management, because I cannot reuse the knowledge of backend programmers on the frontend and vice versa. The option to use Mobile Blazor Bindings is not the most optimal because HTML and CSS have to be used in the view and also Razor. Ideally in view is to use XAML, C# and the MVVM pattern. In short, .NET MAUI should do the same thing that the UNO Platform does.

    • David OrtinauMicrosoft employee 0

      Linux and Web are on our radar even though you don’t see them here in our .NET 6 investment. We are actively gathering specific customer plans around those platforms, so please email me additional details so we keep them in mind.

      • Alexey Leonovich 0

        I’ve wrote you some details about our company software and expectations regarding MAUI.
        Email was sended more than 2 days ago – still no response..

      • Mike Lowery 0

        Curious how far out on the radar is Linux GUI support? I haven’t seen anything in the planning. Being able to write cross-platform desktop applications is huge and would allow C# to start displacing Java on that platform.

  • Peter N. Moore 0

    Still nothing about web. Without it this is nothing but a curiosity.

    • David OrtinauMicrosoft employee 0

      Please shoot me some details about your needs for web in this context so we can keep your scenarios in mind as we plan beyond .NET 6.

  • saint4eva 0

    Comet MVU +1

  • Charles Roddie 0

    This is a brilliant strategy and I’m looking forward to testing previews. Will the best migration for an XF app be 1. migrate to dotnet6 in XF, then later migrate to MAUI, or 2. migrate both at once.

    • David OrtinauMicrosoft employee 0

      I suggest prep your Xamarin.Forms to be on latest 5.x, make sure you’re not using deprecated apis, and where possible replace customer renderers you don’t need. Then upgrade all to .NET MAUI and 6.

      There will be no supported Xamarin.Forms on .NET 6. That’ll still be Framework for a year.

  • Jeff Jones 0

    I am glad to see the progression in multiplatform .NET app development with MAUI and .NET 6.

    The only weak point that stands out to me is the rapid application development (RAD) capabilities. How is it that in 2021 Microsoft cannot even come close to the productivity with a visual designer for XAML (or MAUI) that was a part of Microsoft development 30 years ago. How could Alan Cooper and his small team provide a drag-n-drop designer and all the brains at MS today cannot?

    The concept is still the same. Widgets drag and dropped on widgets hierarchically with properties and events. Whether WinForms, WPF, XAML, or whatever, the principles are still the same. The widgets are no more complex today than then in the context of what is designed on a surface. In fact, one visual designer can be used and coded for the abstract UI elements, with the setting of which UI type determining the specifics.

    I’ve been around long enough, and worked on enough complex projects to know that with the right small team, a real visual designer could be ready in a year – disposing of the half-hearted and brittle attempts at partial functionality like Hot Reload.

    The UI development time for an app using RAD is much faster than hand-coding the UI. Less time and fewer bugs. That advantage sells. It once allowed Visual Basic to dominate the Windows programming world. Bringing back a real RAD visual designer for all UI design in Visual Studio would catapult the C# and .NET development environment even farther ahead – not just on Windows, but on al supported OSs.

    Read how Alan Cooper did it here, if you are interested.

    • Charles Roddie 0

      A drag and drop designer has a lot of drawbacks. Imagine how much cleaning up would need to be done after someone creates a UI this way. And how much maintenance needed, including versioning dependencies, and how this would slow down the progress of the platform.

      disposing of the half-hearted and brittle attempts at partial functionality like Hot Reload

      Hot reload would still be needed because 1. you would still spend a lot of time hand-editing markup, even if it’s only to clean up the results of the GUI, and 2. you still need hot reload for people who don’t use a GUI and people who don’t use markup languages to define UI.

      • Seyyid Ahmed Çiftçi 0

        Charles is right. Even if some designers can make the work easier, programming by hand is always better for high-performance products. HotReload is a must-have here. Currently you have to wait at least 30 seconds for every small change, which can even take 1-2 minutes, depending on the performance of your hardware.

        You always have to distinguish whether easier operation also makes sense. Always consider the usability-performance curve. In any case, there are a lot of points that still need to be improved, as development with XF is currently much more difficult and laborious than with other platforms. That should actually be the first point to work out.

    • Kevin Weir 0

      Jeff you nailed it. The lack of a good/simple visual designer contributed to the slow uptake of UWP. I simply don’t understand how 30+ years after Visual Basic Forms Microsoft can’t come up with a compelling and modern UI designer that abstracts and hides the complexities of XAML. One UI designer to rule them all.

      Choose a template (i.e. mobile, desktop, hybrid) and off you go. Drag and drop from a UI control palette, set properties and respond to events. At the end of the day the UI boils down to a grid system of pixels, where the UI design environment should give you the tools/controls/widgets to paint your Picasso.


      The notion of themes should also be looked at where a global theme could be applied to the application or overridden at the window and control level respectively.

    • Daniel Smith 0

      Completely agree Jeff. A visual designer should be top priority for any UI technology. For those that prefer the tedium of doing it by hand, they’d still have the option to do that, so it’s a win-win for everyone.

      It’s like the situation with the designer being dropped in EF Core. I can scarcely believe anyone writes their contexts by hand. Thank goodness for Erik Jensen’s EF Core Power Tools! I just don’t understand how EF Core doesn’t have such basic necessities built in though.

      Microsoft has some of the best developer talent on the planet, yet creating visual designers seems to be some sort of dark art lost in the mists of time.

      I challenge the team to come up with the next generation experience in visual design that brings back the amazing productivity gains we’ve enjoyed with other technologies over the years!

Feedback usabilla icon