I've been writing .NET code since the first beta. Over three decades of professional development, I've seen the good, the bad, and the abandoned. I love C#—it remains one of the most elegant languages for building production software. But Microsoft's UI framework strategy? That's been a different story.
Recently, I needed to port a tool I'd built in SwiftUI to Windows. What started as a simple requirement turned into a deep dive through Microsoft's fragmented ecosystem and ultimately led me to abandon MAUI entirely. Here's what I learned.
The Project: Edge Debug Helper Needs Windows Support
In my current role as a Developer Advocate at Ditto, I work with developers building applications using Ditto—an offline-first mobile database platform that enables peer-to-peer mesh networking and real-time data synchronization. Ditto solves a critical problem: applications that need to function reliably regardless of network connectivity. Using Conflict-Free Replicated Data Types (CRDTs), Ditto automatically handles data synchronization across devices via Bluetooth, Wi-Fi, or LAN without requiring constant cloud connectivity. It's particularly valuable for field operations, collaborative applications, and scenarios where internet access is unreliable or unavailable.
I wrote Edge Debug Helper to debug Ditto apps when working with the MongoDB Connector. SwiftUI let me prototype quickly—within days I had a functional macOS tool. But as I started working with developers on Windows, the limitation became obvious: I needed cross-platform support.
My first instinct was Rust. I'm learning the language, and it offers genuine cross-platform capabilities. But the learning curve was steeper than I anticipated with limited UI libraries, and I was spending more time fighting the borrow checker than building features.
Then I thought: why not return to .NET? I've used it throughout my entire career. Like SwiftUI, I should be able to get something running quickly. C# is a joy to work with. The question wasn't whether to use .NET—it was which .NET UI framework to use.
Microsoft's Platform Abandonment Problem
Here's where things get frustrating. Microsoft has a terrible track record with UI frameworks. Let me count the casualties:
- Windows Forms - Still technically supported, but ancient
- WPF - 20 years old, Windows-only
- Silverlight - Abandoned, leaving countless developers stranded
- UWP - Dead, officially discontinued after promising write-once, run-everywhere
- WinUI - Uncertain future
- Xamarin - Forcibly migrated to MAUI with support ending May 2024
- MAUI - The latest attempt, and spoiler: it's not great for desktop apps
This pattern represents millions in wasted development effort across the industry. Every few years, Microsoft pivots to a new framework, and developers are left rewriting applications or maintaining legacy code. It's exhausting.
I stumbled across this blog post from Avalonia comparing WinUI, WPF, and UWP. Reading their analysis of Microsoft's broken strategy made me smile—finally, someone saying what we've all been thinking. The constant churn isn't sustainable. Microsoft cannot be trusted with long-term UI framework investment.
But I still needed to build my app. So I started with the obvious choice: MAUI.
MAUI: The Choice That Disappointed
MAUI is Microsoft's official cross-platform framework, so naturally, I tried it first. The experience was terrible when using it to target desktop apps.
macOS Performance Was Abysmal
MAUI on macOS uses Mac Catalyst, not native AppKit. The performance was horrible. This isn't a full macOS application—it's an iOS app awkwardly shoehorned onto the desktop. For a developer tool that needs to feel responsive, this was unacceptable.
Theming Was Painful
Getting a Windows app to look decent took far too much work. Making the same app look nice on macOS? Even worse. The default controls feel out of place on every platform.
Signing and Packaging Was a Nightmare
To ship a proof-of-concept to a colleague's Windows machine—without requiring dev tools—I needed to sign the application. The process was painful.
I get it: Apple requires signing too. But Xcode Cloud auto-signs builds and makes this essentially a non-issue for macOS/iOS developers. Microsoft provides no equivalent service. You can cobble together GitHub Actions workflows, but they're complex, especially for someone who hasn't done full-time .NET development since 2019.
The Jank Persists in .NET 9
Even in the latest stable release, MAUI has rough edges. I tried the .NET 10 beta hoping CollectionView improvements would help, and they did—but relying on beta releases for basic functionality isn't acceptable.
Linux Support? Forget About It
MAUI's Linux support is effectively non-existent. This became critical when I bought a uConsole—a portable Linux device perfect for testing Ditto's peer-to-peer mesh networking. The moment Linux became a requirement, MAUI was out.
MAUI isn't ready for production cross-platform development that need to target MacOS, Windows, and Linux . Maybe it'll improve, but I've heard that promise before with Silverlight, UWP, and every other framework Microsoft has abandoned.
Uno Platform: Impressive DevTools, But Still Some Jank
Next, I explored Uno Platform. This framework impressed me immediately.
The Developer Tools Are First-Class
Uno's tooling is everything MAUI should be but isn't. Hot Design with AI assistance, real-time XAML updates, Figma integration—these features make writing XAML applications genuinely enjoyable. I can't emphasize enough how good Uno's developer experience is compared to MAUI. They're leading the industry in making XAML development productive.
The Project Structure Is Complex
Despite the excellent tooling, Uno's project structure left something to be desired. For someone returning to full-time .NET development after several years, the complexity was daunting. Multiple projects, conditional compilation, platform-specific implementations—it all felt heavier than necessary.
Linux Support Was Better, But Still Not Great
Uno supports Linux, which put it ahead of MAUI. But the support isn't quite production-ready. I needed something more mature.
There Was Still Some Jank
I documented issues I encountered during livestreams on my YouTube channel. To Uno's credit, the team released updates that resolved some of these problems. They clearly care about the developer community, and my interactions with the team have been extremely positive.
Uno Platform is impressive. If Avalonia hadn't worked out, Uno would have been my choice. But then I discovered something that changed everything.
The Game Changer: Avalonia's Packaging Solution
I shelved the project for a few months—my wife and I had a baby in September. When I picked it back up in October, I was nearly ready to commit to Uno. Then I saw this LinkedIn post from Mike at Avalonia about their new packaging solution.
This was like Xcode Cloud, but for .NET. You can tell an AI assistant: "Package my Avalonia app for macOS as a signed DMG," and two minutes later, you have a production-ready, signed application. No certificate wrangling. No build scripts. No wasted afternoons.
Here's the kicker: you can build and sign macOS DMG files from Windows. This is typically impossible through conventional methods.
I got excited. Really excited. Excited enough to try Avalonia for the first time, even though I was nearly finished with my Uno POC.
Building with Avalonia: Fast and Productive
I started with two screens: a login screen and a main UI displaying connected Ditto SDK peers. If Avalonia worked well for these screens and the packaging was solid, I'd migrate from Uno.
Documentation Was Clear and Comprehensive
Both screens came together fast. Avalonia's documentation is excellent—clear, comprehensive, with good examples. Controls worked as expected. Everything felt solid.
The First UI Wasn't Pretty
My initial attempt didn't look great. I explored theming options and found Material Design support. But it wasn't complete Material Design—it was an older version with glitches like outline text not rendering properly.
I tried Fluent Design next, but it looks terrible on macOS. Nothing close to the polished UI that SwiftUI provides out of the box.
I was getting discouraged. Then I discovered SukiUI.
SukiUI: The Missing Piece
SukiUI is an incredible project—a comprehensive desktop UI library specifically for Avalonia. With minimal setup (just following the installation instructions), my app immediately looked more attractive.
I switched to their GlassCard control, and suddenly my app looked really nice. Professional. Polished. Modern.
Next, I refactored my navigation to use SukiUI's Side Menu. The transformation was remarkable. My app went from "functional but ugly" to "something I'd actually want to use."
Not Everything Was Perfect
The Dock control had some issues. I posted in their forums, and they recommended upgrading to a nightly build. Since I wanted to stay on stable releases, I simply removed the Dock code temporarily. This is active development—issues get fixed quickly.
Performance: Avalonia Edges Out Uno
I didn't see massive performance differences between Uno and Avalonia. Both render quickly on my target platforms. But Avalonia seemed slightly better in memory usage, and from a UI standpoint, I loved how my app looked and felt with SukiUI more than my Uno implementation.
Performance on Windows, macOS, and Linux was solid across the board.
Avalonia's Bright Future
Two developments have me particularly excited about Avalonia's roadmap:
Next-Generation Rendering
Avalonia is exploring new rendering with Impeller, the rendering engine that Google wrote for Flutter. Impeller delivers smooth, consistent performance, higher average frame rates, and reduced VRAM use. It is unapologetically GPU-first, making it ideal for modern hardware where predictable performance and power efficiency are essential.
This isn't ripping out the stable SkiaSharp backend. Avalonia is taking a measured approach, offering multiple rendering backends so developers can choose what works best for their use cases. Stability first, with experimental options for those who need cutting-edge performance.
MAUI Linux Rendering
Avalonia is now providing the rendering layer for MAUI on Linux. Read that again: Microsoft's own framework is depending on Avalonia for Linux support. That's a remarkable validation of Avalonia's technical foundation.
The Verdict: Avalonia Won
After building POCs in MAUI, Uno, and Avalonia, I chose Avalonia. Here's why:
SukiUI Makes My App Beautiful
The transformation SukiUI provides is remarkable. My app looks professional with minimal effort, and working with the component library has been smooth.
Documentation and Community Are Strong
Avalonia's documentation is comprehensive and clear. The community is active and helpful. When I have questions, I get answers quickly.
DevTools and Parcel Are Essential
Avalonia's DevTools and Parcel are game-changers. I'll admit Uno's designer tools are better than Avalonia's DevTools in some ways, but Parcel—especially the packaging and signing automation—more than makes up for it.
The subscription cost is affordable, even for small teams. If it means I don't have to deal with signing and packaging nightmares, it's worth every penny.
Performance Is Solid Across All Platforms
Windows, macOS, and Linux all perform well. No Mac Catalyst compromises. No platform-specific jank. Just consistent, responsive applications.
I'm Past the POC Phase
With Avalonia, I moved from proof-of-concept to feature development quickly. Good documentation and extensive example code mean I'm productive, not fighting the framework.
What About Uno?
Uno Platform is genuinely impressive. Their developer tooling is industry-leading, and the team clearly cares about developers. If you're heavily invested in the Microsoft ecosystem or need the specific features Uno provides, it's a solid choice.
For my project, Avalonia was the better fit. But Uno deserves recognition for pushing the entire .NET UI ecosystem forward with their tooling innovations.
What About MAUI?
I can't recommend MAUI for serious cross-platform development that need desktop support for MacOS, Linux, and Windows. The macOS performance is poor, Linux support is essentially non-existent, and the rough edges suggest it's not production-ready. Maybe Microsoft will fix these issues, but I've been a .NET developer for three decades. I've seen this pattern before. In my humble opinion Microsoft is not investing enough in Maui when you see small companies like Uno and Avalonia making better solutions than the huge company that is Microsoft. How serious is Microsoft about Maui when Uno and Avalonia are just SO much better?
Avalonia works today. I'm not waiting for Microsoft's next pivot.
Moving Forward
I'm excited to finish my app over the holiday break. Avalonia has proven to be fast, stable, and genuinely cross-platform. The documentation is excellent, the community is strong, and the tooling removes the pain points that have plagued .NET desktop development for years.
After 30 years of .NET development—through Windows Forms, WPF, Silverlight, UWP, Xamarin, and MAUI—I've finally found a framework I can trust for the long term. It's not from Microsoft, and maybe that's exactly why it works.
If you're building cross-platform .NET applications, give Avalonia a serious look. It's what MAUI should have been.
Top comments (0)