Avalonia UI is an open-source and cross-platform UI framework for .NET developers, designed to facilitate the development of desktop applications that can run on Windows, macOS, Linux, iOS, Android, and WebAssembly. InfoQ interviewed Mike James, CEO of Avalonia UI, in order to understand more about this UI framework and its features.
InfoQ: How did Avalonia UI emerge within the ecosystem?
Mike James: The project has its roots in OSS, being community-led from its inception rather than being built by an established business and later shared. The core contributors established a company a few years back to provide support and development services to enterprises.
We recently announced our first foray into products with Avalonia XPF, our cross-platform WPF, which enables WPF apps to run on macOS and Linux with little to no code changes.
InfoQ: What are the key features and benefits of using Avalonia UI for developing desktop applications?
James: Using Skia, we enable "pixel-perfect" applications that look the same across every platform. You don't need to learn or dig into platform-specific APIs to tweak your app's UI or create custom controls! We've found that this level of customisation is essential to many of our users.
The other key benefit of Avalonia UI is that we have the broadest range of supported platforms while not compromising performance. You can develop apps for powerful desktops, low-powered embedded devices, phones, tablets, and WebAssembly.
Our API is designed to be cross-platform, and we take time to ensure that added features make sense in the context of cross-platform UI app development. While WPF and WinUI influence our APIs, we don't simply copy them; we change things where we can improve. We've always regarded blindly copying Windows APIs as a flawed strategy.
InfoQ: What is the current state of Avalonia UI in the .NET User Interface landscape?
James: When I started exploring cross-platform UIs for .NET in 2012, the only option was Xamarin. Today the landscape is very different; we have many more options, all with their strengths and weaknesses. Our strength is our ability to provide a high-performance, consistent user experience across platforms while providing developers with a familiar, stable and proven SDK.
We're often compared to MAUI, which interests me as we don't view MAUI as a competitor. When I worked at Xamarin, the significant benefit was that Xamarin apps were native apps; that is, they used the native UI toolkits. In 2013, this was extremely important, but it's no longer such a crucial component when picking a UI technology. If we look at Flutter or the growing popularity of web technologies, we see that it's possible to deliver high-quality experiences without using native UI toolkits.
We have a ton of respect for MAUI, but we see Flutter and Qt as the main competitors going forward. That's not to disrespect them, but we believe that technologies outside the .NET ecosystem are doing some exciting things.
In terms of our current state, we provide the most performant cross-platform UI toolkit for .NET developers. If developers prioritise performance, then it makes sense for them to use Avalonia UI. We achieve this by managing every pixel displayed within the application. We have very minimal dependencies, on Windows only using Win32 for the Window.
We previously had a version of Avalonia UI that depended on MonoMac, the precursor to Xamarin.Mac, but found its performance wasn’t acceptable, and thus created our own binding approach called MicroCOM.
On Linux, we only need X11, and iOS and Android just require NET.iOS and NET.Android. Once we have a native Window, we’re good to start pushing pixels and receiving user input events.
InfoQ: How is Avalonia UI positioned in comparison with Microsoft’s recent efforts?
James: We tend not to compare ourselves to MAUI, which provides respectable support for mobile but falters on other platforms. From a technical perspective, Avalonia’s approach is drastically different from that of MAUI. MAUI is less a UI toolkit and more a UI abstraction. It relies on the underlying native UI toolkit to work, while we draw the entire UI using ourselves. Most of our users are using SkiaSharp to achieve this, but our architecture makes the renderer pluggable and we’re looking at alternatives as SkiaSharp risks becoming a liability with its lack of maintenance from Microsoft.
The drawn approach yields considerable benefits, especially regarding performance, ease of development and platform support. What really illustrates this is our ability to easily support any platform. Our only requirement is the ability to push pixels and receive interaction events. To give a concrete example, you only need to look at our VNC support, which works with only ~200 LOC. It’d be impossible for MAUI to add new platforms at the speed that we can, simply due to their architecture and dependency on abstracting native UI toolkits.
Our ultimate aim is to become the first choice for every new project that requires a client app, regardless of the target platform. We deliver the best experience for desktop apps already, but we must continue improving our mobile offering to compete with Flutter. We're going to achieve this by continuing to make investments in growing the team developing Avalonia UI.
InfoQ: What is the roadmap for future development of Avalonia UI, and what new features can we expect to see in upcoming releases?
James: In the short term, our roadmap focuses on releasing v11 and overhauling the documentation portal.
v11 provides vast improvements, including a new compositional renderer, accessibility, additional platform support and much more.
Past the release of v11, we've some plans that will help us continue to drive adoption and improve the developer experience. We’re going to improve our Visual Studio extension and investigate other renderers to remove our dependency on SkiaSharp.
Interested readers can learn more about Avalonia UI and get started using the documentation and Avalonia GitHub repository.