MAUI or more accurately .NET MAUI stands for .NET Multi-platform App UI. It is a bit of a mouthful but essentially all it is 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 you’re thinking, Why the name change and surely it’s more than that? and yes you’re 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.
A Quick History Lesson – A Look at .NET MAUI’s Roots in Xamarin
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, libraries and SDKs into one. This all started coming together with the .NET 5 release 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. Instead of relying 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.
Write Once Run Everywhere
However, as I mentioned, the dream was to write your code once using .NET and C# and it could run on any device. Microsoft, when Announcing .NET 5, used this slide to show the intention of the project.
Now we, as app developers, are concerned with mobile, and there was an obvious intention in placing mobile centre in this slide when it was first shown. It highlights that Microsoft is pushing this as well.
We have been writing our apps for mobile using Xamarin 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. This version will keep getting updates and patches until 1 year after the GA of MAUI. So if you’re 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.
What’s Changed from Xamarin to .NET MAUI?
Well a lot actually. The team at Xamarin built the infrastructure based on Mono with what was available in C# at the time and what they thought was the best way forward. However, 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 .Net fully so that they could fulfil the idea of Build Once run everywhere.
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.
.Net 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 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.
Fixing the Scars
If you’re 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 something is missing from Xamarin or you want to change how something looks on the screen, you have to write your own Custom Renderer and this must be done for each platform and 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 Handler are decoupled so that they are reusable between projects. It is all made possible with the use of 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.
How do Handlers work then?
As we know our C# code, whether we write the UI in code or express it with XAML, needs to be built and then 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 a picture speaks louder than words so:
Looking at the 3rd layer in this diagram, we can see there is a ButtonHandler for each of the platforms. It’s this that we can call in our code and change settings or even swap out altogether. We can also set things like colours globally across all controls and even target just one platform. As shown in this example — for Android all backgrounds are set to Cyan and you will notice the use of Compiler PreProcessor Directives.
What Else Should I Know About .NET MAUI?
The other big changes that are new and make for an easier transition for .NET developers 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:
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 With .NET MAUI?
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 check out the main .NET MAUI project, then you can find it over at the MAUI GitHub page.
The biggest thing you can do to start – and you would 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.
If you have already been installing any of the VS22 previews even without any 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
I have been following 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. You will see even at the time of writing, they are nearly there with mostly Done ticks.
Lastly, you can check out 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. The latest news can be found on the team’s blog.
As I continue the journey of playing with MAUI I will add more blog posts to this one. I’ll be showing you the other changes like the Multi-Targeting and the new project structures within VS22 as it becomes one project, rather than one for each platform under Xamarin.