GPUI

Last updated: Oct 28, 2026

---

Rationale

GPUI is the desktop UI technology that Fluid Attacks uses to build native applications in its Rust-first stack. It is a GPU-accelerated UI framework. Zed Industries developed it and uses it in production as the foundation of the Zed code editor.

These are the primary reasons why Fluid Attacks selected it:

• It is open source.
• It is pure Rust from end to end. Fluid Attacks also uses Rust for the domain logic of the application. Thus, the full app (the UI and the core) is one type-checked codebase with no language boundary, no JavaScript bridge, and no inter-process serialization between the view and the engine.
• It renders on the GPU with an immediate-mode model. Thus, interactions are fast, and the UI code is easy to understand.
• One Rust toolchain produces a self-contained binary. Thus, the build, linting, and distribution stay simple.
• With it, Fluid Attacks can enforce a functional-core/imperative-shell architecture. In this architecture, the pure domain crate is no_std (the compiler proves that it cannot get to the filesystem, network, or clock), and only the GPUI shell does input/output.
• It works with the design system of Fluid Attacks. Thus, the desktop tools natively use the design language of Fluid Attacks.

Alternatives

Qt (PyQt)

• It is a mature, cross-platform, native desktop toolkit. Fluid Attacks uses it through the PyQt bindings.
• At this time, Fluid Attacks uses it for signals, its security-assessment desktop tool in Python, and it continues to be a good selection for that tool.
• It is the correct tool for a Python desktop application, but it is not as good a fit for the Rust-first stack as GPUI:
  • It uses two languages through a C++/Python binding layer.
  • It ships a large C++ runtime, not one Rust binary.
  • Its licensing (GPL/LGPL or commercial) is more restrictive than the permissive license of GPUI.

Tauri

• It is open source.
• Fluid Attacks built, shipped, and tested a real version of an internal tool on Tauri before it moved to GPUI. Thus, this is a tested alternative, not a theoretical alternative.
• It has a Rust backend and a web frontend (HTML/CSS/JavaScript) that the WebView of the operating system renders. The result is two languages and a serialization boundary between the UI and the Rust core. Thus, it adds glue code and a class of runtime errors that the compiler cannot find.
• You cannot type-check the web frontend together with the Rust domain. Thus, when a shared shape changes, you must keep the two parts in sync manually.
• The rendering and behavior depend on the WebView of the platform, which is different for each operating system and version.
• It is a good alternative when a team has a web frontend or web skills that it can use again, and wants native packaging around them.

egui

• It is open source and pure Rust, with a simple immediate-mode model.
• Its visual style is for tools and debug UIs. Thus, it is harder to get pixel-accurate, polished native chrome than with GPUI.
• Its component ecosystem is smaller.

Iced

• It is open source and pure Rust, with an Elm-style architecture.
• It is promising, but it is less proven than GPUI at the scale of a full application. (The Zed editor uses GPUI in production.) Also, it has a smaller component ecosystem.

Usage

Fluid Attacks uses GPUI for:

• mrq, its merge-request review companion, a macOS desktop client that is fully in Rust.

Widgets

The desktop widgets come from the design system of Fluid Attacks, which Fluid Attacks publishes as the fluidattacks-designs crate, over the shared tokens in fluidattacks-designs-domain. The two crates are projections of the same React library that the web uses. Thus, a desktop tool and the platform look like one product.

When Fluid Attacks owns the widgets, its design language does not depend on the roadmap of a different company. Also, the components can use the tokens that the web publishes, and no third-party widget library is in the dependency graph.