A 2026 Survey of Rust GUI Libraries

2026 年 Rust GUI 库调研

It has been more than one year since boringcactus’s A 2025 Survey of Rust GUI Libraries. That was indeed a very interesting blog; so interesting that I wanted to try it myself. So I will be testing and reviewing each of the libraries listed on the Are We GUI Yet? website. 距离 boringcactus 的《2025 年 Rust GUI 库调研》已经过去一年多了。那确实是一篇非常有趣的博客，有趣到我也想亲自尝试一下。因此，我将对 Are We GUI Yet? 网站上列出的每一个库进行测试和评估。

The task I chose is a QR Code Generator. The interface has a text box; when text is entered, the Rust backend calculates the corresponding QR Code based on the text and displays it below the text box. 我选择的任务是制作一个二维码生成器。界面包含一个文本框；当输入文本时，Rust 后端会根据文本计算出相应的二维码并显示在文本框下方。

This task can cover many aspects that GUI frameworks need to consider. For example, the text box involves IME support, and displaying images from the backend tests the framework’s compatibility with the existing Rust ecosystem. In addition, this task is also a simplified version of a real example I encountered when I first used Rust to develop a GUI program this year. 这个任务涵盖了 GUI 框架需要考虑的许多方面。例如，文本框涉及输入法（IME）支持，而从后端显示图像则测试了框架与现有 Rust 生态系统的兼容性。此外，这个任务也是我今年第一次使用 Rust 开发 GUI 程序时遇到的真实案例的简化版。

Beyond basic feature completeness, I’ll also give a fairly subjective usability rating, covering state management, styling, the complexity of scaffolding an initial project, and the editor experience. 除了基本的功能完整性外，我还将给出一个相当主观的易用性评分，涵盖状态管理、样式设计、初始项目构建的复杂性以及编辑器体验。

To get a realistic feel, I’ll try to hand-write each task as much as possible. Of course, in 2026, a major difference is the practical adoption of coding agents. If, during this survey, I come across a framework whose correct usage I can’t figure out myself, but a coding agent can write the correct code on my behalf, then I’ll still give that framework some credit for usability. 为了获得真实的感受，我会尽量手写每一个任务。当然，2026 年的一个重大区别是编码智能体（coding agents）的实际应用。如果在调研过程中，我遇到了自己无法弄清正确用法，但编码智能体能代我写出正确代码的框架，我仍然会给予该框架一定的易用性加分。

I’m on macOS, so the survey will be based on the macOS platform. For certain Windows-specific frameworks, I will also try running them in a Windows VM. The conclusion and the table are at the end of this article. 我使用的是 macOS，因此本次调研将基于 macOS 平台。对于某些特定于 Windows 的框架，我也会尝试在 Windows 虚拟机中运行它们。结论和汇总表格位于本文末尾。

Azul

When I opened Azul’s homepage, I was greeted by a rather ambitious page introducing Azlin Workspace, Azlin UI Toolkit, and Azlin OS. Although Azlin Workspace is basically a bunch of “Coming Soon” notices, and I’m not sure how Azlin relates to Azul, I still managed to get past the homepage and find the correct user documentation on GitHub. 当我打开 Azul 的主页时，映入眼帘的是一个相当宏大的页面，介绍了 Azlin Workspace、Azlin UI Toolkit 和 Azlin OS。虽然 Azlin Workspace 基本上是一堆“敬请期待”的通知，而且我不确定 Azlin 与 Azul 有什么关系，但我还是设法绕过主页，在 GitHub 上找到了正确的用户文档。

It looks like Azul just released version 0.2.0, and according to the docs, I can simply install its runtime library via Homebrew. Then, since Azul isn’t published on crates.io, I had to clone its Git repo and run it to generate the Rust API bindings. 看起来 Azul 刚刚发布了 0.2.0 版本，根据文档，我可以通过 Homebrew 轻松安装其运行时库。然后，由于 Azul 没有发布在 crates.io 上，我不得不克隆其 Git 仓库并运行它来生成 Rust API 绑定。

The first snag came right away: rust-analyzer didn’t recognize the Rust code that Azul generated. It compiled and ran fine, but all editor hints for the relevant types were gone. 第一个障碍立刻出现了：rust-analyzer 无法识别 Azul 生成的 Rust 代码。虽然编译和运行都很正常，但所有相关类型的编辑器提示都消失了。

Well, that’s not a huge deal; at least cargo doc is available. It’s like going back to programming in the pre-LSP era. 好吧，这也不是什么大问题；至少 cargo doc 还能用。这感觉就像回到了前 LSP 时代的编程生活。

After spending 10 minutes digging through the cargo docs and repeatedly invoking the compiler, I finally managed to stick a text box into its original example. But then, no matter what I did, I couldn’t get any text I typed into the box to actually show up. So I asked Codex to help me debug this issue, and it turned out that Azul apparently couldn’t read fonts installed on the system. That alone is almost enough to rule out using Azul for this purpose. Not wanting to waste any more of my time (and tokens), I decided to move on to the next framework. 在花了 10 分钟翻阅 cargo 文档并反复调用编译器后，我终于设法在它的原始示例中塞进了一个文本框。但随后，无论我怎么做，我在框中输入的任何文本都无法显示出来。于是我请 Codex 帮我调试这个问题，结果发现 Azul 似乎无法读取系统安装的字体。仅凭这一点就足以排除将 Azul 用于此目的的可能性。不想再浪费更多的时间（和 Token），我决定转向下一个框架。

Blinc

Blinc is a very new framework. It only released its first version in early 2026. Like many Rust GUI frameworks, Blinc uses wgpu as its rendering backend and adopts a reactive programming model. With rapid iteration, some examples in its official documentation are already outdated. Blinc 是一个非常新的框架，直到 2026 年初才发布了第一个版本。像许多 Rust GUI 框架一样，Blinc 使用 wgpu 作为渲染后端，并采用响应式编程模型。由于迭代迅速，其官方文档中的一些示例已经过时了。

The TextInput component feels unfinished: it doesn’t let you set a font, and its reactive behavior requires manually triggering in the on_change event. Meanwhile, TextArea allows you to specify a signal as the target to trigger when it updates. However, I don’t think either of these approaches really conforms to the reactive standard. True reactivity shouldn’t require you to manually handle events or signals; it should directly propagate changes in input controls to wherever the state is used. TextInput 组件感觉还没完成：它不允许设置字体，其响应式行为需要在 on_change 事件中手动触发。同时，TextArea 允许你指定一个信号作为更新时的触发目标。然而，我认为这两种方法都不符合响应式标准。真正的响应式不应该要求你手动处理事件或信号；它应该直接将输入控件的变化传播到使用该状态的任何地方。

TextInput’s default font doesn’t support CJK character display. IME works fine, but the composer position doesn’t align with the text box position. macOS’s accessibility features don’t work either; screen readers can’t read out the content in the window. TextInput 的默认字体不支持中日韩（CJK）字符显示。输入法（IME）工作正常，但输入框的位置与文本框位置不对齐。macOS 的辅助功能也无法使用；屏幕阅读器无法读出窗口中的内容。

Cacao

Cacao is a Rust binding for macOS AppKit. Honestly, I’d never tried this crate before. I expected it to be full of unspeakable unsafe things interacting with low-level Objective-C code. But after actually using it, I found its API surprisingly clean. Cacao 是 macOS AppKit 的 Rust 绑定。老实说，我以前从没试过这个 crate。我原以为它会充斥着与底层 Objective-C 代码交互的、难以言说的 unsafe 代码。但实际使用后，我发现它的 API 出奇地简洁。