Develop workflow

The daily Fission workflow is built around one command, one project manifest, and one shared app model.

You write product behavior in Rust: state, actions, reducers, selectors, widgets, resources, and capabilities. Then you use the fission command to add hosts, run targets, attach logs, check local setup, build packages, and publish releases. The command-line tool should make the platform work repeatable without hiding the app architecture from you.

The normal day-to-day loop

Most days follow this loop:

Open a project that has fission.toml at its root.

Run the fastest useful target while developing the shared feature.

Switch to the platform target whenever the question depends on a real host.

Keep logs attached while the app runs.

Add focused tests before the feature grows.

Run readiness checks before packaging or publishing.

A new project usually starts like this:

fission init my-app
cd my-app
fission run

An existing project can add more hosts without replacing its source files:

fission init .
fission add-target web android ios
fission devices
fission run --target web

fission init . is intentionally idempotent. On an existing project it should create or update missing Fission metadata without overwriting your app source. That matters when older examples or hand-written projects need a fission.toml before they can use newer CLI features.

Choose the fastest target for the question

A target is the output family you want to run or build. A shell is the host layer that boots the shared app model for that target.

Question you are answering	Good first target	Why
Does my reducer update state correctly?	Rust unit test	No host is needed. Test the function directly.
Does the screen composition make sense?	Desktop or web	Fast visual iteration with the normal widget tree.
Does the layout adapt to browser sizes?	Web	The browser host answers viewport, focus, clipboard, and page-integration questions.
Does touch, safe area, or mobile density feel right?	Android or iOS	Mobile hosts answer mobile input and presentation questions.
Does a command-line workflow need persistent interaction?	Terminal	The terminal shell proves keyboard, mouse, logs, and scrollback behavior.
Does documentation or marketing content render as crawlable pages?	Static site	The site target answers routing, generated HTML, metadata, search, and link-validation questions.
Does an ecommerce, account, dashboard, or portal page need request-time data?	Server-rendered site	The server target answers sessions, cache policy, server jobs, signed actions, workers, and islands.

Do not treat desktop as the only real loop. It is often the fastest place to start, but Web, Android, iOS, Terminal, Static site, and SSR targets are first-class delivery paths. Choose the host that can actually answer the current question.

Keep host details at the edge

Product modules should not need to know whether they are running in a native window, browser, phone, terminal, or static site build unless the feature itself depends on that host.

For example, an inbox screen should not contain Android packaging logic or browser script setup. It should contain state, reducers, selectors, and widgets. If the inbox needs notifications, deep links, clipboard, camera, or local authentication, it should request those through Fission capabilities. The shell-side provider handles the platform-specific API.

That boundary keeps app code reviewable. A teammate can read the inbox module and understand the product behavior without also learning every target's launch script.

Use fission.toml as the project root

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.toml is the authoritative manifest for the project. It should contain stable project facts and references to larger files:

Belongs in fission.toml	Usually belongs in a referenced file
App name, app id, package ids, enabled targets	Full release notes
Target declarations and generated host locations	Long store descriptions
Site route roots, output directory, static assets	Localized marketing text
Capability declarations and platform config references	Screenshot inventories and preview videos
Release ids, provider names, track names, metadata paths	Provider-specific review attachments

Keeping the root manifest readable makes it easier to review changes. The CLI can populate or edit parts of the manifest, but the files remain ordinary project files that can be committed and reviewed.

Run with attached output by default

fission run should feel like a production developer tool: it builds, launches, and attaches to useful output unless you ask it not to.

fission run --target android --device emulator-5554
fission run --target ios --device "iPhone 15"
fission run --target web

Use --detach when you want the app to keep running without the command staying attached. Use fission logs to reconnect where the target supports it.

fission run --target web --detach
fission logs --target web

Use the terminal UI when discovery matters

The command-line flags are still the stable automation surface, but not every task is easiest to learn as a command. fission ui opens a Fission-built terminal interface for project setup, run/build workflows, logs, settings, and discovery.

fission ui --project-dir .

Use the terminal UI when you want a guided workflow. Use direct commands in scripts and continuous integration.

Check setup before blaming the app

A lot of platform failures are environment failures: missing Android NDK, missing simulator runtime, unavailable browser driver, stale package metadata, missing signing config, or an unauthenticated provider CLI.

Run doctor and readiness checks when the error smells like setup:

fission doctor
fission doctor android ios web
fission readiness package --target android --format aab
fission readiness distribute --provider github-releases --artifact target/fission/release/windows/msix/artifact-manifest.json

A good check tells you what is missing and what to do next. It should not leave you guessing which SDK, target, credential, or generated file caused the problem.