Building a graphical interface for an application can feel like one of the biggest hurdles when you’re working with a systems language like Rust. You have this incredibly fast, safe, and reliable backend, but then you need a window, buttons, and text fields for people to interact with it. For a long time, this area was Rust’s frontier, but today, it’s a flourishing ecosystem with serious options. I want to walk you through the current landscape, not as a detached observer, but as someone who has tinkered, gotten frustrated, and ultimately been impressed by what’s available.

The choice isn’t about finding the single “best” framework. It’s about matching a tool’s philosophy to your project’s needs. Do you want something that feels like traditional desktop programming? Are you coming from a web background and want those familiar technologies? Or do you need something ultra-simple for a tool only you will use? Rust has a path for each of these.

Let’s start with a framework that embodies a very classic, pragmatic approach to GUI development. Druid operates on a clear principle: your user interface is a direct reflection of your application’s data. When the data changes, the parts of the UI that depend on that data update. This sounds simple, but it’s a powerful way to structure an application and avoid messy state synchronization bugs.

Druid feels familiar if you’ve used toolkits like Qt or SwiftUI. You build a tree of widgets, and they react to changes in your data model. Here’s a concrete example. Imagine a simple counter application. Your data is just a number. Your UI is a label showing that number and a button to increase it.

use druid::widget::{Button, Flex, Label};
use druid::{AppLauncher, LocalizedString, PlatformError, Widget, WidgetExt, WindowDesc};

fn build_ui() -> impl Widget<u32> {
    // The label's text is a function of the data (a u32).
    let label = Label::new(|data: &u32, _env: &_| format!("Count: {}", data));
    // The button's click handler modifies that same data.
    let button = Button::new("Increment")
        .on_click(|_ctx, data: &mut u32, _env| *data += 1);

    // Arrange them vertically in a column.
    Flex::column().with_child(label).with_child(button)
}

fn main() -> Result<(), PlatformError> {
    let main_window = WindowDesc::new(build_ui())
        .title("Counter");
    // Launch the app with the initial data: 0.
    AppLauncher::with_window(main_window)
        .launch(0)
}

The elegance is in the separation. The build_ui function describes how the data maps to widgets. The button’s closure describes how an action changes the data. Druid handles everything in between. This model scales well to complex, data-heavy applications like editors or data analysis tools. The widgets are native-looking on each platform, and the community is actively building out a comprehensive set of components.

If the Elm architecture or React’s functional UI patterns resonate with you, then Iced might be your ideal match. It structures every application around a clear, unbroken loop: your Model (state), your View (a function that returns UI elements), and your Update function (which changes the state in response to messages). This enforced discipline eliminates whole classes of UI state bugs.

Working with Iced feels declarative. You don’t manually tell a button to update its label; you describe what the entire UI should look like for any given state, and Iced makes it so. Let’s recreate our counter.

use iced::{button, Application, Button, Column, Command, Element, Settings, Text};

struct Counter {
    value: i32,
    increment_button: button::State,
}

#[derive(Debug, Clone, Copy)]
enum Message {
    Increment,
}

impl Application for Counter {
    type Message = Message;

    fn new(_flags: ()) -> (Self, Command<Message>) {
        (Self {
            value: 0,
            increment_button: button::State::new(),
        }, Command::none())
    }

    fn update(&mut self, message: Message) -> Command<Message> {
        match message {
            Message::Increment => self.value += 1,
        }
        Command::none()
    }

    fn view(&mut self) -> Element<Message> {
        Column::new()
            .push(Text::new(format!("Count: {}", self.value)))
            .push(
                Button::new(&mut self.increment_button, Text::new("Increment"))
                    .on_press(Message::Increment)
            )
            .into()
    }
}

fn main() -> iced::Result {
    Counter::run(Settings::default())
}

The Message enum is the core of your application’s logic. Every user interaction sends a message. The update function is a pure state transformer. The view function recreates the UI from the state. Iced’s async support is also first-class, making it excellent for applications that need to fetch data or perform long-running operations without freezing the interface. Its custom widget system is powerful, allowing you to create unique, pixel-perfect components when the built-in ones aren’t enough.

Now, what if you don’t want to describe your UI in Rust code at all? What if you want a true separation between the visual design and the application logic? This is where Slint shines. It introduces a custom, declarative markup language (called .slint) for defining interfaces. This isn’t just a template language; it’s a compiled, type-checked part of your project.

The benefit here is two-fold. First, the separation is clean. Designers or front-end developers can potentially work on the .slint files. Second, Slint provides a visual designer tool, a WYSIWYG editor for your UI. This is a unique advantage in the Rust GUI world for rapid prototyping. The runtime is also notably small, making Slint a compelling choice for embedded systems with displays.

