In the world of cross-platform .NET development, two popular frameworks have emerged as strong contenders: Avalonia UI and .NET MAUI (Multi-platform App UI). Both are powerful tools designed to solve different problems, making it essential to understand their key differences to make an informed choice for your project.
This blog post will delve into the primary distinction between these two technologies and the benefits of each approach.
Let's start with a brief overview of both Avalonia UI and MAUI.
Avalonia UI
Avalonia UI is an open-source, cross-platform UI framework that allows developers to create beautiful, responsive applications using a single codebase for multiple platforms, including Windows, macOS, Linux (desktop and embedded), WebAssembly and even mobile platforms. Avalonia UI leverages XAML for creating the UI, making it familiar to those with experience in WPF, UWP, WinUI or Xamarin.Forms.
While Avalonia UI is free and OSS, it is backed by a small, independent company formed by the core team responsible for the development of Avalonia UI. We offer development services, support agreements and recently announced our first product, Avalonia XPF. The goal of the company is to generate revenue to enable the core team to work on Avalonia UI full-time and to better serve enterprises building apps with Avalonia.
MAUI
MAUI (Multi-platform App UI) is an evolution of Xamarin.Forms. It's an open-source, cross-platform framework for building native UIs for iOS, Android, macOS, and Windows. MAUI simplifies creating apps with native user interfaces by enabling developers to develop in a single project. It uses the native UI toolkit of each platform, which allows developers to leverage platform-specific capabilities and build applications that feel native to each platform.
Developed by Microsoft, it has a large and dedicated community of users to lean on for support.
Now that we have a basic understanding of Avalonia UI and MAUI, let's dive deeper into their differences.
UI Drawing
Native vs Custom Rendering:
The primary difference between Avalonia UI and MAUI lies in how they draw the user interface. Avalonia UI employs a custom drawing engine powered by Skia (like Flutter), while MAUI uses native UI toolkits for each platform.
Let's explore these approaches in more detail.
MAUI
MAUI uses the native UI toolkit of each platform, resulting in an application that feels native to the platform it's running on. This means that a MAUI app on Android will use the native Android UI toolkit, while on iOS, it will use UIKit. This approach ensures that your application will have a look and feel that users expect on their devices. This approach offers several benefits:
Performance: By utilising native UI toolkits, MAUI can offer good performance, especially on mobile devices. It should be noted that on some platforms, objects will exist in both the .NET memory space and the platform UI toolkits memory. This can have a noticeable effect on performance compared to an app developed purely with the native technology. For example, on Android you will have two Garbage Collectors, one for the ART Runtime and one for the .NET runtime.
Platform-Specific Animations and Transitions: MAUI allows developers to harness platform-specific animations and transitions, giving applications a polished and native feel. By utilising the animations provided by the native UI toolkits, developers can create applications that are consistent with the design language of each platform and provide a familiar user experience.
Rapid Adoption of New Platform Features: As new features and UI components are introduced in native platforms, MAUI applications can quickly adopt these updates, ensuring that applications stay up-to-date with the latest design trends and platform improvements. This helps maintain a modern and consistent user experience while also reducing the time and effort needed to implement new features manually.
Avalonia UI
Unlike MAUI, Avalonia UI uses a custom rendering engine that draws UI elements consistently across all platforms. This means that your application will have the same appearance and behaviour regardless of the platform it's running on. Avalonia UI's custom rendering approach allows for greater control over the UI design and a consistent user experience across different platforms. This approach comes with its own set of benefits:
Consistency: Applications built with Avalonia UI have a consistent look and feel across platforms, which can be valuable for branding and user experience.
Flexibility: The custom drawing engine gives developers more control over their application's appearance and behaviour. They can create custom UI elements and styles that might not be possible or would require more effort using native UI toolkits.
Simplified Maintenance: Using a custom drawing engine means the UI code is the same across all platforms, simplifying maintenance and updates. Developers only need to change the shared codebase, reducing the time and effort required to maintain the application across multiple platforms.
Independent Evolution: Avalonia UI's custom drawing engine allows the framework to evolve independently of the native platforms it targets. This means that improvements, bug fixes, and new features can be implemented faster without having to wait for native platforms to catch up or maintain compatibility. As a result, Avalonia UI applications can benefit from continuous innovation and stay ahead of the curve in terms of UI and UX advancements.
Platform Support
While both technologies are both versatile and powerful UI frameworks, their platform support differs in some key areas.
Windows
MAUI provides support for Windows 10 and 11, depending on WinUI3, while Avalonia UI can target Windows 7 and higher.
macOS
As MAUI relies on Mac Catalyst, it supports macOS 10.15 (Catalina) and newer. Avalonia, on the other hand, supports macOS 10.13 (High Sierra) and higher.
Linux
At this time, MAUI doesn’t have any official support for Linux, though a community effort exists to enable MAUI to run on desktop Linux. Avalonia UI supports both desktop and embedded distributions of Linux, requiring no desktop environment to be installed. Officially supported distributions include Debian 9, Ubuntu 16.04 and Fedora 30 and higher.
iOS
MAUI supports iOS 11 and higher, while Avalonia UI supports iOS 13.
Android
MAUI supports Android 7.0 (API 24) and higher, while Avalonia UI supports Android 5 (API 21)
WebAssembly
It was recently announced that MAUI could be getting Web support after .NET 8, but at this time, there are no options to deploy your MAUI applications to the web. Avalonia UI supports WebAssembly today and has a fully interactive playground for exploring Avalonia UI on the web.
Solving Problems Differently
While both Avalonia UI and MAUI are powerful frameworks for cross-platform development, they are designed to address different concerns:
Avalonia UI is an excellent choice for developers who prioritise consistent branding and a uniform user experience across platforms. Its custom drawing engine provides flexibility in designing custom UI components and styles, making it perfect for creating unique and visually rich applications. Avalonia UI excels on desktop focused applications, with mobile and WebAssembly being new additions to the platform.
On the other hand, MAUI is the go-to choice for developers who need their applications to adhere to platform-specific design guidelines and provide a native look and feel. Its use of native UI toolkits ensures fantastic performance on various devices, and direct access to platform-specific APIs allows for seamless integration of native functionality. MAUI is a great choice for developing mobile centric applications, where desktop is a secondary or lower priority.
Conclusion
Avalonia UI and MAUI are both outstanding options for cross-platform development, each offering unique benefits depending on your project's requirements. The strength of the .NET ecosystem lies in its ability to provide developers with an array of options to choose from, ensuring they can select the most suitable approach for their specific project. The beauty of .NET is that a well architected application can reuse a huge amount of code, regardless of the UI framework used.
If you want to learn more about Avalonia UI and how it can help you develop visually stunning, high-performance applications for Windows, macOS, Linux, Android, iOS and WebAssembly then check out our getting started.
Oldest comments (16)
There is also Uno, which use the UWP/WinUI XAML dialect.
Really nice comparison
I really like that this article highlights the good in both frameworks to draw the comparisons rather than put the other one down to prop the other one up.
I love this positive approach <3
This is a really good comparison between the frameworks.
A while ago, I started on a personal project. I wanted to build a (primarily) Windows desktop app, but wasn't sure of which UI framework to use. I could have gone for WPF, but it seems like it isn't (truly) in active development anymore.
After looking around a bit, I came across a few options which included MAUI and Avalonia. MAUI didn't really seem the perfect fit for what I wanted to do, and I already knew WPF pretty well. I decided to go with Avalonia, and I have to say it's a nice framework to work with!
In the spirit of being fair, I'm sure MAUI is great too; I just haven't tried it yet.
WPF isn't dead. If it was, they wouldn't have taken the time to port it from framework 4.x to Core 3.5. It's more that it works and it's flexible enough that you can make it do pretty much anything now so there's not much left to do...
Well, other than make it cross platform, which Avalonia does - without turning it into .Net Forms, which MAUI and Xamarin Forms does.
I just had a quick look at the WPF GitHub repository. You're right - it's not dead, and there is a vision for it.
For the most part, I agree that it's mature and flexible. That said, it's been around for a long time time. I understood the initial vision to be a modern replacement for Windows Forms, but it still doesn't have colour picker or tray icon controls - unless I'm mistaken (which could be the case as I haven't done much WPF recently).
Ah... well, you're actually sort of right in that Microsoft is a little like a herd of cats.
Forms tried to 'modernise' VB. WPF modernised Forms (and made it platform independent - but at a time when Microsoft wanted all platforms to be Windows). That led to Silverlight - which was 'WPF Everywhere' - and ran in all browsers.
Then they decided they wanted to replace Win32 with a modern platform and cater to webdevs and so created WinRT and tossed desktop apps for UWP/WinRT and HTLM/Js/Visual C++ (original Surface and Win8). Seriously, .Net/C#/VB/F# wasn't even mentioned in the original presentations., When the dev community collectively said "WTAF Microsoft???" they reluctantly added .NET back into the mix and kind leaned back into WPF but secretly still wanted everyone to use UWP - which was a variant of WPF anyway. This would become a trend.
Then they bought Xamarin and bam, back to Forms again AND cross-platform (sort of, because relying on native controls means 'least common denominator' development rather than WPF's 'do anything anywhere' approach). They also promised XAML 2 - a the one formal consistent XAML to rule them all.
It kind of vanished.
Then they introduced WinUI - which was (wait for it) UWP on Win32 that could live side by side with regular WPF and was itself WPF-like.
Then they announced MAUI (Multiplatform Application User Interface) which was...mmm... Xamarin.Forms but with a few webby things glued into it and a hint that they might remove the coupling to native controls (or make it optional) which was ALSO WPF-like.
At the same time, we got Uno Platform ('let's make Xamarin.Forms use WinUI syntax - a good idea but...), CHTML or OpenSilver (which brought back Silverlight, so WPF but ONLY in browsers) and AvaloniaUI (basically real WPF with a few syntactic changes AND genuinely cross platform - most of the others support macOS through MacCatalyst which is really just a way to run iOS/iPadOS apps in macOS - but not a real macOS app).
And that's where we are today. Microsoft doesn't like WPF but it's so flexible, powerful and easy to learn that even their own engineers prefer to use it, so they can't get rid of it. It's why when .Net Core came out they were trying to ride the webdev bandwagon and targetted it at ASP.Net on Linux, there was NO UI tech in it at all.
It took until .Net Core 3.1 (I think) before they added WPF and Forms when they realised that all the app devs were ignoring Core because, well, they couldn't use it. :) Then Microsoft open sourced .Net, so WPF is here for the long haul.
As for colour pickers and tray icons, yeah - there are weird gaps, but you can host Forms controls or Interop to the platform for those. There are quite a few open source control kits (some by Microsoft in fact) to fill in the missing pieces. More to the point, it's really easy to fill them in.
Why Microsoft chose to skip some basic control (Open File, Save File and Folder Browser are another set) is that cat herd problem again.
PS: When they did open sourced WPF and brought it to .Net Core, I remember Scott Hanselman hinting that they could make WPF genuinely crossplatform and that that might be coming. Sure, sure. :)
Thanks for the history lesson (I really do mean it).
I did the bulk of my WPF coding starting circa 2005, and remembered feeling disappointed that there were no tray icons, etc. But you’re your right that they can be relatively easily patched, and I remember following some guides to do platform interop code for tray icons, etc.
I then transitioned to Silverlight until its sunset approximately 10 years later. I remember the fanfare around .Net Core being cross platform, and that WPF was coming to it. And then the disappointment of learning that it would be there, but only for Windows (rather than being cross platform like the rest of .Net Core).
After Silverlight was dropped, I transitioned to HTML/JS/CSS, so didn’t follow the Microsoft UI frameworks as closely until around a year ago when I wanted to do a desktop app. I admit I found it really confusing choosing a UI framework, as there were so many different options. I think I tried WinUI3, but it didn’t feel right for my project and so tried Avalonia. It was still slightly confusing – it was my first real contact with Observables and Reactive UI – but nice to use once I got the hang of things.
It's good to know WPF is here to stay – at least for now. Thanks for the insight.
Very good contribution and a comprehensive comparison of the two frameworks. As an experienced .Net and wpf developer, I think the decision on which framework to use depends on context and requirements.
For example, if a cross-platform business application is to be developed, then the usability and user experience are critical. So that the user experiences the same behavior of the application on each platform. So that the decision for Avalonia UI is made
For example, if an app is developed for mobile devices, where there is no business process in the background, it is more about performance and a native platform experience. So that the decision for MAUI is made.
But lastly, such a decision is difficult, because it must be sustainable in the long run.
Thanks and best regards.
I don't understand why in MAUI Performance you say:
It doesn't make sense to me. Since Avalonia is built on top of .NET Mobile/Xamarin too, isn't this the same for Avalonia too?
maybe it means when you create a control in maui on android, it also will use java create this control, althoug memory that c# use is little, but it is exist.
Yes, but Avalonia is also based on .NET Mobile/Xamarin. It uses SkiaSharp to draw the controls, which means, on Android, there's two objects in memory, one in .NET and another one in Java.
the SkiaSharp control would be referenced on both sides but thats it. With Xamarin.Android, it's every single control, which is a huge performance problem.
We also have a version of Avalonia that can run without any Xamarin / .NET Mobile and the performance is incredible.
While the version without Xamarin/.NET Mobile looks fine and extreme fast in the video, it is still a preview? and as far as I know there is no real commitment date planned for it? So it could be years? And even then, there will probably be still more than enough bugs or limitations.
It's a proof-of-concept to demonstrate that we don't require Xamarin to run Avalonia. We havn't got a release date for it, because it's not a big priority for us right now. When we do release it, we'll have worked hard to make sure it doesn't have "more than enough bugs"....
The biggest difference is that MAUI/Xamarin.Forms uses a highly incompatible XAML syntax which means having rewrite most of your UI while AvaloniaUI is about 95% compatible with standard WPF.
I just ported two WPF apps to macOS using Avalonia in two weeks after literally trying to do this with Uno Platform and MAUI and Xamarin.Form for years.