The New .NET Multi-platform App UI

David Ortinau

David

With .NET 6 previews starting right around the corner, it is time to start getting excited for the new .NET Multi-platform App UI (MAUI) that was announced at BUILD 2020. This year of .NET has a lot of amazing things for client application developers. Let’s review the highlights and set your expectations for the year ahead.

.NET 6 planning and execution is happening in the open, and we have a beautiful website that summarizes our GitHub epics and user stories across all of .NET. Visit themesof.net and search on Xamarin to see the high-level details.

.NET 6 and Mobile SDKs

At the heart of this release is the unification of the Xamarin SDKs into .NET. Xamarin has always been a part of .NET, but now it ships as a core workload, shares the same base class library as other workloads like Blazor, and adopts the modern SDK Style project system for consistent tooling experiences. No longer is Xamarin some other thing that is like .NET or has some dependency on .NET, but it IS .NET. This will be made clear as you see the naming aligned in our documentation and product pages as we approach release.

Xamarin.Android and Xamarin.iOS are now additional platform targets you can reach with .NET, so we will refer to them as .NET for Android and .NET for iOS. Those SDKs themselves are .NET bindings to the native SDKs from Google and Apple respectively, and thus no renaming takes place in their API surface.

.NET Multi-platform App UI (MAUI)

.NET MAUI is the evolution of Xamarin.Forms, a cross-platform mobile first framework for Android, iOS, and UWP. Building upon 7 years of experience supporting customers from independent developers to some of the world’s largest companies, we are improving the core of the product, speeding up UI rendering, investing in consistent design systems, and extending from mobile to desktop.

For Xamarin.Forms customers, think of this as the next major version of the same product you know today. For developers new to multi-platform development with .NET, we invite you to take a look at what we are doing to serve you.

Quality

Since mid-2020 the core team has been focused on high impact issues in the product, and design the new control architecture to set you up for future success. With Xamarin.Forms 5.0 representing the last major feature release before .NET MAUI, the only work happening there are bug fixes. Xamarin.Forms will continue to receive service releases through November 2022.

There are no new controls planned for this release; our focus is being invested into the heart and soul of the product. We get excited about new features just like you, and for that, we are very pleased to see such a positive response to the Xamarin Community Toolkit which launched 1.0 alongside Xamarin.Forms 5.0 and includes an already impressive set of controls and tidbits.

As you look at the dotnet/maui repository, you’ll notice a much leaner folder organization that makes use of multi-targeting and has a much more consistent naming scheme as compared to Xamarin.Forms. We hope this will be a great benefit to contributors looking for just the right place to make their impact. Active development today is happening in the main-handler branch of the xamarin/Xamarin.Forms repository, and then synced to dotnet/maui.

Performance

There are several points in an application where performance can be a critical quality issue, including app startup and UI responsiveness. We have made great progress with AOT, Startup Tracing, and fast renderers to help address these issues. In .NET MAUI we have several tasks that will benefit performance, not least of which is .NET 6 itself!

The new handler architecture in .NET MAUI removes view wrapping, thus reducing the number of UI controls needed to render a view. It also fundamentally decouples the platform controls from the framework itself. In Xamarin.Forms each renderer has a reference to the cross-platform element and often relies on INotifyPropertyChanged to work. Rather than using these renderers, .NET MAUI introduces a new pattern called a handler.

The relationship between the framework and the platform is now inverted, and all the platform control needs to do is handle the needs of the framework. Not only is this more efficient, but much easier to extend or override when needed. Gone will be the days of needing to create custom renderers or effects (though we have made sure those all still work too).

The new architecture also makes the platform handlers much more suitable for reuse by other frameworks such as Fabulous, and experiments like Comet and Blazor. We always have our eyes on the future!

Design

The design requirements for applications that target multiple platforms have changed over the years. In the early days of Xamarin.Forms, most customers wanted their Android app to look very Android, and iOS app to look very iOS. We have introduced in Xamarin.Forms more and more styling and controls that look the same across platforms, and added the Visual control API along with Material Design components for iOS to match what you get on Android. These efforts went part of the way towards satisfying what customers have shown us they require, and in .NET MAUI we are laying the foundation to go even further.

Fluent UI Button

We are enabling full-app themes through styling for Fluent UI and Material Design, filling out the existing controls with the necessary styling APIs and visual states, and adding support for control templates as we are able (see RadioButton for a recent example of this).

On the experiment front, we also have kicked off a new Visual strategy that uses a combination of native controls and drawn controls. We will have more information to share about that later this year. For customers needing the 1:1 design across platforms and looking for even better performance, but also having a requirement for native platform support, we think this will be on target.

Platforms

.NET MAUI is embracing Android, iOS, macOS, and Windows in .NET 6. We are excited to see what you will build for mobile and desktop! Beyond that, we are also working hand-in-hand with the Blazor team to enable Blazor Desktop in .NET 6.

