--- title: A 2026 Survey of Rust GUI Libraries | daily.dev description: A hands-on 2026 survey tests nearly every Rust GUI library listed on Are We GUI Yet? by building the same QR code generator app in each, evaluating IME... canonical: https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: A 2026 Survey of Rust GUI Libraries | daily.dev og:description: A hands-on 2026 survey tests nearly every Rust GUI library listed on Are We GUI Yet? by building the same QR code generator app in each, evaluating IME... og:url: https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7 og:image: https://api.daily.dev/og/posts/E93CfC0B7.png og:image:alt: A 2026 Survey of Rust GUI Libraries og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # A 2026 Survey of Rust GUI Libraries **[Lobsters](https://daily.dev/sources/lobsters)** · 101 min read · 1 upvotes · 0 comments ## Summary A hands-on 2026 survey tests nearly every Rust GUI library listed on Are We GUI Yet? by building the same QR code generator app in each, evaluating IME support, screen reader accessibility, ecosystem integration, and developer experience. Findings include Azul failing to render system fonts, Blinc's incomplete reactive text input, Cacao's surprisingly clean AppKit bindings, Cushy's concise and ecosystem-friendly API, CXX-Qt's painful Nix/SemVer-related build issues, GPUI's missing built-in text input and a crash bug in its IME handling, Floem's broken IME and accessibility, and egui's shift to wgpu as its default rendering backend in version 0.34. The author also notes Dioxus's pivot toward the Blitz rendering engine and Freya breaking away from Dioxus to build its own GUI model. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Which Rust GUI framework has the best combination of IME support and screen reader accessibility on macOS? Slint and egui both provide solid IME and screen reader support alongside clean, low-friction APIs, making them the top picks among dozens of Rust GUI libraries tested. Slint acts as a retained-mode framework using its own DSL similar to QML, while egui is the leading immediate-mode option and the first wgpu-based framework to offer good accessibility support. _Developers picking a Rust GUI stack for accessible apps can track framework comparisons like this on daily.dev._ ### What rendering backend does eframe use by default in egui version 0.34? Eframe, egui's desktop integration, switched its default rendering backend from glow to egui-wgpu starting with version 0.34, whereas the prior year it still defaulted to glow. This reflects wgpu becoming the de facto standard rendering backend across the Rust graphics ecosystem, with many other GUI frameworks also adopting it. _Track backend changes like this before upgrading an egui-based app on daily.dev._ ### Does GPUI ship with a built-in text input component? No, as of 2026 GPUI still does not include a built-in text input widget, forcing developers to copy a roughly 700-800 line example from GPUI's repository and adapt it. Additionally, GPUI's crates.io release doesn't match its GitHub examples due to versioning tied to Zed's own tags, and a known bug causes an out-of-bounds panic when retyping after deleting IME composer text. _Anyone evaluating GPUI for a desktop app can weigh these gaps against alternatives on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 31 comments across lobsters (as of 2026-09-13). **TL;DR:** Commenters largely agree the Rust GUI ecosystem is still immature and fragmented, sharing their own frustrating experiences with docs, missing features, and half-finished libraries, while debating whether GPU-based rendering is even necessary. **Sentiment:** 15% positive · 45% mixed · 40% skeptical **The case for** - Some found gpui-component (built on GPUI) to be a promising, well-documented, quickly-productive option beyond what the article tested. - GPU-accelerated rendering has real technical justifications like fast text rendering, caching/compositing efficiency, and cheap effects. **The pushback** - Several noted major Rust GUI frameworks (Iced, libcosmic) have unfinished documentation that stops after just a few pages. - GPU-based UI frameworks can be very slow or unusable inside VMs. - A commenter argues GPU rendering claims are often conflated with basic hardware-accelerated compositing and that CPU rendering can outperform naive GPU approaches. - Tree views and virtualized list boxes with full feature sets (drag-and-drop, multi-selection, async data, animations) are missing from most listed libraries and are seen as a critical litmus test the survey didn't cover. - The trend toward DSL/markup-based UI definitions instead of plain code is disliked for reducing portability and tooling support. - The QR code demo app used in the survey is seen as too simple to reveal real issues like massive table views, custom text layout, or accessibility abstractions. **By community** - lobsters (mixed): People appreciated the survey but used it as a springboard to vent about the broader immaturity of Rust (and desktop) GUI tooling, while disagreeing over how important GPU rendering really is. **Hottest debate:** Whether GPU-based rendering is a genuine necessity for modern GUIs or an overused buzzword conflating hardware acceleration with true GPU-driven UI architectures. **Open questions** - Is there a Rust GUI library that offers a fully-featured tree view or virtualized list comparable to mature toolkits like Qt? - Will any Rust GUI framework support large-scale accessibility abstractions, translation, and remote/local UI code sharing seen in older frameworks like OpenStep or NeWS? **Highlights** > Frustrating times for desktop imho. Recently learned rust and thought learning libcosmic and iced would be a good project. Both have a “book” so I got started reading. Both project’s books end on the third substantial page. Iced was a bit worse in that it dedicates its first page to admonishing the reader to not expect *anything* from the developer. Noted. A few months previously I’d tried to learn PyGTK (and gnome stuff to some degree.). Their book also ended on approximately the third page after “hello world v2”. This is not the timeline I imagined at the dawn of the web. Desktop GUIs are near dead, and the UI/X field as well. For example, when I learned wxPython, QT, and Java Swing at the turn of the century, there were complete books in print to learn from. I’d like to buy one. (Delphi too, though was paid env.) Also there’s been a weird and long movement towards DSL/markup files instead of code, which I don’t like. I understand code is harder at first, but it scales and compounds very well. Just like static typing. I don’t want to learn your custom language unusable anywhere else without refactoring or tool support, or requires a specific IDE. I guess going back to something mature (read elderly) is the right call, but had wanted to move forward. There should be a better than 1999 all-around choice by now. > — [white-star on lobsters · 11 points, 4 comments](https://lobste.rs/s/83yugk/2026_survey_rust_gui_libraries#c_krer4i) > My personal checklist (all must be yes): - Can I use it without dynamically linking system C code that might not be installed? (this invalidates most webview wrapper libraries, the ones that don't let me configure them to use a vendored fallback) - Does it support IMEs and screen readers and loading system fonts? - Does at least latin text render correctly with full hinting, or is it blurry and hard to read? (subpixel AA not needed, just hinting) - Can I bolt on my own widgets that do their own input handling and rendering, or am I stuck uploading entire images or hacking at the viewport? - Does it support all 4 major desktop shell ecosystems (windows/mac os/x11/wayland)? - Does it retain state? (pure immediate mode libraries that shunt all state management onto the application are out of the question; egui barely has enough state retention to be usable!) - Am I able to use it without structuring all of the UI parts of my application reactively? (I need check-and-update patterns to be available, even if they're unidiomatic) - Is its license compatible with whatever other yet-unknown dependencies I'm likely to use? (this rules out slint) Most of these requirements (excluding the first one about webviews, that's a personal nitpick) are incredibly basic and fundamental but get overlooked for years in most libraries. Unfortunately, they rule out almost the entire rust GUI tooling ecosystem. > — [wareya on lobsters · 1 points, 1 comments](https://lobste.rs/s/83yugk/2026_survey_rust_gui_libraries#c_f2xwji) > I find the best demonstration of a UI library's capabilities is a tree view. If a UI library doesn't provide a fully featured tree view then you should go elsewhere so you don't need to implement it yourself. I have implemented the following feature set more than once, and I'll tell you that it's very difficult to have all of them at once with zero bugs/glitches and a good API. A good complete tree view: - Can be given a model that can have unlimited items in it, and it displays only the ones you can see on the screen without performance woes. - The model is unoppinionated, and adaptable to any data source you have. - Let's you define a custom row delegate for your custom model. - Supports drag and drop, with insertion lines that preview where an item will be inserted into the tree. - When dragging an item over the tree view, it automatically scrolls when dragging near the top/bottom. - Supports multi selection, range selection, maintaining the selection when a branch of the tree is collapsed and the selected rows are no longer visible. Selections stay sane in the face of model changes. - Supports keyboard navigation and selection shortcuts. - Supports having interactive items in the delegate (eg. a button) while still allowing you to select the row by clicking on it. - A model implementation ideally can notify about specific changes to the model like "row added", "row data changed" etc. - Kind-of a bonus but I would say it's necessary for a good implementation: When expanding/collapsing/adding/removing/moving rows, the tree view can do animated transitions. Can be a nightmare to get this right. All of those things have implications for the underlying implementation of the UI library, and if they actually can't be done, then I would say the library is not sufficient for use in a complex professional application. Unfortunately a good tree view is simply not available in many of the listed UI libraries, so that's an immediate "maybe later" from me. I find the demo in the article mostly insufficient for making any kind of judgement about the suitability of a library for a large project, though it's good to know when a library can't even do something very simple I guess. > — [yokljo on lobsters · 1 points, 2 comments](https://lobste.rs/s/83yugk/2026_survey_rust_gui_libraries#c_pvnhd2) > My litmus test for GUI libraries requires two things not tested at all in the example application: First, can you create a table view with a hundred million entries and smoothly scroll it without memory usage ballooning? With the contents changing asynchronously in the background? Second, can I create a text view with a custom hyphenation algorithm, adjust the default kerning, and provide a non-rectangular clipping region that the text layout engine uses to fit the text? Can I bring my own text layout engine and hook it into your text view without rewriting the text view entirely? If I can do both of those, I can build most rich UIs, so you’ve met the table-stakes requirements. OpenStep, from 30 years ago, could do both of them in a few dozen lines of code. How much do you beat that by? Beyond that, a few other things I want in a UI framework that *isn’t* 30 years old and designed for 25 MHz m68k chips: - What tools do you provide for abstraction over UIs that can be used to support translation and accessibility? Can I define core UI components that are input-device agnostic with localisation for touchscreen, mouse-driven, and keyboard-only devices? Copeland / Taligent did this better than anything I’ve seen in the last 20 years. - Can I use the same core code for a local app and a remote web UI? Do you provide a clear separation between the UI and model layers that supports latency hiding so that I can compile the UI bit to WebAssembly and put an RPC layer between the two? i.e. Have you yet caught up with NeWS (1986). - If you are not the platform’s native UI toolkit, do you provide abstractions that make it possible to use native widgets *and* hooks to change the behaviour based on native human-interface guidelines? Java AWT (1995) attempted this but I’ve never seen it done *well*. - Do you provide a GUI builder that creates serialised object graphs, or something more primitive? NeXT’s IB let you create an entire graph of objects for an empty document in a NIB file so it was one line of code to instantiate a new document, how much better than this are you (how much less do you need to be explicit in the UI editor)? - Do you support run-time reflection over the UI and tools for modifying it as the program runs so that I can rapidly evolve the UI? With EtoileUI, we exposed the UI tree as the same generic data model that the UI layer was intended to surface so you could have an inspector for your UI and modify it dynamically then save the resulting version. - How easy is it to provide multi-level, persistent, branching undo? Ideally, it shouldn’t require any code beyond defining the data model (for Étoilé, we built this in at the CoreObject layer). - If you have multiple views of the same data model (e.g. master-detail views) how much code do you need to avoid them getting out of sync? With Apple’s Cocoa Bindings, this was zero but they suffered from the ‘too much magic’ problem: they were amazing when they worked and impossible to debug when they didn’t. None of these issue show up in a QR-code generator. > — [david\_chisnall on lobsters · 2 points, 1 comments](https://lobste.rs/s/83yugk/2026_survey_rust_gui_libraries#c_nmezii) > There are a few reasons to want to run GUIs on a GPU. The first one is text rendering. Each glyph is a sequence of Bézier curves that need to be rendered (possibly with antialiasing). A paragraph of text has more distinct vector-graphics elements than the whole of the rest of a typical window. Scrolling text on a 300 MHz PowerMac was noticeably slow because this was done all on the CPU. The simplest fix (which OS X did around 10.2) was to render each glyph (for each size) once and then use the GPU to composite them. This was *much* faster (even on a 1 GHz machine it was noticeable in very text-heavy windows). This has some knock-on effects because it’s generally fast to send things *to* a GPU, but slow to bring the, back, so you want to either do all compositing on the GPU or add text later. The second is largely about caching, which trades memory for compute. Older GUIs would send expose events whenever any part of a window was exposed and make the owning application redraw that part (which, often, required redrawing a bit more than just the bit because it’s hard to identify exactly the set of things that draw into a specific rectangle, so you conservatively over approximate). This was necessary because the frame buffer was a huge chunk of total memory. Modern machines have a lot of memory (or graphic memory, if they’re separate) relative to the size of a frame buffer. My old 2013 laptop had 2 GiB of graphics memory. A 4K frame buffer is a bit over 23 MiB, so the frame buffer is now tiny in comparison to available memory. A compositing display server (or window manager for X11) will cache windows and not send redraw notifications when they become visible but a toolkit can cache individual views. This means less time on the CPU (or GPU) redrawing, which lets the CPU stay in lower-power states and improves battery life. Compositing on the GPU is very power efficient, so having a small tree of textures for views and just compositing them to get the window state is fast and doesn’t consume much power. Finally, there are effects. Things like making the active button pulse to give the user a strong visual cue that it’s the active one, or animations to draw the eye to where something is moving, rather than simply having it disappear and reappear, are trivial on a GPU but much more expensive on a CPU. > — [david\_chisnall on lobsters · 1 points, 3 comments](https://lobste.rs/s/83yugk/2026_survey_rust_gui_libraries#c_zhm97i) **Source threads** - [lobsters](https://lobste.rs/s/83yugk/2026_survey_rust_gui_libraries) · 40 points · 31 comments ## Similar posts on daily.dev - [Thanks for All the Frames: Rust GUI Observations](https://daily.dev/posts/thanks-for-all-the-frames-rust-gui-observations-4x2gjqln2) · Lobsters · 16 upvotes · 0 comments - [longbridge/gpui-component: Rust GUI components for building fantastic cross-platform desktop application by using GPUI.](https://daily.dev/posts/longbridge-gpui-component-rust-gui-components-for-building-fantastic-cross-platform-desktop-applica-kbdiwfvz3) · Hacker News · 17 upvotes · 1 comments - [Iced 0.14 Released For Popular Rust Cross-Platform GUI Library](https://daily.dev/posts/iced-0-14-released-for-popular-rust-cross-platform-gui-library-mp1ebhdos) · Phoronix · 2 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust), [#accessibility](https://daily.dev/tags/accessibility) [View this post on daily.dev](https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"A 2026 Survey of Rust GUI Libraries","url":"https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7"},"datePublished":"2026-08-23T04:47:18.941Z","dateModified":"2026-09-13T21:47:50.798Z","description":"A hands-on 2026 survey tests nearly every Rust GUI library listed on Are We GUI Yet? by building the same QR code generator app in each, evaluating IME...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0a96998019a9d5e5eb8b86abc28d0226?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0a96998019a9d5e5eb8b86abc28d0226?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust,accessibility","timeRequired":"PT101M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"A 2026 Survey of Rust GUI Libraries"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7#faq","mainEntity":[{"@type":"Question","name":"Which Rust GUI framework has the best combination of IME support and screen reader accessibility on macOS?","acceptedAnswer":{"@type":"Answer","text":"Slint and egui both provide solid IME and screen reader support alongside clean, low-friction APIs, making them the top picks among dozens of Rust GUI libraries tested. Slint acts as a retained-mode framework using its own DSL similar to QML, while egui is the leading immediate-mode option and the first wgpu-based framework to offer good accessibility support. Developers picking a Rust GUI stack for accessible apps can track framework comparisons like this on daily.dev."}},{"@type":"Question","name":"What rendering backend does eframe use by default in egui version 0.34?","acceptedAnswer":{"@type":"Answer","text":"Eframe, egui's desktop integration, switched its default rendering backend from glow to egui-wgpu starting with version 0.34, whereas the prior year it still defaulted to glow. This reflects wgpu becoming the de facto standard rendering backend across the Rust graphics ecosystem, with many other GUI frameworks also adopting it. Track backend changes like this before upgrading an egui-based app on daily.dev."}},{"@type":"Question","name":"Does GPUI ship with a built-in text input component?","acceptedAnswer":{"@type":"Answer","text":"No, as of 2026 GPUI still does not include a built-in text input widget, forcing developers to copy a roughly 700-800 line example from GPUI's repository and adapt it. Additionally, GPUI's crates.io release doesn't match its GitHub examples due to versioning tied to Zed's own tags, and a known bug causes an out-of-bounds panic when retyping after deleting IME composer text. Anyone evaluating GPUI for a desktop app can weigh these gaps against alternatives on daily.dev."}}]} ```