Introducing .NET Multi-platform App UI

Scott Hunter [MSFT]

You can build anything with .NET. It’s one of the main reasons millions of developers choose .NET as the platform for their careers, and companies invest for their businesses. With .NET 5 we begin our journey of unifying the .NET platform, bringing .NET Core and Mono/Xamarin together in one base class library (BCL) and toolchain (SDK).

As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS. To address this need we are excited to announce a new first-class UI framework for doing just that: .NET Multi-platform App UI, affectionately called .NET MAUI.

Let us introduce you to what .NET MAUI is, the single project developer experience, modern development patterns, and a look at the journey ahead.

MAUI overview

What is .NET MAUI

.NET MAUI is an evolution of the increasingly popular Xamarin.Forms toolkit that turns 6 years old this month. For years companies such as UPS, Ernst & Young, and Delta have been leveraging the mobile expertise of Xamarin atop .NET to power their businesses; some since the very beginning. It has also been very successful in helping small businesses maximize their development investment sharing upwards of 95% of their code, and beating their competitors to market. .NET MAUI extends this success on mobile to embrace the desktop making it the best way to build multi-platform applications across both, especially our new devices such as the new Surface Duo.

.NET MAUI simplifies the choices for .NET developers, providing a single stack that supports all modern workloads: Android, iOS, macOS, and Windows. The native features of each platform and UI control are within reach in a simple, cross-platform API for you to deliver no-compromise user experiences while sharing even more code than before.

Single Project Developer Experience

.NET MAUI is built with developer productivity in mind, including the project system and cross-platform tooling that developers need. .NET MAUI simplifies the project structure into a single project to target multiple platforms. This means you can easily deploy to any target that you wish including your desktop, emulators, simulators, or physical devices with a single click. With built-in cross-platform resources you will be able to add any images, fonts, or translation files into the single project, and .NET MAUI will automatically setup native hooks so you can just code. Finally, you will always have access the native underlying operating system APIs and it will be easier than ever with new platform specific integrations. Under platforms you can add source code files for a specific operating system and access the native APIs. With .NET MAUI everything is in one place where you need it to keep you productive.

.NET MAUI Single Project

This delivers:

  • One project targeting multiple platforms and devices
  • One location to manage resources such as fonts and images
  • Multi-targeting to organize your platform-specific code

You master one way to build client apps, the .NET MAUI way, and all platforms are within your reach. Today, Scott Hanselman and I will demo it in action at Build, The Journey to One .NET.

Modern App Patterns

Part of the vision for one .NET is providing developer choice in the areas of personal preferences so you can be most productive using .NET. This manifests in which IDE you use whether Visual Studio 2019, Visual Studio for Mac, or even Visual Studio Code. .NET MAUI will be available in all of those, and support both the existing MVVM and XAML patterns as well as future capabilities like Model-View-Update (MVU) with C#, or even Blazor.


Model-View-ViewModel (MVVM) and XAML, the predominant pattern and practice among .NET developers for decades now, are first-class features in .NET MAUI. This will continue to grow and evolve to help make you productive building and maintaining production apps.

    <Label Text="Welcome to .NET MAUI!" />
    <Button Text="{Binding Text}" 
            Command="{Binding ClickCommand}" />
public Command ClickCommand { get; }

public string Text { get; set; } = "Click me";

int count = 0;

void ExecuteClickCommand ()
    Text = $"You clicked {count} times.";


In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern. MVU promotes a one-way flow of data and state management, as well as a code-first development experience that rapidly updates the UI by applying only the changes necessary. For more information about MVU as a pattern, check out this Elm Programming guide and this blog from Thomas Bandt.

Below is a basic counter example in the MVU style written in .NET MAUI.

readonly State<int> count = 0;

View body() => new StackLayout
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)

This pattern is ideally suited for hot reload as you can see below with added styling, gradients, and fonts with instant hot reload from C#.

MAUI model-view-update

