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.

165 comments

Comments are closed. Login to edit/delete your existing comments

    • Avatar
      Ben Funk

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

    • Avatar
      redthMicrosoft logo

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

      • Shimmy Weitzhandler
        Shimmy Weitzhandler

        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.

      • Vincent Thorn
        Vincent Thorn

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

      • Avatar
        Derek Ziemba

        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?

    • 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
      Charles Roddie

      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.

      • Daniel Hughes
        Daniel Hughes

        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)

    • Avatar
      Lars Bruins Slot

      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
        Daniel Hughes

        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.

  • Avatar
    Krio

    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
    Shimmy Weitzhandler

    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.

    • Avatar
      David OrtinauMicrosoft logo

      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. david.ortinau@microsoft.com

      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.