The Rust desktop GUI ecosystem, measured

The ecosystem is consolidating from the bottom of the stack upward. In the last 12 months the principal reusable pure-Rust text stacks converged on HarfRust, Zed dropped its custom Linux GPU layer for wgpu, and Slint/Bevy/floem migrated to parley/fontique. AccessKit is now the shared native accessibility layer. iced and floem remain unintegrated (floem's pinned rev has no accesskit anywhere in its dependency tree), while gpui support is unreleased and currently disabled in Zed. The top is still fragmented: text layout, 2D renderers, widgets, and windowing forks.

A GUI framework is a tower of layers: window (winit opens the window and feeds you input) → GPU (wgpu turns one API into Metal/Vulkan/DX12) → 2D renderer (turns "rounded rect with shadow" into GPU work or pixels) → text (find fonts → shape glyphs → lay out lines) → layout (taffy computes flexbox math) → a11y (AccessKit feeds screen readers) → widgets. Several lower-layer pieces are increasingly shared. These four stories are where sharing still breaks down.

The shared infrastructure under the sampled frameworks, ranked by how concentrated and how funded they look from public evidence. The table contains 21 entries; 15 are rated amber/red. "Author concentration" is a heuristic derived from dated public commit attribution, not a measured probability of collapse, and "none found" means no public direct funding source was identified, not proof that a contributor is unpaid. Exact reverse-dependency, sponsor, and search-result counts are dated snapshot observations whose raw query responses were not retained. Full sourced table: report/data/load-bearing-crates.md.

A todo app (text input, Enter shortcut, per-row delete, live counter, scrolling) built idiomatically in each framework, versions pinned. All ten compiled and survived the launch check; later inspection observed their windows, and the implementations cover the source-level spec (GPUI exposes low-level elements and a hand-built input example but no reusable first-party high-level input widget, so this app approximated text input). On this M4 Pro, these ten small apps each clean-built in under a minute from a warm registry and empty target directory; that is not a general large-application ranking. Floem is the one deviation from the "latest crates.io release, pinned =x.y.z" rule: its published 0.2.0 was 20 months stale at measurement and main cannot be published (it depends on a forked winit and on git-only understory_* crates), so all eight floem apps pin git rev 778bb5f2. The unpublishable-main situation is itself a finding.

Round 2 tested interaction: drag-and-drop, live data, custom charts, hover interactions, inline editing, animation. Two more apps per framework. "Pulse" is a live metrics dashboard (draggable card grid, 1–60 Hz data at default 10, hover-tooltip chart) and "Board" is a kanban (cross-column DnD, drop indicators, double-click edit). All 20 built and survived the scripted launch check, and later inspection observed their windows (floem's two retained records are launch-liveness only); interaction evidence ranges from source/API paths through retained app tests as marked per capability. Full data: report/11-interactive-results.md + per-app FRICTION.md.

¹ The sample has no shared automatic FLIP/position-transition abstraction: stock iced/xilem layouts snap, while the implementations used egui tweens, hand-built CSS FLIP, explicit Slint x/y animation, or the framework-owned tweens and springs of the 2026-08-03 trio. Vizia comes closest, since a CSS transition: height genuinely animates a layout property, so the kanban's insertion gap opens and closes. Even so, no framework automatically transitions a card it did not itself move: Slint and floem animate positions only because the app positions cards by index or the framework owns the drag ghost. ² iced's time::every needs a non-default executor feature; the compile error gives no hint.

One quick-note app per framework exercising everything AROUND the window: tray, global hotkey, native menubar, dialogs, clipboard (text + image), Finder file-drop, notifications, live dark mode, multi-window, close-to-tray. Zero implementation-level not-achievable cells on tested macOS. All ten frameworks exposed a viable path, although Finder drops and some notification results were source/API-level rather than real end-to-end observations. Full matrix + evidence notes: report/12-shell-integration-results.md. The round's traps and reference shapes are distilled into a facade requirements brief: the winit shell facade, specified.

¹ A trap reproduced in these 3 integrations: muda's predefined Edit items silently swallow ⌘X/⌘C/⌘V before the framework's own bindings, so the standard Edit menu breaks paste app-wide. Freya, vizia and floem all reach the same muda API and all three deliberately avoided the predefined Edit roles for this reason. ² notify-rust was rejected for different reasons in the two frameworks: egui hit a frame-scheduling freeze in two of three runs (cause unproven; a 2026-08-30 source check rules out the earlier delegate-replacement hypothesis and points at the helper's synchronous run-loop pumping; no minimized reproduction was retained), while xilem hit AppleScript's blocking app chooser for the use_default bundle id, a winit re-entrancy panic-abort, and silent no-banner delivery from a detached thread. ³ eframe never runs App::ui for hidden viewports, so reopen logic must live elsewhere or the window can't come back. Round upset. dioxus quietly matches Tauri here (tray, hotkey, menubar, multi-window, close-to-tray all built-in). 2026-08-03 addendum. floem is the only native-rendered framework here with native menubar, dialogs, file-drop, live dark mode, multi-window and Dock-icon reopen all built in, none of it documented outside its source. freya's tray feature owns the global tray-icon/muda handlers itself, which structurally prevents the muda channel-splitting trap dioxus hit, a trap iced and egui avoided only by deliberately routing both menus through the tray_icon::menu re-export, and floem escaped by accident via a muda version mismatch; vizia ships no shell layer beyond windowing, but its models run on the main thread with no Send bound, so the !Send tray handle just lives in app state. Scope note. This is macOS; the Linux GTK fault line (muda menubars cannot attach to plain winit windows; global-hotkey is X11-only) still holds as documented in the fragmentation stories.

The same multilingual corpus (Latin ligatures, Arabic/Hebrew BiDi, Chinese/Japanese/Korean, Devanagari, Thai, ZWJ emoji, one all-scripts line) rendered by every framework. Verification used screenshots plus OCR/glyph/caret diagnostics described in each FRICTION file. All ten screenshots are retained, but not every raw diagnostic output is; exact caret/OCR/mark counts and caption-specific interpretations therefore remain local observations rather than independently reproducible results. Full matrices incl. evidence levels and editing behavior: report/13-text-i18n-results.md.

The three stacks added on 2026-08-03 are not embedded above (page weight); their window-scoped captures are retained at apps/freya-babel/screenshot.png, apps/vizia-babel/screenshot.png and apps/floem-babel/screenshot.png. Verdicts: freya (Skia textlayout over CoreText) renders all 11 corpus lines, no tofu, 0 bytes of bundled fonts; vizia (SkParagraph over CoreText) also renders all 11 lines, no tofu, 0 bytes bundled; floem (parley/fontique) is the second stack in the corpus to hit the fontique Han-discovery hole xilem exposed. Han and kana ([ZH], [JA], and 世界 inside the mixed line) render as pure tofu because fontique 0.7.0 (floem's pin) rejects CoreText's PingFang answer, which has no readable font file on macOS 26, while Hangul, Devanagari, Thai and BiDi are all correct; regional-indicator flag pairs are tofu too (a harfrust AAT shaping bug). Both are fixed upstream in fontique/parley 0.8.0 (2026-03), so the fix is a dependency bump in floem, not app code (status checked 2026-08-30).

Editing is the sharper finding. Rendering mostly works. Backspace over 👨‍👩‍👧‍👦 deletes the whole cluster in WebKit and gpui's hand-rolled editor, shrinks it through valid smaller emoji in Slint (by design), and splits the cluster or leaves a dangling zero-width joiner in the tested iced, egui, and xilem editing paths. Those integrations lacked whole-cluster deletion out of the box. Source re-check 2026-08-30: cosmic-text 0.15's Backspace deletes one char while its Delete uses grapheme clusters (unreported — we are filing it); parley 0.6's backdelete treated one char as a cluster and is fixed on main by PR #715 (unreleased); egui deletes per char by design. The 2026-08-03 trio splits the same way from three more stacks: floem's Lapce editor core treats the 25-byte family as a single caret stop (the best grapheme behaviour measured here), vizia moves and selects by grapheme but deletes by scalar (its emoji state machine never advances its cursor — a one-line fix, unreported, we are filing it), and freya-edit 0.4 moves the caret by UTF-16 code unit, so a caret can land inside a surrogate pair and one Backspace corrupts the cluster and leaves a dangling joiner, in a crate that already depends on unicode-segmentation (fixed upstream in freya-edit 0.5.0-rc.1, PR #2034). Egui also dropped 13 corpus combining marks; Slint showed one notdef mark and clipped tall stacks. macOS AX selected-text queries returned garbled RTL text for egui; actual screen-reader speech was not exercised, so assistive-technology impact remains an inference.

The seven July iteration-1 apps were bundled into launching DMGs containing ad-hoc-sealed .app bundles. The "packaging is the hard part" claim splits in two. The mechanical layer is nearly free. A revived cargo-bundle packaged all six non-Tauri frameworks with an identical 4-line stanza, under a minute each, and it beat cargo-packager, the ecosystem's "intended answer," head-to-head in this run. The trust layer is the real cliff. With no identity configured, none of the tested runs produced a distribution signature. cargo-bundle lacks signing, while Tauri/cargo-packager support it when configured. The create-dmg flows failed repeatedly on this macOS 26 machine, while a plain hdiutil create fallback was more reliable. In the standard quarantined-distribution path tested here, spctl rejected all seven of those ad-hoc bundles as expected without Developer ID signing and notarization; Tauri, cargo-packager, and the principal Rust-native cross-platform implementation rcodesign automate parts of that workflow but cannot supply Apple credentials. Bundle sizes: 5.0 MiB (GPUI) → 14.7 MiB (Slint). Reliable app-attributed notification banners and dock behavior also benefit from a bundled, identified .app. 2026-08-08 completion. The current freya, vizia and floem apps went through the identical cargo-bundle pipeline. All three launch, seal, and hdiutil-verify (spctl rejected as expected); floem, packaged for the first time, is smaller than the Skia-static pair (17.1 vs 20.3/21.7 MiB .app). The same day, an RCN-thread tip was tested: dx bundle (dioxus-cli 0.7.10) packaged all nine non-Tauri apps 9/9 from a 4-line Dioxus.toml each, and its built-in DMG step succeeded first-try for all nine, the exact step that failed on 6 of 8 tool paths in July. Costs: it rebuilds each app under its own desktop-release cargo profile (~24–53 s) and ignores [package.metadata.bundle]. Its macOS signing/notarization automation exists in the 0.7.10 code but was not exercised (no credentials, by design). Details: report/14-packaging-results.md + report/data/packaging-results.md.

Round 4 tested the last untested dimensions: "Peek" (camera preview ≈30 fps, mic meter, audio, 200-image gallery), "Grid" (100k rows: virtualization, sort, filter, resize, selection), and "Fetcher" (debounce, streamed progress, and cancellation proven by a local server that logs client disconnects). All 30 apps built and ran. Full matrices with per-cell evidence labels for the original seven: report/15-media-hardware-results.md, report/16-data-grid-results.md, and report/17-async-network-results.md; the freya/vizia/floem evidence lives in report/data/iter4-rows.md and the per-app FRICTION.md files.

The macOS-built apps, rebuilt and run on Linux headlessly (lavapipe software Vulkan + llvmpipe GL, WebKitGTK 2.50.6, one plausible CI configuration). All 11 tested apps compiled with zero source changes (gpui needed one -dev system package at link time); the differences live mainly in the render path and the shell layer. Font discovery/fallback and gpui's present path also differ per platform. This round predates the expansion: freya, vizia and floem have not been built or run on Linux. Verbatim logs, screenshots, and probe sources retained. Full report: report/18-linux-reality-results.md.

The 80 apps, rebuilt and launch-probed on one real Windows 11 x64 laptop (MSVC toolset pinned to 14.34, 200% DPI, WebView2 151.0.4129.59). 28 of 80 apps fail cargo build --release as-is, including three entire frameworks at 0/8 (tauri, freya, vizia), all three on packaging/distribution infrastructure rather than framework Rust code. 36 reached a visible window on the default env, and WGPU_BACKEND=dx12 rescued all 14 of the intermittent wgpu surface deaths. Verbatim logs, per-variant runs, screenshots and CSVs retained. Full report: report/21-windows-reality-results.md.

Two specs an r/rust commenter asked for: "Windows" (what is a window — modality, parenting, shared state across windows, close veto, persistence) and "Ledger" (can the text input be a numeric input — typed filtering, locale, decimal alignment, tab order, undo — plus the corpus' first verified accessibility-tree dump). All 22 apps self-test (SELFTEST DONE … fail=0) and were re-verified by three independent passes. Full write-up: report/22-windows-forms-results.md; normalized 11-column matrices: report/data/verification/iter5-matrix.md.

Whatever you pick, prototype the riskiest screen first (not hello-world), pin versions exactly (several audited tutorials were stale; this was not universal), test Linux on Wayland + NVIDIA early, and budget real time for packaging, signing, and updates. Tauri has the most integrated first-party chain; other stacks assemble maintained bundlers, platform tools/rcodesign, and Velopack.

1. Finish the accessibility map: fund iced's AccessKit integration. The tracking issue is iced#552 (open since 2020); the live draft PR #3111 demonstrates VoiceOver on one limited Button/Text example; the most complete community attempt, PR #3281, was closed unmerged in Mar 2026. System76's fork ships a11y today via pop-os/iced. Upstream integration would close the baseline gap in this sample, but still requires widget semantics, adapter QA, maintenance, and upstream acceptance; Floem and GPUI product readiness remain separate gaps.
2. De-GTK Linux shell integration. Today muda menubars need a GTK window and cannot attach to a plain winit window, tray-icon needs a parallel GTK event loop, and global-hotkey is X11-only; winit has no menu/tray API (winit#403, #3108). Integrating existing Rust portal/SNI/DBusMenu implementations into maintained winit-compatible facades would improve menus/tray/hotkeys for every winit-based framework, and would remove part of the remaining rationale for the tao fork (tao#509, wry#1014). Movement is real here: as of July 2026 Tauri has a merged gtk4 backend built on winit's 0.31 pluggable-backend architecture (winit-gtk4) and an open PR consuming it, though that architecture itself is still beta-only (stable winit remains 0.30.13). The corpus's requirements-and-traps input for this effort is distilled in the winit shell facade, specified (+ report/19-shell-facade-spec.md).
3. Explore fontique interoperability for cosmic-text. fontdb has had no release since Oct 2024 and this audit found no announced maintainer succession; cosmic-text uses it and is a significant consumer in this sample. Slint already made this exact migration (slint#9564, 1.14) to fontique. A migration or adapter could reduce duplicate font discovery/fallback work, subject to maintainer and compatibility review.
4. Sustainability grants for AccessKit and rcodesign. AccessKit now has one active maintainer: since April 2026 Arnold Loubriat has merged every pull request and cut every release, in his spare time, with two individual GitHub sponsors. The 2023–24 Sovereign-Tech-Fund-backed work administered via GNOME is wrapped up (GNOME STF report), and the one later grant — NLnet NGI0 Commons, iOS support, from 2025-11 — was scoped to a feature and is delivered. If you fund one thing in this stack, fund AccessKit's maintainer. rcodesign, the principal open-source Rust-native cross-platform implementation found, has concentrated maintenance and no release since Nov 2024.
5. Bless a framework-neutral packager. Non-Tauri apps lack one equally integrated bundle + sign + runtime-update chain. cargo-packager had current commits as of June 23, 2026, but its latest release was 0.11.8 from November 2025. cargo-bundle is minimal. dist is CLI-shaped. The strongest measured candidate so far is dx bundle (officially any-Rust-project since 0.7.0). It packaged all nine non-Tauri apps 9/9, with a first-try DMG step and in-code signing/notarization automation. Cost: its own config file and build profile. Linux formats were untested here. On Windows it emitted an NSIS exe, not the documented MSI. Silent install/uninstall worked; the installed copy failed the launch check. cargo-packager's WiX route built an MSI from every buildable app (all seven installed and uninstalled cleanly; the MSI-installed dioxus-app copy failed the same launch check). cargo-bundle MSI and cargo-packager NSIS went 0/10. Improve a shared composition around dx or cargo-packager, or standardize on Velopack (official Rust crate) + rcodesign.