Both MVVM and MVU deliver the same native applications, performance, and platform fidelity. Developers will be able to choose which style best suits their preference and use case.

Transitioning from Xamarin.Forms to .NET MAUI

Xamarin.Forms developers will hit the ground running with new projects in .NET MAUI, using all the same controls and APIs they have grown to know and love. As we get closer to the .NET MAUI launch, In order to help developers make a smooth transition of existing apps to .NET MAUI we intend to provide try-convert support and migration guides similar to what we have today for migrating to .NET Core.

The .NET MAUI Timeline

We will begin shipping .NET MAUI previews later this year, and target general availability with .NET 6 in November of 2021. .NET MAUI will ship on the same 6 week cadence that Xamarin.Forms has been on. We have published the .NET MAUI roadmap on GitHub and invite you to join us there today!

What’s Next for Xamarin and Xamarin.Forms

As part of our .NET unification, Xamarin.iOS and Xamarin.Android will become part of .NET 6 as .NET for iOS and .NET for Android. Because these bindings are projections of the SDKs shipped from Apple and Google, nothing changes there, however build tooling, target framework monikers, and runtime framework monikers will be updated to match all other .NET 6 workloads. Our commitment to keeping .NET developers up-to-date with the latest mobile SDKs is foundational to .NET MAUI and remains firm. When .NET 6 ships, we expect to ship a final release of Xamarin SDKs in their current form that will be serviced for a year. All modern work will at that time shift to .NET 6.

Xamarin.Forms will ship a new major version later this year, and continue to ship minor and service releases every 6 weeks through .NET 6 GA in November 2021. The final release of Xamarin.Forms will be serviced for a year after shipping, and all modern work will shift to .NET MAUI.

Get Involved Today