The Xamarin pedigree is deep in mobile, and that’s certainly where the majority of customers have used it. Xamarin.Mac exists today as the .NET binding to AppKit, Apple’s desktop platform. In .NET 6 this is now referred to as .NET for macOS, however, we see Apple going a different direction for macOS desktop development and we want to make sure we give you the very best experience. For this we are introducing .NET support for Mac Catalyst, a solution from Apple that brings your iOS app built with UIKit to desktop, and augments it with additional AppKit and platform APIs as needed. You can explore several of Apple’s first-party apps to experience this yourself. .NET MAUI will use this approach in .NET 6.

When UWP was targeting Windows Mobile, Xamarin.Forms added a mobile-centric implementation with UWP. In .NET MAUI we are bringing stronger desktop-focused support with WinUI 3 Desktop, the very latest way to build great apps from our Windows team partners. When it comes to UWP and WinUI as it relates to .NET MAUI, the main question we are asked is what “flavor” of XAML will be used in .NET MAUI. Because .NET MAUI controls are multi-platform abstractions rather than Windows-only controls, and because we have a massive catalog of Xamarin.Forms customers with knowledge and projects to bring forward, we are continuing forward with the same “flavor” you have in .NET MAUI.

Single Project

One of the most exciting things we announced with .NET MAUI is the Single Project experience. We find that developers are most productive when doing tasks in the .NET Standard library project rather than bouncing between Android, iOS, macOS, and Windows projects where you need to navigate the idiosyncrasies of each platform.

As part of this experience, we are unifying many experiences such as fonts and image management, and reducing reliance on the complexity of managing multiple platform projects. For developers that enjoy or require multiple platform projects, that’s still supported too!

.NET Hot Reload

One of the biggest productivity boots for .NET developers in the past few years has been the introduction of XAML Hot Reload. As you make changes in XAML, updates are pushed to your running applications, and you get to avoid the tedious build and deploy cycle that interrupts and distracts even the most seasoned developer. In .NET 6 we are expanding this success to C# and introducing it to other workloads as well. We can’t wait for you to experience this later in the year.

Getting Ready for .NET 6 and .NET MAUI

I hope you’re excited about one or more of these highlights. They come directly from talking to customers like you, and we’ve prioritize these themes for the .NET 6 release. If you don’t see updates you’re hoping for, let us know as we will be shortly planning .NET 7 and beyond.

To help you consider what you can be doing to get ready, I’ll share here some frequently asked questions and some replies.

Should I use Xamarin.Forms today, or wait for .NET MAUI?

Use Xamarin.Forms! You’ll have a migration path to .NET MAUI when everything is ready.

What is the migration path from Xamarin.Forms?

First, you do NOT need to rewrite your application. The first step will be to update your project and solution files to use the standardized SDK Style. You’ll then update the namespace from Xamarin.Forms, and update your NuGet packages. Any obsolete or deprecated APIs should be updated at this time since this is a major version release. That’s it!

You may then choose to migrate custom renderers to the new handler architecture in order to reap all of the performance gains possible. This may be done at your own pace.

Before migrating be sure to explore .NET MAUI in a new project.

Will my custom renderers work?

Yes, we are providing adapters to enable renderers to work side-by-side with the new handlers, however, you should consider updating to handlers in order to reap the performance gains. Plus, it’s a lot less code to maintain.

What’s going on with VS Code, Comet MVU, and Blazor Mobile Bindings?

These are experiments at this time as we iterate on them. Check them out here:

We look forward to sharing more about these projects later in the .NET 6 preview cycle and getting your feedback.

38 comments

Leave a comment

  • Avatar
    Yves Goergen

    What XAML flavour?

    “the main question we are asked is what “flavor” of XAML will be used in .NET MAUI. (…) we are continuing forward with the same “flavor” you have in .NET MAUI.”

    So you’ll be using the same XAML in MAUI that you have always used in MAUI. I guess that’s not an answer. Did you mean to write something else here? Or is my English parser broken?

    • Avatar
      Yves Goergen

      I found the answer on the dotnet/maui FAQ page:

      What flavor of XAML will be supported by .NET MAUI

      We’ll continue to use the same XAML that we know and love from Xamarin.Forms.

      So it looks like it’s time to say goodbye to my WPF knowledge and move on to the next framework. BTW, where can I find those previews? I’m not going to invest in learning Xamarin if it’s being replaced anyway.

    • Avatar
      Yves Goergen

      From their short GitHub readme:

      supporting a wide range of Operating Systems such as Windows via .NET Framework and .NET Core, Linux via Xorg, macOS.

      That wide range comprises only desktop systems, nothing mobile. I don’t see how that framework is anywhere comparable with Xamarin or MAUI.

  • Avatar
    Erhan Kaluc

    Great news! Thanks for the progress put into this effort.

    Let me ask and suggest:

    Does anyone ever think about providing better IntelliSense in view files for data binding?
    My experience with WPF and Xamarin Intellisense in view files: Either don’t work correctly or don’t work at all for most of the time.

    What about refactoring? Do you have any plans to provide refactoring in the view files?
    Let’s think. Visual Studio may perform refactoring in the view file when any bound property’s name is refactored on the code file.

    Does anyone in Microsoft think about how counterproductive these above issues could be?

    I hope that the product to be published this time will not come across with the above problems. The year is 2021!