Introducing .NET Multi-platform App UI

Scott Hunter [MSFT]

Scott

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.

MVVM

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.

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

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

int count = 0;

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

MVU

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;

[Body]
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.

142 comments

Leave a comment

    • Avatar
      redth

      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.

  • Avatar
    Mike-E

    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. 😁

    • Avatar
      idchlife idchlife

      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.

      • Avatar
        Mike-E

        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.

        • Avatar
          idchlife idchlife

          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.

          • Avatar
            Mike-E

            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. 🙂

          • Avatar
            Mike-E

            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.

    • Avatar
      Cory Crooks

      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?

      • Avatar
        Cory Crooks

        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?

        • Avatar
          Mike-E

          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.

  • Avatar
    Jeff Jones

    Please say there will be a UI designer. MS could provide a designer for WinForms going back 30+years to VB, then VS.NET. That one was not provided for XF is an embarrassment. The productivity gains with a UI designer are immense. Please don’t set RAD IDEs back 30 years with no UI designer.

  • Avatar
    Charles Roddie

    This is great because Xamarin.Forms badly needs a fresh start. It has became unmanageable because of 1. adding an abundance of features without stabilizing existing ones, 2. an extremely complex architecture that makes it very hard to contribute/merge fixes.

    In order to improve on Xamarin.Forms this needs to be subtractive. The current Xamarin.Forms organization will always decide to increase size and complexity at the cost of maintainability, and keep delivering buggy releases as a result. This strategy has made it a maintenance nightmare. This needs to have a higher-level review so that MPAU can be brought to the standard expected of a core .Net repository. Each feature needs to be analyzed to weigh up its benefits against its maintenance implications.

    I would suggest some principles:
    1. Be open, on a case by case basis, to using SkiaSharp renderers rather than platform-specific implementations, to dramatically reduce the amount of code needed to be maintained, and to improve consistency across platforms.
    2. Separate objects and markup. The objects can be defined in a core repo, and markup languages that describe them in others. This reduces the potential for bugs in the core repo as objects are more type-safe. It avoids the craziness that there are 2 markup languages in XF (xaml and css)! Users should not need to work with the markup layer in order to fix bugs in the core layer.
    3. Things that are not MPAU-specific should be removed from MPAU. For example navigation does not need to be in MPAU.
    4. Have type-safety as a priority. That may mean altering the binding framework to one not involving strings and untyped objects.

    We use Xamarin.Forms and the fight against bugs is a huge problem. The amount of effort needed to make a bugfix in the repo is huge so we often gave up. Instead bugfixes are currently made inside user projects (as “renderers”) instead of shared with the community.

    • Avatar
      Emil Alipiev

      Seriously skiasharp everywhere? You want flutter with c#? Why would we need another flutter when there is a native platform alternative. If you want to do skia everything go do flutter. Dart is not so different than c#

    • Michal Dobrodenka
      Michal Dobrodenka

      We were waiting and evaluating Xamarin.Forms several times, last time in 2017. Xamarin.Forms was a little overbloated, buggy and slow (adding 1 sec to Android start). And also missing features – in 2017 there was no CollectionView (is it on all platofrms now?) In the end we decided to make own multiplatform framework which position controls natively – UICollectionView, VirtualizingPanel, RecyclerView and render via SkiaSharp. Right now we target Android, iOS and WPF and we are happy with this solution. We made our “flutter” 🙂 (Together with parametrized vector icons via PaintCode/SkiaSharp it makes a very nice UI development experience)

  • Avatar
    Andrew Leader

    This seems really great, especially the “one project” part! I might even consider re-writing my Xamarin native Android, iOS, and UWP apps to this when it comes out.

    However, I’m not sure about MVU… React’s virtual DOM seems like a much more brilliant idea. In MVU, what if you need to sometimes include or not include a UI component, or need some more complicated logic within constructing the view? For example, if you have a StackPanel that sometimes needs to have 5 items and other times needs to have only 1 item (and they’re different items)? In React, you’d just say “if true, render this, else render that”… but I don’t see how you’d be able to do the same in MVU?

    Or actually is it using a virtual “DOM”? I was looking at Clancey’s implementation of Comet, seems like it does. Seems like you could mix in more complicated code?

    • Avatar
      Max Mustermueller

      You don’t see it mentioned because it’s basically just Xamarin renamed (simplified). Xamarin does not support Linux (officially and under active development). Therefore, no, MAUI won’t have Linux support. Now you ask yourself what’s the big thing then, when you can also just use Xamarin now?! Good question, nobody knows. It may have a better integration into VS or some small differences but it’s neither a new thing nor an evolution.

  • Avatar
    Andrew Beeman

    Really? Xamarin Stack Layout? Come one man. There’s zilch Xam devs solely for that reason. EF/LINQ Lambda are god like for development and then we get trashed on with Stack Layout. The amount of Xam devs alone should tell you that you’re doing it wrong.

  • Avatar
    Anand C

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

    Please include a UI Designer with preview on various Devices (Desktop, Mobile, web with Responsive design) that is targeted by the project.

    In order to have one unified UI Framework, MS should also look at using Xaml as replacement for Blazor components/applications rather than razor syntax with html markup. Let the MSBUILD convert the xaml representation into whatever that’s required to convert them into equivalent html5/css3 standards. There should only one language for constructing the UI that’s Xaml based on WPF style development (all features of WPF including ability to author custom components/controls, triggers, visual state managers, bindings, MVVM…etc)

    • Avatar
      Eduard Kagan

      Dude, no one cares about Windows 7. You’ve got to be out of your mind if you think there are “millions of devs” as you stated elsewhere coding on Win 7. It got end-of-lifed on 01/14/2020, why would MS waste time and resources to support it???

      • Avatar
        justforbuild@outlook.de

        There is still a significant user-base for Win7, obviously.

        Win10 is still a privacy nightmare, with tracking and data collection, instead of respecting the wish of users to keep their private data. It can be fully disabled (with a lot of effort) for Enterprise, but not for Professional nor Home.

  • Avatar
    Nawfal Hassan

    So now there is

    1. MAUI (Xamarin.Forms),
    2. Xamarin.iOS and Xamarin.Android,
    3. UWP (windows specific)
    4. Other open source projects like Uno

    Not counting the WinUI which is just a UI library compatible with both Win32 and UWP. I wonder how they all relate. Too much platforms to remember. I hope this madness stops with MAUI. Is MAUI with WinUI the future? Not so hopeful, is XF/MAUI based XAML even compatible with WinUI?

    • Avatar
      David Ortinau

      Hi Nawfal,

      Xamarin.Forms uses WinUI2 today with its current XAML. As with all platforms, we will guide our support based on developer demand and required device targets.

      You write your UI once in .NET MAUI and you can target Android, iOS, macOS, and Windows.

      • Avatar
        Nawfal Hassan

        @David, great, thanks for the reply. Hmm I like it where it stands now. So I will consider these for future development:

        1. MAUI with its XF/WinUI2 XAML (what i like about it is it being architecture pattern agnostic – either MVVM or MVU)
        2. Uno with its WinUI3 XAML

        Will play around and decide.

  • Avatar
    Max Mustermueller

    How is this different to Xamarin? With Xamarin we can do the same, as far as I can see. XAML + no Linux support + one code for different platforms (mostly mobile), at the cost of larger applications and performance penalties when targeting Windows comparing to WPF/Winforms. MAUI doesn’t seem to fill the gaps, nor does it have something outstanding for desktop developers to use it instead of WPF/UWP/Winforms.

    At this moment I’m not that much excited, I’m sorry.

  • Avatar
    Jacques Doubell

    So with this new layout language, how do you control size and positioning of elements? At least with xaml you have a clear separation between ui and logic. Like someone else already mentioned, this seems a lot like how Flutter does things.

  • Avatar
    Indudhar Gowda

    This is Super Stuff…Good Bye Java, Swift.

    Looks like .NET MAUI will put a full stop to all other Language..

    1. Hot Reload working on XAML and C# will Definitely help in building the Apps Faster. Can we take this Feature to Blazor, UWP, and WPF where c# reload is Missing.

    2. Can we bring Live Visual Tree to Blazor , .NET MAUI or Xamarin.

    3. Can we bring INotification PropertyChange to Blazor.

  • Avatar
    Farr, Derek

    What version of XAML will be in MAUI?
    (Personal preference…please, please, PLEASE let it be WPF/WinUI’s version. XF XAML has many confusing patterns and names. KISS!!!!)

    Is Height going to be Height and no longer need to use HeightRequest?

    • Avatar
      Rod Macdonald

      I’d say WinUI with fluent compatibility for Blazor Native is all we need. The former for the Windows platform, the latter for cross platform + fluent hook up on Windows. Job done.

      Maui is one of those endless goals that frustrate us all. You see the blip on the horizon then it disappears and all your aspirations sink…

  • Jeff Johnson
    Jeff Johnson

    Really hoping you manage to knock the four remaining files out for single file on windows. Need a way to have the exe stand alone. Even if those files have to be extracted to the same folder or a temp folder at runtime that’s fine. Just don’t require them in the folder when the exe is run please.

  • Avatar
    Jeff Siemens

    Wow, this was a unexpected surprise! Overall, I am very excited about what I see!

    In particular, I’d like to give two very enthusiastic thumbs up to:

    • One .NET – integrating Xamarin right into .NET
    • Simplified project files
    • Support for both VS and VS Code
    • A single project that you can run on Windows, iOS, or Android! This truly blew my mind
    • Commitment to multi-platform app development using .NET
    • Support for both MVVM and MVU – cool!
    • Hot reload / hot restart built in from the start. I just hope that it works better than hot reload, because despite the claims from Xamarin that it will work in complex projects, it doesn’t
    • Ability to deploy to an iOS device straight from Windows! Not sure how you guys pulled this off! Again, mind blown!

    Overall, really great stuff!

    Now for some constructive feedback…

    • I happened to notice that you used a “NavigationView” (not Page). This actually got me excited. Now, I’m reading behind the lines a little here, and hoping (really hoping) that this means that you can embed it inside another view. Now, wishful thinking, but I’m also really hoping you guys ditch the whole Page architecture in Xamarin Forms altogether. It’s infuriatingly inflexible. I just want to be able to nest anything inside of anything. Yes, it’s actually important to be able to put a NavigationView inside of a stack. So don’t make it a Page! Don’t make anything a Page! Well, you can have one Page – ContentPage and that’s it. It’s your top level construct for your app, and everything else should be a View.
    • Please support svg/xml/pdf icons and make them tintable. And if you’re thinking of fonts as the answer for vectorization – I issue this warning: fonts aren’t good enough, because you can’t just add a single item to a font. We have a graphics department that makes icons. We have an extensibility mechanism that allows for 3rd parties to bundle their own icons into our app. So fonts don’t work – you can’t add to them. And please please discourage people as much as possible from using Pngs. Pngs should be burned to the ground. They’re not scaleable. They’re not vector. It’s an absolute maintenance nightmare to try to maintain Pngs. Please don’t use Pngs.
    • Please support a wide variety of mobile controls – ideally, looking to match the first party controls from UWP / WinUI, iOS, and Android
    • Please focus on startup and rendering performance
    • Please do ListView / CollectionView, whatever you want to call it, right
    • For the same reason that Pages are horrible and inflexible, please burn Shell to the ground – rigid, inflexible, and useless outside of a horrendously simple demo app. Just make a FlyoutView and a TabView, and you’ve got everything that Shell offers but with way more flexibility.
    • Please do safe areas right. And don’t just put a 30pt margin at the top and a 20pt margin at the bottom (or whatever the dimensions of the notches are on your phone). We actually want stuff to go outside of the safe area too!

    Anyways, I’m really excited about what I see. I hope someone at Microsoft reads this and listens to my feedback.

    Feel free to reach out to me if you want to discuss any of these ideas with me. I’d be happy to!

    Basically it all comes down to this – if you can enable developers to build the types of apps that people with native frameworks, but in a cross platform way, and without having to bend over backwards to avoid the limitations of your platform, then it will be a huge success. That is the litmus test. From what I’ve seen so far, I really believe this is achievable.

  • Micksolidien
    Micksolidien

    Please consider changing your rebranding effort. There is already a cross-platform UI toolkit that has had the MAUI name for over two years under the KDE community. Anyone with two seconds and a search engine would have been able to figure this out. There are a million other names out there–do the right thing and find a new one.

  • Avatar
    Dominique Gratpain

    Hi Scott,

    The first sentence of your article is:
    “You can build everything with .NET. This is one of the main reasons why millions of developers choose .NET as the platform for their careers, and companies invest for their companies. “

    It’s true or rather, it was true until Microsoft tried to stop VB.NET. It is a shame to read that MAUI works with C # or even F # but no word on VB.
    VB.NET is a major piece of the .NET puzzle.
    No, VB.NET is not the poor relation of the family. We could do everything with VB.NET as with C#.

    Please don’t interrupt VB.NET, too many developers around the world are using it.
    Microsoft must integrate VB.NET into new developments. Do not make this error as Microsoft can do it: tiles without start button in the windows of Steve Balmer, silverlight ..

    Thank you in advance for your answer

  • Avatar
    Shiraz Adam

    Xamarin Forms are absolute trash! Looks like I’ll be moving away from .NET because this does not sound promising to me at all.

    I’m sticking with RAD Studio for all my iOS / Windows cross platform development needs

  • Io Lo
    Io Lo

    Why did you choose the name Maui? I think the people who chose that name didn’t do the job right. There’s already a project with the same name and the same functions. Except that it uses Qt and KDE frameworks: Maui

    Plus I looked it up and apparently there’s a registered trademark since 2018. Anyway, I hope at least it’s not plagiarism, because that would mean that Microsoft is so awesome that it’s fallen down… It’s a real shame.

  • Avatar
    Anton Plotnikov

    Hello. What about business applications? We use the WPF, and our customers quite often ask us about versions for macOS (more often), and Linux (hardly ever). What is your vision about the future of the WPF? Will the MAUI be able to replace it with all rich-client features like multi-window, drag-and-drop with the shell, heavy controls like grids and trees, P/Invoke, and so on?