Join us on this journey to .NET MAUI at our brand new repository dotnet/maui. Be sure to star and watch to get notifications, then join in the discussion of proposals describing how we want to evolve the code base. This is the very beginning of a long journey welding Xamarin and Xamarin.Forms directly into the heart of .NET, and we are excited to do this in the open with you.


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

    • Immo LandwerthMicrosoft employee 0

      Sorry about that, just made it public.

      • André Ziegler 0

        thanks, it works now.

  • Jason Kuo 0

    Will this be AOT or JIT?

    • Ben Funk 0

      Fingers crossed that the answer is both, and that AOT on Android isn’t tied to ridiculous edition requirements like it currently is (Enterprise only, even though Pro subs could really benefit from it).

    • redthMicrosoft employee 0

      iOS will continue to require AOT on devices (a limitation of the platform itself) but we will also be enabling interpreter support. Android already provides support for JIT as well as Full/Hybrid AOT and will continue to do so as well as also enabling interpreter support in the future.

  • Manuel Sidler 0

    What about F# support?

    • Jordan Marr 0

      MVU pairs more naturally with F# (as exemplified in the referenced Thomas Bandt blog above), but still glad to see it has made its way to C# so that it can finally gain a broader acceptance.

      • Manuel Sidler 0

        Good point. Thanks Jordan!

      • Isaac Abraham 0

        Looks nice, but in the case of the sample above, the “M” in “MVU” would stand for “Mutable” I guess…

        • William Kempf 0

          I also see no U in that example. Granted, this was a throw away blog post and not necessarily a real example, but based solely on that code snippet they seem to have no clue what MVU is. Here’s to hoping I’m wrong.

    • saint4eva 0

      F# Fabulous got its inspiration from a C# project by Frank Krueger.

    • James MontemagnoMicrosoft employee 0

      .NET MAUI will absolutely support F#

      • Brett Rowberry 0


  • Mike-E 0

    Web? Blazor? Flutter has a single model that reaches all platforms whereas it sounds like .NET still has two: web and everything else. Nice to see the effort, though. Maybe by the time .NET 17 rolls around we’ll finally be where Flutter is today. 😁

    • Krio 0

      Have you tried flutter on the web? Lol. They don’t have anything there either yet.

      • Matthew Heimlich 0

        Flutter on anything that’s not a phone is garbage right now

        • Mike-E 0

          Same was said of XF v1 (and beyond), yet here we are.

      • LC 0

        I actually made a web app in Flutter and was impressed with its speed and ease of use. I’m also in the process of targeting web in a fairly large Flutter app I’ve been working on.

    • Steven Sagaert 0

      That already exists: Basically the .NET equivalent of Flutter. This is a competitor to Xamarin Forms/MAUI but it’s a lot less known.

      • Shimmy Weitzhandler 0

        TBH, actually Uno seems far more attractive and relevant than MAUI, from every aspect. MAUI is a disappointment to me.

        And Uno is indeed a far better competitor to Xamarin.Forms, but don’t forget that it’s actually using Xamarin.Android and Xamarin.iOS, so not a total competitor.

        It actually terrifies me and saddens me that Xamarin.Forms is going to become part of the .NET Core.

        • PandaSharp 0

          +1 Start from the XAML dialect used UWP/WinUI XAML instead of XF XAML

        • Mike-E 0

          Indeed, I have never been impressed with XF’s design and it is disheartening to see that it is being “chosen” to “lead” the “future” here. :p The design/style choices here between it and Blazor/ASP.NET Core (which I think are amazing BTW, HTML aside) are night and day.

          If you could somehow evolve the syntax of Blazor Mobile Bindings but make it also generate HTML/web components (like Uno does), then you could start talking about a winner. I have yet to see anything close to that, however.

          And yes, Uno knows their stuff, too!

      • Vincent Thorn 0

        Unfortunately UNO works only from Windows 10 (because requires Windows 10 SDK, which doesn’t install on Win7). So HALF of all world’s PC are “cutted off” from MS “paradise of unified UI”. But I can say it different way: MS again pushes people on Windows 10, while A LOT of people even don’t plan to use buggy Win10 and still prefer Win7, so for millions people “MAUI” is just another USELESS M$ try to unify something.
        MS follows ridiculous ways EACH of ’em leading to idiotic Win10. Forget it. Stop it. WE NEVER COME TO WINDOWS 10. Period. Return back and rethink how much resources you WASTE on “10”, which could be used to improve “7”.

        • Alex DaSwagga Dresko 0

          I created an account here just so I could LOL at this guy.

          • Eduard Kagan 0

            I had to add a +1. So many clowns around.

          • PandaSharp 0

            I already had one, but you deserve a +1

          • 0

            There is no reason to laugh about the privacy nightmare that Windows 10 still constitutes.

            With a lot of effort you can disable all the tracking and data collection in the Enterprise version, but not in Professional nor Home.

            MS should finally respect the choice of their users who do not want to share their private data.

        • Ian Marteens 0


        • Matthew Heimlich 0

          I cringe for whatever organization you work for

        • 0

          There is no reason to laugh about the privacy nightmare that Windows 10 still constitutes.

          With a lot of effort you can disable all the tracking and data collection in the Enterprise version, but not in Professional nor Home.

          MS should finally respect the choice of their users who do not want to share their private data.

        • Wil Wilder Apaza Bustamante 0

          this comment has been deleted.

        • Gavin Williams 0

          Haha. I haven’t seen Windows 7 for a very long time.

          It’s cool though that you guys are all still hangin’ out and celebrating the old operating systems.

      • Derek Ziemba 0

        That does look really nice!

        It’s unfortunate they didn’t choose a more googleable nnam though.

        Is there by any chance a web browser control to view external pages in app?

    • idchlife idchlife 0

      Pfft, flutter is an outlandish platform desperately trying to win the market, buying reviews and gathering semi-successfull developers here and there.

      I’m here, doing Android + iOS crossplatform UI with Xamarin Forms, utilizing best of both platforms for my needs: underneath in Xamarin iOS project I use CoreML features, I create SceneKit visuals and all that with wonderfull C# language.
      For Android I can create either OpenGL or use cross platform solution like Urho3D.

      Good luck accessing native features of your devices in Flutter as well as it s wonderfully done in Xamarin Forms + Xamarin Native underneath.

      I’m doing serious stuff with the help of Xamarin. I’m not sure that Flutter is capable of that.

      • Mike-E 0

        No doubt about Xamarin’s native integration, but that is not the issue here nor the point I made above. 🙂 The issue is the expensive divide that .NET development faces in having two development models rather than one, which Flutter has successfully established and will only improve upon as time progresses. Lest we forget that a lot of resources currently working on Flutter used to work at MSFT but moved over to GOOG as it was really the only way to make progress. The irony.

        • Wil Wilder Apaza Bustamante 0

          this comment has been deleted.

        • idchlife idchlife 0

          The irony 😀

          Well you are trying to pinch Xamarin comparing it to a toy 🙂

          You can talk about development politics and tech corporation propaganda wars whatever you want, but in the end – if you want fancy html5-ish canvas drawn app without strong backup for native integration on each device and a huuuuge mature ecosystem of libraries and history of magnificent developers developing fantastic solutions – you choose Flutter.
          If you want to be serious – you choose Xamarin Forms/Xamarin Native.

          I’m not afraid of double coding to tweak for each platform for app to be the best, because I don’t tend to whine and lean to the young technologies trying to capture the market because corporation told them to conquer the world with fancy tutorials and words and what… number of developers? Pffft

          I feel really, really sorry that Dart did not conquer the browser JavaScript market at the time, but it’s not the time for it to shine seriously either. Anyway, good luck with playing, little brother Flutter. You here to stay, but not to be taken very seriously.

          • Mike-E 0

            That really had nothing to do with calling attention to the expensive dichotomy that currently exists in .NET client application development which is my whole central point and not anything specific to Flutter/Xamarin/Dart/JS/politics, but OK. 🙂

    • saint4eva 0

      You complain a lot. If you do not like it, kindly go for flutter.

      • Mike-E 0

        Are you… complaining about my complaining? I “complain” because I pay attention, and care.

        • Super Duper 0

          Really? Espousing the greatness of a half completed development platform that is more costly to develop in than XFs? Doubtful!

          • Mike-E 0

            Greatness? No, efficiency. In the case of starting a company and hiring application development resources, I only have to hire one type of developer with Flutter: a Flutter developer. In the case of .NET, I am now at the moment and for the foreseeable future required to hire two: a .NET web developer and .NET native app developer (iOS/Droid/Windows). I cannot efficiently “share” resources between web and native. Friction and time will incur any time a developer has to “switch” to web mode and vice versa.

            Inefficient and therefore expensive.

            I get that Flutter is v1, but GOOG’s pockets are pretty deep — not to mention loaded with former MSFT developers that have a chip on their shoulder — and how long do you think it’s going to take before v3 or v4 is here and that is no longer a viable argument? Shortsightedness is also an inefficiency.

      • TD 0

        You complain a lot. If you do not like it, kindly go for React Native
        Skype, Microsoft’s Teams: OK, We did!

    • Cory Crooks 0

      Yes this. This, this, a thousand times this. We were shown experiments last year using Blazor as the “mvu” framework for both flutter and ahem xamarim forms. But now it’s going to be this c# code thing without an angle bracket in sight? What?

      • Cory Crooks 0

        Ah, I see now looking at the repository it mentions “app models” as “MVVM, RxUI, MVU, Blazor”… so I’m guessing the Blazor stuff we saw a few months ago is moving forward? I guess that what was meant by the blazor mention in the article?

        • Mike-E 0

          Your guess is as good as mine, as Blazor isn’t an “App Pattern” but more of a framework application development model? shrug Regardless, I stopped taking anything out of MSBuild conferences seriously ever since the Xaml Standard disaster. Trust but verify, fool me twice shame on me, etc etc.

  • Philipp Ertel 0

    Will this also be available for linux?

  • olcay seker 0

    As expected, no Linux. Meh,

    • Charles Roddie 0

      Xamarin.Forms already has had a Linux target for several years. If you want to improve it you can contribute. It’s crazy that Linux advocates, whom you would expect to advocate open source, are instead expecting a big corporation to do the work for them.

      • Wil Wilder Apaza Bustamante 0

        this comment has been deleted.

      • Daniel Hughes 0

        The Xamarin.Forms linux target is pretty much useless, let me explain why.

        It uses GTK2 which very, very old GTK3 is the current and GTK4 is soon to be released.

        It only works on classic .net/mono it has no support for dotnet core, for me this makes it a non starter.

        There is no IDE support for it on linux, Microsoft has abandoned MonoDevelop, and there is no xaml support there. vscode is all about .net core and has zero tooling for Xamarin.Forms. This means you cannot develop/debug for linux desktop on linux 🙁

        Microsoft claims that Xamarin.Forms linux is maintained by the community, in reality it is not maintained at all, (thats why there is no GTK2 support and no .net core/vscode support)

    • Lars Bruins Slot 0

      This is false. If you read the ReadMe on github it clearly states linux is supported. Community provided support that is but I think that would fit the linux community best anyways.

      • Daniel Hughes 0

        No, Microsoft claims that it is supported by the community, this is just wishful thinking at this point, Xamarin.Forms linux is stuck on the ancient GTK2, doesn’t support .net core and has no linux IDE or tooling support.

        This is because it isn’t actually maintained by the community, it not maintained at all.

  • Krio 0

    Really excited for this. Xamarin seems to have lagged a bit behind other offerings in recent years and I’ve had to avoid it. With the unification of .net this year it seems like we are getting some great stuff.

  • Shimmy Weitzhandler 0

    Thanks for sharing!

    • Does it have WASM support?
    • Does it use standard MS WinUI XAML, or is it another XF XAML?
    • Will I have to tweak each target individually or will it render everywhere the same by default?

    MAUI aka Xamarin.Forms as part of .NET Core is sad news to me.

    • PandaSharp 0

      +1 for Does it use standard MS WinUI XAML, or is it another XF XAML?

      I prefer UWP/WinUI XAML but unfortunately from the screenshot looks like XF XAML

    • Farr, Derek 0

      +10000 for not using XF XAML

      WPF XAML or what was going to be XAML Standard would be best.

    • David OrtinauMicrosoft employee 0

      Hi Shimmy,

      WASM – not on our roadmap at this time. As with all platforms, we guide our support based on developer demand and required device targets. It would help our research to know more about your needs and expectations for WASM.

      XAML – As an evolution of Xamarin.Forms, we continue to use the same XAML.

      Tweaking – we are continuing to work on enabling consistency across multiple platforms so when you do not want platform distinction you can adopt consistency. Material renderers are a step in this direction for controls like Button, Entry, Editor, Frame, etc.

      • Sébastien PEROT 0

        it seems that people would prefer an revolution rather than an evolution, and prefer the xaml from wpf/uwp
        i don’t use xamarin because i can’t simply put a panel in a button, and other cool stuff in wpf/uwp …

      • Wil Wilder Apaza Bustamante 0

        this comment has been deleted.

    • Wil Wilder Apaza Bustamante 0

      this comment has been deleted.

  • Halid CisseMicrosoft employee 0

    Great news!
    I would prefer a simpler catchy naming that is consistent and easy to pronounce like .NET UI.

    • saint4eva 0

      Or SharpUI 😊😊

      • anonymous 0

        This comment has been deleted.

    • Anand C 0

      Yes. Even I would prefer simpler name like .NET UI or Xaml UI.

    • Dominic Brühwiler 0

      Was my first thought… the name sounds really strange. All the suggestions here would match much better 🙂

    • Okhakumhe Gideon 0

      The name sounds like that of a Cow I know .

      • 0

        It’s an island…

        , same as Java, which is what I suspect inspired this name.

  • Petru Cervac 0

    Sounds great

Feedback usabilla icon