Open Source Experiment

The same calendar app built with three different .NET UI frameworks. Compare Blazor, Uno Platform, and Avalonia side by side.

Blazor

Web framework using C# and Razor components instead of JavaScript.

Uno Platform

Cross-platform framework using WinUI and XAML.

Avalonia

Cross-platform framework using XAML and Skia rendering.

Why?

Sundy Calendar is a new project, early in development. I was searching for the "right" stack for a true cross-platform application.

I use a Mac, an iPhone, and a Windows computer in my day-to-day life and work. I occasionally use Linux, and can see myself using it more in the future to replace my Windows setup.

The goal was to build a full working application in Avalonia initially. Then I figured, why not try Uno too? Or see how other platforms feel? The real motivation is to experiment and see how things are done differently across stacks. Which feels better? Which "clicks" with me more? The last time I did true cross-platform development was with Expo, which had a fantastic dev experience.

Before starting with Uno, I tinkered with Flutter, mostly having an LLM generate a barebones calendar app to walk through the tooling. Reading through the Flutter code, I realized I wanted to stick with C#. From there, I built with Avalonia and Uno in parallel while also testing a Swift application.

After a few weeks, I realized Tauri — initially excluded from my choices — did support iOS/Android (the reason I hadn't tried it earlier). I gave it a shot, and boom: Blazor. It's no secret I enjoy working with Blazor, so it's no surprise I'm enjoying the Tauri experience.

Conclusion? None yet. Below are my current thoughts and status. Next step is to analyze this more, flesh out the Tauri-Blazor solution, and decide which stack to move forward with.

Observations

Personal experience building with each stack

Blazor + Tauri

Active development

WebAssembly in browser. Tauri for desktop (Windows, macOS, Linux) without bundling a full browser engine.

Pros
  • Feels natural coming from a Blazor/web background
  • Tooling is very good
Cons
  • Dev server doesn't end the dotnet watch process—have to manually kill it
Metrics
RAM ~242 MB
Cold boot Not measured
Bundle size Not measured

Uno Platform

Built out for now

WinUI and XAML with Skia rendering. Targets WebAssembly, iOS, Android, macOS, Linux.

Pros
  • Outstanding support from the Uno Platform team. They worked hard to ensure I could take full advantage of the framework and quickly resolved issues I encountered on dev builds.
  • MCP integration with Claude significantly improved correct implementations on the first try. While I found the documentation hard to follow, the MCP servers feeding documentation worked great.
Cons
  • Ran into lots of small issues. Some likely due to my unfamiliarity with WinUI, but none blocked progress.
  • Documentation was hard to follow and navigate. Demos focused on MVUX which I wasn't interested in using.
Metrics
RAM ~240-260 MB
Cold boot Not measured
Bundle size Not measured

Avalonia

Built out for now

XAML (own dialect) with Skia rendering. Targets WebAssembly, iOS, Android, macOS, Linux.

Pros
  • WPF/XAML syntax made styling and animation straightforward, especially with LLM assistance
  • Worked without any major hurdles
Cons
  • After signing up for the free trial, couldn't get the tooling to reflect it. Didn't file issues or contact support.
  • Couldn't get AOT build working when bundled—possibly a .NET 10 related bug

Didn't press hard on these cons since they didn't affect the experiment significantly.

Metrics
RAM ~240-260 MB
Cold boot Not measured
Bundle size Not measured

Also Explored

Frameworks evaluated but not demoed

.NET MAUI

Complete non-starter without Linux support. This may change with the Avalonia partnership. The hybrid Blazor + MAUI path is very attractive if Linux isn't a requirement.

No Linux support

Flutter

Tested as a baseline for what to expect from other stacks. Smoothest overall dev experience, aside from some CocoaPods issues (likely environmental, and this was my first foray into the experiment).

Baseline test

SwiftUI ~60 MB

Clean, fast, low memory. Would strongly consider if browser and Android targets were available.

Apple only