Compose-shaped UI in Rust, drawn by Compose.

What it is

compose-rust is four things put together.

• A Compose-shaped Rust API with a slot table and a recomposition runtime. A composable is a function, and state lives in remember. When state changes, only the scopes that read it run again. Nothing compares trees to find what changed. Planned for 1.0.0.
• A narrow C ABI boundary and a schema. Rust defines the widgets, properties and records once. The Kotlin types and the platform shims are generated from that definition, never written by hand. Works
• An AOT-compiled Compose renderer. It is compiled ahead of time to native code on every platform, to Kotlin/Wasm in the browser, and to an Android library on Android. Compose's own text layout, widgets and platform IME do the drawing and the typing. Works
• No webview, and no bundled JVM. On the desktop the goal is one executable that links only the system's own libraries. 0.0.1 does not reach it yet; see Platforms. Partial

Why it exists

It is aimed at applications that stay open all day, where weight is felt every hour. A webview brings a browser engine with it. A bundled Java runtime adds 80 to 120 MB, even after jlink.

A pure-Rust UI toolkit fails where text-heavy applications need it most: text itself. Korean, Japanese and Chinese input goes through the platform IME, and an IME that is 90% right makes an application unusable. Compose Multiplatform already has mature text, IME and widget behaviour. compose-rust borrows exactly that. Rust keeps the application code, and Compose interprets the UI tree that Rust sends it.

Status

0.0.x is the name reservation and renderer distribution stage. The API will change. This is what the 0.0.1 crate contains today:

Until 1.0.0 the crate is a foundation for a layer that builds the tree. It is not yet something you write screens with directly.

The planned shape

#[composable]
fn counter() {
    let count = remember(|| mutable_state_of(0));
    Column(Modifier::new().fill_max_width(), || {
        Text(format!("{}", count.get()));
        Button(|| count.set(count.get() + 1), || Text("+1"));
    });
}

fn main() {
    compose_rust::launch(counter);
}

Three things about it are settled. #[composable] inserts the groups, so you never write groups or keys by hand, and they close correctly through branches, loops, early return, ? and unwinding. Names follow Compose. The widget vocabulary is the one in the schema, so nothing is defined twice. Writing UI describes the rest of the planned API.

Platforms

The table lists the renderer each platform gets in 0.0.1. "Works end to end" means the platform has been used by hand. "Builds and starts" means CI builds it and a smoke test opens and draws a window, which proves rather less.

What it weighs

These numbers are for the notepad sample, built for release and stripped, with the Kotlin/Native renderer linked in. That is the path that becomes the default after 0.0.1, not what 0.0.1 ships. The result is one executable, with no runtime beside it and no virtual machine inside it.

For scale, the same kind of application on macOS was four files and 93.1 MB, with a 56 MB footprint, while the renderer still carried a Java runtime. In the browser, the renderer and Skia together are 6.95 MB gzipped.

Where to go next