slint::slint! {
    // This is the Slint markup, embedded directly in Rust.
    import { Button, HorizontalBox, VerticalBox, Text } from "std-widgets.slint";

    export component App inherits Window {
        in property <int> counter: 0;
        VerticalBox {
            Text { text: "Counter: " + counter; }
            HorizontalBox {
                Button { text: "Decrement"; clicked => { counter -= 1; } }
                Button { text: "Increment"; clicked => { counter += 1; } }
            }
        }
    }
}

fn main() {
    let ui = App::new().unwrap();
    ui.run().unwrap();
}

The logic is minimal. The UI definition contains its own interactive logic (the clicked => { ... } handlers). More complex logic can be exposed as Rust callbacks. Slint strongly emphasizes accessibility and internationalization from the ground up, which is a significant advantage for commercial desktop software.

The frameworks we’ve discussed so far are “retained mode” toolkits. They maintain a persistent model of the widget tree. Egui takes the opposite approach: “immediate mode.” This means your code describes the UI fresh every single frame. If a button should be on the screen, you call ui.button(...) every time you draw. The library handles the input state and tells you if it was clicked this frame.

The immediate mental load is lower. You don’t manage widget state objects; you just describe what you want, right now. It’s incredibly straightforward for tools, debug overlays, and game UIs. The trade-off is that rendering everything every frame uses more CPU than a retained UI that only updates changed parts. However, for many applications, this is a perfectly acceptable trade for developer simplicity.

use eframe::egui;

struct MyApp {
    name: String,
    age: u32,
}

impl eframe::App for MyApp {
    fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
        egui::CentralPanel::default().show(ctx, |ui| {
            ui.heading("My Egui Application");
            ui.horizontal(|ui| {
                ui.label("Your name: ");
                ui.text_edit_singleline(&mut self.name);
            });
            ui.add(egui::Slider::new(&mut self.age, 0..=120).text("age"));
            if ui.button("Increment").clicked() {
                self.age += 1;
            }
            ui.label(format!("Hello '{}', age {}", self.name, self.age));
        });
    }
}

fn main() -> Result<(), eframe::Error> {
    let options = eframe::NativeOptions::default();
    eframe::run_native(
        "My App",
        options,
        Box::new(|_cc| Box::new(MyApp { name: "".to_owned(), age: 30 })),
    )
}

See how the ui.button("Increment") call both creates the button and returns a response telling us if it was clicked? The mutable data (self.age) is modified directly in the click handler. The UI is just a sequence of instructions. Egui is pure Rust, integrates beautifully with game engines like macroquad or bevy, and is my go-to for internal tools where quick iteration is more important than native platform fidelity.

Perhaps you and your team are already experts in HTML, CSS, and JavaScript. You have a beautiful web app, but you need it to run as a trusted desktop application with access to the filesystem or other OS APIs. Rebuilding the entire frontend in a native Rust GUI framework might be a daunting task. This is the problem Tauri is designed to solve.

Tauri creates a tiny, secure Rust backend process and renders your frontend in a minimally sized, system-provided webview (not a full browser like Electron). Your UI is built with any web technology you like: React, Vue, Svelte, or plain HTML/JS. The frontend and backend communicate through a structured message-passing system.

// This is the Rust backend (src-tauri/src/main.rs)
use tauri::Manager;

// This function can be called from JavaScript.
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! You've been greeted from Rust!", name)
}

