GPUI: Building Native Desktop Apps in Rust with the Framework Behind Zed

Most desktop applications built in the last ten years are web pages in a box. Electron bundles a copy of Chromium and Node.js with every app, which is why a chat client or a note-taking tool can use hundreds of megabytes of memory while idle. The team behind the Zed code editor took the opposite route. They wrote their own UI framework in Rust, GPUI, which draws the entire interface on the GPU the way a game engine does. Zed reached version 1.0 on 29 April 2026 on macOS, Windows, and Linux, and GPUI is now used outside Zed as well, most visibly by the trading platform Longbridge. This article explains how GPUI works, what state it is in, and what kind of desktop application it is worth considering for.

What GPUI Is

Its own description is short: a fast, hybrid immediate and retained mode, GPU-accelerated UI framework for Rust. In practice that means three things. The application state lives in long-lived objects managed by the framework, which is the retained part. The visible interface is described again on every frame from that state, the way an immediate mode framework works, so there is no separate widget tree to keep in sync. And the result is turned into shapes, text, and images that are drawn directly by the GPU, instead of by the operating system controls or a browser engine.

GPUI uses the native graphics API on each platform. On macOS it renders through Metal. On Windows, the Zed team first tried the Vulkan renderer from Linux, found it failed on many machines, and wrote a DirectX 11 backend instead, with DirectWrite for text. On Linux it uses a Vulkan-based renderer with Wayland and X11 support. Because the framework draws everything itself, an application looks and behaves the same on all three systems.

The Core Concepts

• App and windows: an application starts the GPUI event loop, then opens one or more windows, each with a root view.
• Entities: application state owned by GPUI and shared through handles similar to reference-counted pointers. You read and update an entity through a context, which lets GPUI know what changed and what to redraw.
• Views: entities that implement the Render trait. GPUI calls render at the start of each frame, and the method returns a tree of elements.
• Elements: the building blocks of the interface. Most UI is built from div elements styled with a Tailwind-like API, such as flex, gap, padding, background, and text size. For special cases there is a low-level element API with full control over layout and painting, which Zed uses for its virtualized lists and the code editor itself.
• Actions: named operations, such as save or move to the next tab, that are bound to keyboard shortcuts in a keymap. This makes keyboard-heavy applications much easier to build.
• Async executors: background and foreground executors integrated with the platform event loop, so work such as file reading or network calls runs off the UI thread and returns results to it.
• Testing: a gpui::test macro and a test context that can simulate input, so UI behavior can be tested without opening a real window.

A minimal program is short. The application opens a window, creates a view with a single field holding some text, and its render method returns a div with flex layout, a background color, a size, and the text as its child. Anyone who has used React with Tailwind will recognize the shape of the code, although state management follows Rust ownership rules rather than hooks.

The State of the Crates in November 2026

This is the part most introductions skip, and it matters for planning. GPUI is developed inside the Zed repository, and its README says plainly that it is still pre-1.0 and that there will often be breaking changes between versions. The gpui.rs site adds that for the near future GPUI is tied to Zed, so contributions go through the Zed project. The gpui crate on crates.io was last published as version 0.2.2 in October 2025, while development continues in the repository.

• Git dependency: point Cargo at the Zed repository and pin a specific commit. You get the latest framework, but you upgrade on your own schedule and fix breaking changes yourself.
• GPUI Kit from Longbridge: the gpui-kit crate, version 0.9.0 published on 2 November 2026, bundles a pinned snapshot of GPUI with gpui-base, gpui-component, and default assets in one dependency. The snapshot is published on crates.io as gpui-pre by the maintainer of gpui-component.

gpui-component is the reason many teams can consider GPUI at all, because GPUI itself provides primitives rather than finished widgets. The GPUI Kit project lists more than 75 documented components and primitives, data tables with virtual scrolling across hundreds of thousands of rows, a code editor that stays stable at 200,000 lines with Tree-sitter highlighting and LSP support, a dock layout with draggable and resizable panels, built-in charts, Markdown and HTML rendering, and themes. It is licensed under Apache-2.0 and has powered the Longbridge Pro desktop app from the start.

How It Compares with Other Desktop Options

For most business desktop apps, the realistic choice is between Tauri and GPUI. Tauri is the safer default when the team knows web development or a web version of the app also exists. GPUI makes sense when the interface itself has to handle large amounts of data smoothly and performance is part of what the user is paying for.

Where GPUI Fits

• Trading terminals and market dashboards that update many numbers per second, which is exactly what Longbridge uses it for.
• Editors and IDE-like tools for code, configuration, queries, or structured documents.
• Log viewers, monitoring consoles, and database clients that need to scroll through hundreds of thousands of rows without lag.
• Operations tools used all day by power users who work mostly with the keyboard.
• Products where a fast, consistent native feel is a selling point against Electron-based competitors.

Where It Is Probably Not the Right Choice Yet

• Simple form-based business applications. A web app or Tauri gets there faster with a larger pool of developers.
• Products that need the same code on desktop, web, and phones. GPUI is built for desktop; GPUI Kit reports WebAssembly support, but mobile is not listed as a supported target.
• Projects with a small maintenance budget. Pre-1.0 APIs mean upgrades take real work, and staying on an old snapshot for years has its own risks.
• Applications with strict accessibility requirements. Frameworks that draw everything themselves have to implement screen reader support and native text input behavior on their own, so check the current state against your requirements before committing.
• Teams without Rust experience. Every screen in a GPUI app is Rust code, so the learning curve applies to the entire frontend, not just one service.

Getting Started Sensibly

1. 1Install the latest stable Rust, which the GPUI README requires. On macOS, install Xcode as well, since the Metal shaders need it. On Linux, enable the wayland or x11 feature and install the matching development libraries. Windows needs no extra features.
2. 2Start from the examples on gpui.rs and the gpui-component gallery rather than from a blank project, and read the Zed source when the documentation runs out. Zed is the largest GPUI codebase in existence.
3. 3Choose one dependency route, either a pinned Zed commit or GPUI Kit, and lock it in Cargo.lock. Upgrade deliberately, for example once per quarter, with time set aside for breaking changes.
4. 4Build a prototype of the hardest screen first, usually a large table or a custom editor, and measure it on the lowest-spec laptop your users have.
5. 5Set up CI that builds on macOS, Windows, and Linux from the start. Rendering backends differ per platform, and problems are cheaper to find early.
6. 6Plan packaging, code signing, macOS notarization, and auto-update as separate work items. GPUI is a UI framework; installers and updates are up to you.

GPUI is not the easy way to build a desktop app. It is the way to build one that stays fast when the data gets big.