Skip to main content
Production-ready Rust user interface

Build desktop, web, Android, and iOS apps in Rust.

Fission is a cross-platform user interface framework with one shared runtime, explicit state, explicit side effects, and a GPU-backed rendering pipeline.

You write app state as plain Rust data, update it with reducers, and let Fission keep layout, input, time, rendering, and platform boundaries consistent across every target.

Run a real app

$cargo run -p counter

Create your own project

$fission init my-app
Rust 1.77+·MIT licensed·v0.1.0 alpha·Renders on Vello + wgpu
Shared across every target

State, reducers, layout rules, semantics, rendering stages, and testable runtime behavior.

  • State and reducers
  • Layout rules
  • Semantics tree
  • Input routing
  • Rendering stages
  • Testable runtime behavior
Owned by each shell

Windows, browser surfaces, package shape, lifecycle hooks, and host-specific integration.

  • Windows and surfaces
  • Browser canvas
  • Package shape
  • Lifecycle hooks
  • OS integration
  • Capability brokering
Pipeline
BuildLowerLayoutPaintRender
Same pipeline on every host.

Beautiful charts

Dashboards, analytics, finance, maps, networks, and 3D-ready visuals.

Fission Charts is the native charting layer for Fission apps, with more than 400 renderer-backed variants covering line, bar, area, pie, scatter, heatmap, financial, relationship, map, component, dynamic, and 3D chart work — without leaving the Rust UI model.

LineBarAreaPieScatterHeatmapFinancialRelationshipMapComponentDynamic3D

Why the model stays stable

The important boundaries stay visible.

Fission is strict about where state changes happen, where host work starts, and how rendering is produced.

reducer.rs
fn reduce(state: &mut AppState, action: Action) {
  match action {
    Action::Inc => state.count += 1,
    Action::Reset => state.count = 0,
  }
}
01State

Plain Rust data stays in charge.

Product truth is not hidden inside widgets or host callbacks.

02Reducers

Every durable change has a named cause.

Typed actions and reducers keep behavior reviewable and testable.

03Host work

Outside work has an explicit path.

Files, timers, authentication, and services do not leak through rendering.

04Render

Layout and paint stay inspectable.

Tests and diagnostics can inspect structure, semantics, and paint order directly.

Targets

Desktop, web, Android, and iOS stay in the same orbit.

Start on the host that answers your next product question fastest, then keep the shared model intact.

Desktop

Supported· macOS · Linux · Windows

Fast local loop for reducers, overlays, layout, and diagnostics.

$cargo run -p counterDesktop path

Web

Smoke path· WASM

Browser host path and generated launcher folder around the same app model.

$./examples/web-smoke/platforms/web/run-browser.shWeb path

Android

Smoke path· Emulator

Checked-in emulator path and generated Android host folder.

$./examples/mobile-smoke/platforms/android/run-emulator.shAndroid path

iOS

Smoke path· Simulator

Checked-in simulator path and generated iOS host folder.

$./examples/mobile-smoke/platforms/ios/run-sim.shiOS path

Examples

Small loop, real app shell, large custom tool surface.

Start where your evaluation needs the most signal.

42DecrementIncrementStarter

Counter

cargo run -p counter

The smallest complete Fission app loop: plain state, two reducers, a widget tree, and buttons bound with the public prelude macros.

  • typed actions and reducers
  • single-file starter app
InboxSentDraftsArchive09:2408:11Yest.MonProduct shell

Inbox

cargo run -p inbox

A product-like mail app that exercises portals, theme switching, locale switching, routing, and host capabilities in one shell.

  • translation bundles and locale sync
  • OPEN_URL host capability flow
main.rs · src/lib.rs · Cargo.toml12345678910fn reducer(state, action) { match action { Action::Inc => count += 1 Action::Reset => count = 0 }}#[test]fn test_inc() {$ cargo testrunning 12 tests · all passedCustom surface

Fission Editor

cargo run -p fission-editor -- .

The deepest example in the repo: custom editing surface, jobs, timers, portals, terminal panel, and extensive live tests.

  • custom render node path
  • resource-driven jobs and timers
Next

Run an app, inspect a host, then go deeper where you need detail.

The shared runtime is sitting right there. The next product question is one cargo command away.