logo

I built the same 8 apps in 10 Rust GUI frameworks (80 apps, macOS + Linux + Windows) to find out where desktop GUI actually breaks

92 points GoldStrikeArch- 65 comments
View on Reddit ↗

A few years ago I tried to build a desktop app in Rust and gave up. Not because of the borrow checker. I got stuck on the boring stuff: a tray icon that worked on macOS but broke on Windows, a file dialog that didn't work at all, things like that.

I came back to it this year and it's much better than I remembered. It's also still fragmented, and I couldn't find anyone who had measured where, so I did it myself.

I picked 10 frameworks (iced, egui, gpui, tauri, xilem, slint, dioxus, freya, vizia, floem) and wrote the same 8 apps in each of them:

  • a classic todo
  • a live metrics dashboard
  • a kanban board with drag and drop
  • an OS shell app (tray, global hotkey, native menubar, clipboard images, file drop, notifications)
  • a multilingual text corpus
  • camera and mic capture
  • a 100k-row data grid
  • a network fetch app

The first run was on my MacBook M4 Pro. I measured build times, binary sizes, dependency trees, CPU and RSS, and packaged the todo apps into DMGs. Then I rebuilt everything on Linux in a headless container, and again on a real Windows 11 laptop.

Write-up, repo, apps, and a second page just on the OS shell layer:

Important disclaimer: These are small apps and none of this is a general performance ranking of frameworks. "Which one is fastest" needs its own study, and I want to do that later.

Some things that surprised me

  • The bottom of the stack is consolidating fast. HarfRust now shapes text for cosmic-text, parley and egui, all within 12 months, and AccessKit and taffy have both crossed framework lines the same way. The "everyone reinvents everything" reputation is out of date today.
  • The top hasn't. Four text-layout stacks are still maintained in parallel and layout is the expensive part: line breaking, bidi, rich text, caret semantics, etc
  • Linux shell integration is where it hurts. Every one of my macOS-written tray apps compiled on Linux with zero source changes and then panicked at launch inside muda's first GTK call.
  • Windows was worse than I expected, and almost none of it was Rust's fault. 28 of 80 apps failed cargo build --release as-is, including three entire frameworks at 0/8 and all three of them dying in packaging and toolchain infrastructure rather than framework code.
  • Packaging splits in two. The mechanical half is nearly free now (dx bundle built DMGs for 9 of 9 non-Tauri apps first try), and the "trust" half (signing and notarization) is still the cliff.
  • The sharpest text finding was about editing, not rendering. Backspace over a ZWJ family emoji (for example the emoji "👩‍💻" is "👩" plus a zero-width joiner, U+200D, plus "💻") splits the cluster or leaves a dangling joiner in five of the ten editing paths I tested. That one looks upstreamable.

There's a lot more on the dashboard, including per-framework verdicts and a "choose in five questions" decision path.

Why I'm posting this

This is the opening research for an initiative in the Rust Commercial Network (RCN), a Rust Foundation program that connects companies shipping Rust with the maintainers and work they depend on. More details: rustfoundation.org/rust-commercial-network

The goal is to make cross-platform desktop GUI development in Rust easier and more accessible. That's broad, so here are the two concrete threads so far.

A funding target list. Where money and paid maintainer time would do the most: iced's AccessKit integration, de-GTK'ing Linux shell integration into winit-compatible facades built on ksni and ashpd portals, sustainability for AccessKit and rcodesign (those are just an examples, not really WIP), and a framework-neutral packaging story. Nico Burns made the strongest version of this argument in our Zulip thread. winit has had 3 to 4 maintainers for three years, none paid, none full time, and it sits under everything except Tauri and GPUI. His pick for the #1 fix is a team of 2-5 people working on winit full time.
A Rust GUI book. Something like the official Rust book plus Ratatui's recipes section. Where "how do I put an icon in the tray on all three platforms" has an answer you can copy. The 80 apps in the repo are already a rough first draft of the recipe list, because every one of them has a FRICTION.md documenting what went wrong.

This is not the first attempt

areweguiyet.com has tracked the framework list for years, though it covers GUI generally rather than cross-platform desktop specifically. Sid Askary organized Rust GUI calls for Futurewei for roughly three years, and there have been in-person unconferences at the last several RustWeek/RustNL conferences with Dioxus, Makepad, Slint, Linebender, AccessKit, egui, winit, Bevy and Servo represented. This initiative isn't trying to replace any of that. What RCN adds is a route to getting commercial users in the same room as maintainers and to paying for some of the work.

If you want to join the initiative

Anyone maintaining or shipping with these frameworks or anyone who has fought this in the past is exactly who we want. There's plenty of open-source work to go around, and part of the point of doing this under RCN is that some of it might eventually be paid work.

Corrections welcome. If I got something wrong about your framework, tell me and I'll fix the page. Several findings above already came from maintainers correcting an earlier draft.