fn main() {
    tauri::Builder::default()
        // Expose the `greet` function to the frontend.
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

In your frontend JavaScript, you would call this function:

// In your index.html or JS framework component
const { invoke } = window.__TAURI__.tauri;
invoke('greet', { name: 'World' }).then((response) => console.log(response));

The result is a desktop application with a negligible footprint, the security model of a systems language for the core logic, and the limitless UI potential of the web. It’s a fantastic bridge for web teams entering the Rust ecosystem.

Sometimes, you need your application to feel like it was born on the desktop. You want native file dialogs, menu bars that match the OS conventions, and perfect integration with desktop environments like GNOME. For this, you need to bind to a mature, native toolkit. On Linux and many cross-platform applications, that toolkit is GTK.

GTK-RS provides comprehensive, safe Rust bindings to the GTK+ library. This is not a Rust-native framework; it’s a bridge to a battle-tested C library. The API will feel familiar to GTK developers, just with Rust’s ownership and type systems applied.

use gtk::prelude::*;
use gtk::{Application, ApplicationWindow, Button, Label, Box, Orientation};

fn main() {
    let app = Application::new(Some("com.example.gtk-app"), Default::default());
    app.connect_activate(|app| {
        let window = ApplicationWindow::new(app);
        window.set_title("GTK-RS Example");
        window.set_default_size(350, 70);

        let vbox = Box::new(Orientation::Vertical, 5);
        let label = Label::new(Some("Press the button"));
        let button = Button::with_label("Click me");

        button.connect_clicked(|_| {
            eprintln!("Button was clicked!");
        });

        vbox.append(&label);
        vbox.append(&button);
        window.set_child(Some(&vbox));
        window.show();
    });
    app.run();
}

You are essentially writing a GTK application in Rust. This is the right choice if you are porting an existing GTK app, need deep Linux desktop integration, or require the absolute most mature and complete widget set available. The downside is that you inherit GTK’s complexity and licensing, and the Rust bindings, while excellent, can sometimes feel like you’re fighting the underlying C semantics.

If your priority is a tiny, fast, self-contained executable, you should look at FLTK-RS. FLTK (Fast Light Toolkit) is a C++ GUI library known for its minuscule footprint and decent speed. The Rust bindings are remarkably straightforward and produce binaries that are often just a few megabytes in size.

The programming model is classic, object-oriented, and callback-based. It’s not the most visually modern toolkit, but it’s reliable, cross-platform, and incredibly lightweight. I’ve used it for small utilities where I didn’t want to impose a 50MB runtime on the user.

use fltk::{app, button::Button, frame::Frame, group::Flex, prelude::*, window::Window};

fn main() {
    let app = app::App::default();
    let mut wind = Window::default().with_size(160, 200).with_label("Counter");
    let mut flex = Flex::default().with_size(130, 180).center_of_parent().column();
    let mut frame = Frame::default().with_label("0");
    let mut but = Button::default().with_label("Increment");
    flex.end();
    wind.end();
    wind.show();

    but.set_callback(move |_| {
        let label = frame.label();
        let value = label.parse::<i32>().unwrap_or(0) + 1;
        frame.set_label(&value.to_string());
    });

    app.run().unwrap();
}

The code is imperative. You create widgets, arrange them, and set callbacks. It’s simple to understand and debug. FLTK won’t give you the most native look on every platform—it has its own drawn style—but for tools where functionality trumps pixel-perfect platform integration, it’s a superb and often overlooked option.

Finally, let’s consider a framework that thinks about rendering differently. Azul is a reactive, retained-mode framework like Druid or Iced, but it uses Mozilla’s WebRender as its rendering backend. WebRender is the GPU-powered 2D rendering engine from Firefox, capable of incredible performance and smooth animations.

Azul’s API involves implementing a Layout trait that returns a Dom (a tree of UI elements). It uses a diffing algorithm, similar to React’s virtual DOM, to update only what has changed. This architecture, combined with WebRender, makes it exceptionally good for applications that require complex, animated data visualizations or highly custom, stylized interfaces.

use azul::prelude::*;
use azul::widgets::{Label, Button};

struct DataModel { counter: usize }

impl Layout for DataModel {
    fn layout(&self, _info: LayoutInfo<Self>) -> Dom<Self> {
        Label::new(format!("Counter: {}", self.counter))
            .dom()
            .with_child(
                Button::new("Increment").dom()
                    .with_callback(On::MouseUp, Callback(update_counter))
            )
    }
}

fn update_counter(app_state: &mut AppState<DataModel>, _event: WindowEvent<DataModel>) -> UpdateScreen {
    app_state.data.modify(|state| state.counter += 1);
    UpdateScreen::Redraw
}

fn main() {
    let app = App::new(DataModel { counter: 0 }, AppConfig::default());
    app.run(Window::new(WindowCreateOptions::default(), css::native()).unwrap()).unwrap();
}

Azul also allows styling with CSS, which is a unique feature among the native Rust frameworks. This combination of a reactive data model, CSS styling, and a high-performance renderer positions Azul for building modern, visually demanding desktop applications. The learning curve can be steeper, and the ecosystem is smaller, but the technological foundation is very strong.

So, where does this leave you? The landscape is rich. If you value a traditional, data-oriented architecture and native widgets, start with Druid. If the Elm/React model speaks to you, Iced is your framework. For a design-first workflow with a custom language, explore Slint. When you need a UI for a game or tool as fast as possible, Egui is irresistible. To leverage web tech with a Rust core, Tauri is the clear path. For perfect GNOME/GTK integration, use GTK-RS. For the smallest possible standalone binary, choose FLTK-RS. And for high-performance, CSS-styled applications with complex visuals, take a close look at Azul.

The best part is that you can’t make a catastrophically wrong choice. Each of these frameworks lets you write safe, fast Rust code. My advice is to pick the one whose mental model aligns with how you think about UI, and start building. The Rust GUI story is no longer about what’s missing; it’s about which of these capable tools is the right fit for your next project.