In less than a month Microsoft will end support for .NET’s first major cross-platform UI tool, Xamarin Forms. Instead of developers having to build separate UIs for Windows, iOS, and Android, Xamarin Forms gave us a set of cross-platform UI controls we could use to build one code base that compiled to all target platforms, without any device-specific code. It was a big hit, but now it’s fading away.
Microsoft has been developing a follow-on to Xamarin Forms in the shape of MAUI, the Multi-platform App UI. MAUI supports Windows, macOS, iOS, and Android, again allowing you to continue to develop code using the same tools and techniques as Xamarin, working with the latest .NET releases. MAUI is still very much under development, with some differences that make it hard to simply swap out one set of controls for another.
You can see the current comparison between the two platforms on GitHub. Probably the most important differences are the need to move code to the latest .NET platform, with support from .NET 6 and higher, as well as the range of different application models which are expanded to include support for both MVU and Blazor. The aim is to provide a common set of features between MAUI and the Windows App SDK, so you can quickly move Windows-only code to multi-platform.
One key point to note is that, even though it won’t be supported, you still need Xamarin Forms to build apps for older iOS and Android devices. If older devices are not a target for you, then you should consider moving your code to MAUI or to one of the alternative cross-platform .NET UI frameworks that are now available. Both the Uno Platform and Avalonia are mature tools that offer WinUI 3 compatible controls and support many different operating systems including Linux.
More options than MAUI
Choice is good. The open-source nature of .NET has made it an attractive platform for extensions like Uno and Avalonia, both of which offer different approaches to delivering cross-platform UIs, support different application models, and provide a different range of controls. You can pick the tool that suits your team, and if you want to try a new one, all you need to do is set up a new branch in your repository and try it out.
Microsoft provides a guide to updating from Xamarin to MAUI. While most common scenarios are supported, others, like watchOS, require you to build new native Swift applications. In practice that may not be necessary, as watchOS’s rich notifications may be a better alternative to managing a whole new application framework.
While you can move projects to the MAUI SDK project format manually, there is the option of using Microsoft’s own .NET Upgrade Assistant to start the process for you. It’s important to note that in most cases this won’t deliver a ready-to-build application. You will have to spend time finalizing layouts and making sure that you have the right libraries.
Recent releases of MAUI have addressed many of the earlier issues, and Microsoft is keeping an open roadmap as well as a list of fixes in the MAUI GitHub repository. It is certainly a very active project and is maturing fast.
If you plan to use one of the alternative UI platforms, both Uno and Avalona offer their own migration guides, as well as case studies showing how large customers have managed their transitions.
Choosing your UI platform
The biggest difference between the Uno and Avalonia UI platforms and MAUI is that MAUI is a wrapper for native controls. MAUI allows you to build native look-and-feel apps while still using the same code, while Avalonia and Uno have their own rendering as well. This approach ensures a level of consistency between apps on different target devices and makes it easier to port controls to different devices and platforms. By building on Windows’ WinUI model, the Avalonia and Uno platforms have more options for styling controls.
If you look at Uno’s migration documentation, there are many things to consider when migrating, from animations, to controls, to navigation, and more. However, there is enough similarity between how Uno and Xamarin Forms implement XAML that you can work your way through a migration. However, you shouldn’t expect it to be a process that can be easily automated.
For example, if you’re animating controls or objects, you need to move away from Xamarin Forms’ animation class to WinUI 3’s Storyboards. Storyboards are based on the animation approaches introduced with WPF back in the early days of .NET, and may seem familiar, as they have been used across most of Windows’ UI development tools for more than a decade. It’s worth understanding the Storyboard equivalents of Xamarin Forms animation operations and using these as part of a migration, while working within a Storyboard timeline.
One key difference is how WinUI 3 supports navigation. Xamarin Forms has a page model, with a stack that manages navigation between pages. This is replaced by a Frame control that manages navigation backward and forward through a stack of pages. While this is a more flexible approach, there are some issues that come from WinUI 3’s Windows heritage. For one thing, there’s no direct support for hardware navigation buttons, so you will need to add your own code to deliver this where needed. You also need to add your own navigation bar controls, though unlike Xamarin Forms, a WinUI navigation can pass parameters to the new page.
There are enough little issues like this that you should spend some time working through the documentation and tutorials before attempting a migration. However, there aren’t any real showstoppers, and there are workarounds for most issues. Of course, there’s another side to the story, where migrating simplifies some operations, allowing you to reduce code complexity, making it easier to debug.
Updates mean everything
In practice, whatever approach you choose to replace Xamarin Forms will require significant work. Much of that, though, will be due to the evolution of the .NET platform beyond Xamarin. Microsoft has done a lot of work to ensure that .NET performs well on all its target platforms, and if you’re building user-facing applications you’re going to want to take advantage of those changes. Xamarin Forms is now a legacy technology, and as such will hold you and your users back.
By moving to a modern UI framework, you’re taking a step toward future-proofing your applications. That means giving users support for newer devices and, with Wasm, support for rich web applications that have many of the same capabilities as native desktop and mobile apps. Both Avalonia and Uno have large libraries of controls that go above and beyond what Xamarin Forms could do, allowing you to do more with your code, and more quickly.
If you take this approach, you could see Xamarin Forms’ end of life as an opportunity to update and rearchitect your code, taking advantage of newer .NET features and newer design patterns that may be more suitable for your applications. You could even add modern design tools, like Figma, to your toolchain, allowing you to bridge the gaps between design and development, reducing frictions and ensuring a more collaborative environment.
End of support for Xamarin Forms isn’t a bad thing for mobile and cross-platform .NET. If anything, it shows that modern .NET gives you lots of options. And its open source foundations allow you to add your own code to fill in any gaps.