What is .NET MAUI

Brief tour of the new .NET MAUI and whats different to Xamarin.Forms

Posted by Clifford Agius | CA-Software Ltd on Tuesday, November 16, 2021

TOC

What is .NET MAUI

MAUI or more accurately .NET MAUI stands for .NET Multi-platform App UI which seems a bit of a mouthful but essentially all it is the next iteration of Xamarin… Yes it’s Xamarin vNext so instead of there being a Xamarin.Forms 6 we are getting .NET MAUI.

But I know what your thinking why the name change and surely it’s more that that and yes your right it is a lot more than just a name change it is pretty much a re-write of the Xamarin stack, and more than that it is also finally being pulled into the .NET BCL (Base class library) which means it is going to be a part of .NET and no longer the separate project it was before.

As mentioned by the team many times when thinking about the change to MAUI it’s important to know that No longer is Xamarin some other thing that is like .NET or has some dependency on .NET, but it IS .NET. This means that you as a .NET developer can write Apps that target Mobile platforms as well as Blazor, Web, Cloud etc so how cool is that.

Quick history lesson

Back in February 2016 Xamarin was purchased by Microsoft and from the annual Microsoft Build conference that followed it was clear that the intention was to fold the Xamarin tooling into .NET and unify all the runtimes, library’s and SDKs into one. This all started coming together with .NET 5 released in November 2020 but was due to complete with the GA of .NET 6 in November 2021.

For this unification to happen and the dream of .NET with C# being the language of choice to write an App once and run absolutely anywhere they needed to bring Xamarin into .NET fully rather than rely on the mono implementation of .NET originally written by Miguel de Icaza to bridge from your C# code into the Android or IoS runtime.

As you can see below the model is complex with Bindings and API’s that allow you to write your C# code to run on the devices supported by Xamarin namely Android and IoS and later others like UWP and Tizen.

Mono Runtime supporting Mobile

Write Once Run Everywhere

But as I mentioned the dream was to write your code once using .NET and C# and it can run on any device and Microsoft when Announcing .NET 5 used this slide to show the intention of the project.

.NET Everywhere

Now we as App developers are concerned with Mobile and there is obvious intention in Mobile being centred in this slide when it was first shown, to highlight that Microsoft are pushing this as well.

We have been writing our apps for mobile using Xamarin up until now and hopefully your projects are on the latest version of Xamarin.Forms which at the time of writing is 5 Service release 5 and this version will keep getting updates and patches until 1 year after the GA of MAUI. So if your about to go File->New Project for a Mobile app today then Xamarin is still your go-to and this is important, as there is a tool being developed that will help migrate from Xamarin.Forms 5.x to MAUI when it GA’s hopefully Q2 in 2022.

Whats Changed

Well a lot actually the team at Xamarin built the infrastructure based on Mono with what as available in C# at the time and what they thought was the best way forward but over the years and with the rise in popularity of Xamarin they have realised there are lots of areas and scars they wanted to fix. Once Microsoft purchased Xamarin it was clear that the team wanted to build Xamarin into DotNet fully so that they could fulfil the idea of Build Once run everywhere.

Base Class Library (BCL) Integration is a large part of the change as Xamarin becomes a true part of .NET just like System.IO so now Xamarin.Forms becomes Microsoft.MAUI and Xamarin.Essentials becomes Microsoft.Maui.Essentials and it is all installed as Workloads using Visual Studio 2022.

DotNet MAUI will continue to release on the same 6 week cadence as Xamarin.Forms currently does, it’s still Open Source with a repo here and the same great team are busy behind the scenes.

This all means that the process of targeting the different platforms is now much cleaner and your code is abstracted away from worrying too much about the device, as you can see here the code targets .NET MAUI and via the target device layer the correct handlers are used (More on this below!) to then build for that device.

New Build Pipeline

Fixing the Scars

If your a Xamarin Developer at the moment you know about the problems and the dance to make it all work not just the tooling but also the complex way your code is built, one of the biggest of these is that if there is something missing from Xamarin or you want to change how something looks on the screen you have to write your own Custom Renderers and this must be done for each platform and thus they are tightly coupled to Xamarin.Forms.

