Docs

Fission is a Rust application platform for building and shipping real apps across macOS, Windows, Linux, Web, Android, iOS, Terminal, Static site, and SSR targets.
That word platform is deliberate. Fission is not only a widget catalog. It gives you the application model, platform shells, command-line workflow, testing story, packaging commands, static site generation, capability APIs, and release tooling needed to carry an app from the first screen to a published product.
These docs are organized around the same lifecycle you will follow in a real project: set up, learn the app model, develop features, test and debug, build packages, and publish releases. You can still look up individual APIs in the reference, but the main path is written as a guided route rather than a pile of disconnected pages.

If you are new, start here

Start with Quickstart even if you already know Rust. It gets a Fission app on screen and explains what each command is doing. Then read Project structure so the files in a generated app make sense.
After that, learn the core loop in this order:
Step
Read
What you should understand afterward
1
Where app state lives, what runtime state means, and why widgets should build from inputs.
2
How widgets become layout, semantics, display lists, and host output.
3
How to compose screens that adapt to mobile, desktop, and web-sized viewports.
4
How pointer, keyboard, text input, theme, locale, and environment data reach widgets.
5
Where durable app state, local widget state, build handles, environment, and parent-provided context belong.
6
How to keep product state explicit while still doing host work, background work, and long-lived resources.
The docs assume you can run cargo, but they do not assume you are an expert Rust developer. When a concept such as Env, BuildCtxHandle, ViewHandle, reducer, selector, resource, job, or capability appears, the relevant guide should introduce what it is, why it exists, when to use it, and what to avoid.

Follow the lifecycle

Fission projects move through a practical development lifecycle.
Lifecycle stage
Where to go
What the pages teach
Setup
Learn
Understand the architecture before copying patterns into a larger app.
Build features
Build product screens, manage state intentionally, theme them, translate them, add charts, and request platform features through typed capabilities.
Develop
Run the app on real targets, keep logs attached, use the terminal UI, build content-backed static sites, and run SSR targets when pages need request-time behavior.
Test and debug
Test reducers first, then widgets, runtime effects, shell paths, screenshots, logs, and release captures.
Build and package
Produce installable or uploadable artifacts with readiness checks and artifact manifests.
Release and distribute
Prepare release content, validate metadata, upload through providers, manage tracks/testers, and keep audit receipts.
Look up exact details
Confirm field names, widget behavior, CLI flags, platform contracts, chart variants, and capability provider contracts.

The mental model to keep

A Fission app should stay understandable as it grows.
State holds product truth. Actions describe intent. Reducers update state. Selectors derive values from state. Widgets build the interface from the current state and environment. Resources, commands, jobs, services, and capabilities describe work outside pure rendering. Shells host the same app model on macOS, Windows, Linux, Web, Android, iOS, Terminal, Static site, or SSR targets. The fission command carries the project through setup, running, testing, packaging, and release.
If you are unsure where a piece of code belongs, ask what kind of thing it is:
If it is...
It usually belongs in...
Durable product data
A user intent such as save, select, open, close, submit, or retry
An action and reducer
A value derived from existing state
A selector or local calculation in component conversion
Visual structure for the current frame
A widget component conversion method
Temporary UI state owned by one widget identity
Typed context a parent gives only to descendants
Theme, locale, title, viewport, or other app-wide presentation context
Env synchronized from state or seeded by the shell
File I/O, networking, device access, notifications, camera, clipboard, or other host work
A capability, resource, command, job, service, or explicit effect
Platform packaging, SDK setup, release metadata, or provider upload
That separation is the reason the same product can run through multiple hosts without becoming several unrelated apps.

Use the reference when you need precision

The guide pages teach patterns step by step. The reference pages are for exact contracts: struct fields, enum choices, command flags, platform tables, widget behavior, chart variants, and capability provider details.
When you know the subsystem you need, go to the Reference overview. When you are still learning how a feature should be built, stay in the guides and cookbook first.

Lifecycle fit and verification

This page belongs to the setup, learn, build, test, and publish lifecycle. Use it to decide the next concrete action, then verify the action before moving to the next stage.
Stage question
Verification
What file or command changes?
The page should point to the exact fission command, fission.toml section, Rust component, or generated artifact involved.
What proves it worked?
Prefer a command output, generated file, screenshot, test assertion, package artifact, or deployed URL over a vague statement.
What can fail safely?
Permission prompts, missing tools, unsupported hosts, invalid config, and expired credentials should produce diagnosable errors that can be retried after the cause is fixed.
What should I read next?
Continue to the linked guide for step-by-step work or the reference page for exact fields and contracts.
Fission
A cross-platform, GPU-accelerated user interface framework for Rust. MIT licensed.
Copyright (c) 2026 Fission
Ready to use today. Widget APIs are expected to remain stable; some runtime and shell APIs may change before 1.0.0.
Fission 0.7.0