Now when you write your code you target .NET MAUI but do so via a Handler in place of a renderer, the advantage here is that you can change out the Handler for each platform, even for the whole project by moving from the default for example an Entry control of Microsoft.MAUI.Controls.Entry to a ReactiveEntry, this means the Handlers are decoupled so that they are reusable between projects. It is all made possible with the use of new these new Handlers which each have an interface layer that your code makes use of, so you can use the default Microsoft.Maui.Controls.Entry or a CometEntry or if you really want control you can make your own.

New Handlers Architechure

How do Handlers work then?

As we know we can write the UI layer in C# code or express it with XAML, it then needs to be built and turned into the native UI Element for the device. So taking a button as an example we can see that our code is mapped via an Interface to the Handler for that platform and finally into the device native element for a Button. As always picture speak louder than words so:

Handler Mapping

Looking at the 3rd layer in this diagram we can see there is a ButtonHandler for each of the platform and it’s this that we can call in our code and change settings or even swap out all together. We can also set things like colors globally across all controls and even target just one platform like this example that shows for Android setting all backgrounds to Cyan and you will notice the use of Compiler PreProcessor Directives.

#if __ANDROID__
    Microsoft.Maui.Handlers.ViewHandler.ViewMapper[nameof(IView.Background)] = (h, v) =>
    {
        (h.NativeView as Android.Views.View).SetBackgroundColor(Microsoft.Maui.Graphics.Colors.Cyan.ToNative());
    };
#endif

What Else?

The other big change that is new and makes for an easier transition for DotNET developers coming from other areas like say ASP.NET is that the start-up of the app now uses the Host Builder pattern so if you open the MAUIProgram.cs file of a new .NET MAUI program you will see the following:

namespace MauiApp2
{
    public static class MauiProgram
    {
        public static MauiApp CreateMauiApp()
        {
            var builder = MauiApp.CreateBuilder();
            builder
                .UseMauiApp<App>()
                .ConfigureFonts(fonts =>
                {
                    fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
                });

            return builder.Build();
        }
    }
}

As you can see this is where you would add in your dependencies and even configure App wide resources like Fonts, Images Sources or even your Handlers from your last MAUI project.

Where do I start?

At the moment .NET MAUI is still in preview and at the time of writing it is at Preview 8 with 9 just around the corner and a monthly release cadence through to GA in Q2 2022.

However that doesn’t mean you can’t jump in and play there is already a fantastic demo App put together by David Ortinau the Principal Program Manager which I think looks amazing, it’s called Weather21 and David is constantly updating it with the new parts as they become available. If you want to checkout the main .NET MAUI project then you can find it over at the MAUI GitHub page

The biggest thing you can do though and would obviously need to build the projects referenced above is to install Visual Studio 22 Preview however before you race off and install it I strongly suggest you take a look at the .NET MAUI install instructions as they change often as the tooling is getting closer to RC. You can find the latest instructions over at Docs.microsoft.com

Note:

If you have already been installing any of the VS22 previews even without an MAUI bits then sadly it could all stop working (It did for me!). The solution for me was to Delete VS22 and then running a great clean tool written by Jonathan Dick (aka @Redth) which is on his Github at https://github.com/Redth/dotnet-maui-check/blob/main/Clean-Old-DotNet6-Previews.ps1

Conclusion

I have been following along with the previews of .NET MAUI since the start and I have been poking around in the GitHub repo to see how it’s built and how it’s all coming together. There are some great resources listed on the FAQ for the project and you can see the progress of each of the Xamarin.Forms components as they move over to .NET MAUI and the new Handlers scheme on the .NET MAUI Status page as you will see even at the time of writing they are nearly there with mostly Done Ticks.

Lastly you can checkout the .NET MAUI docs over at Docs.Microsoft.com which at the moment are very sparse but will get built out over the coming months, but the latest news can be found on the teams blog

As I continue the journey of playing with MAUI I will add more blog posts to this one and show you the other changes like the Multi-Targeting and the new project structures within VS22 as it become one project rather than one for each platform under Xamarin.

I hope you have enjoyed this intro to MAUI so far and please reach out on Twitter @CliffordAgius if you have any questions/comments etc.

Happy Coding!

Cliff.