▾

Setup

Learn

Build

Test

Publish

Home

›

Shells, targets, and tooling

Targets

A target in Fission is a host for shared app code.

The target does not own your reducers, selectors, widgets, or product state model. It owns the files, packaging steps, launch path, rendering mode, and host checks needed to run that shared app in one delivery environment.

That is why target output matters. It is the host wrapper around your app, not a second copy of your app.

Public target set

Use these names in user-facing documentation:

Target	Identifier or entry point	Shell family
macOS	macos	Desktop
Windows	windows	Desktop
Linux	linux	Desktop
Web	web	Web
Android	android	Mobile
iOS	ios	Mobile
Terminal	TerminalApp / fission ui	Terminal
Static site	site	Site
SSR	server	Server

Use the lowercase identifiers when referring to manifest values, generated target folders, or command arguments for scaffolded and packaged hosts. The server identifier is the SSR target.

A fresh fission init project starts with the desktop family scaffolded. You add scaffolded hosts with fission add-target ... when the product or host you care about requires them. Terminal uses the terminal shell and package workflow rather than a mobile-style generated host folder.

What generated host output means

The command-line interface generates platform folders under platforms/<target>/ for scaffolded targets. Those folders contain host-specific notes, scripts, and supporting files for packaging and launch.

In practice, a generated host may include a launcher script, bundle or manifest metadata, and a target-specific README.md file that explains prerequisites and current caveats.

The important contract is that generated target output stays thin. Your product logic remains in shared Rust code, while the target folder owns host setup.

Choosing a target in practice

Target choice should follow product need.

If your app is browser-first, the Web target belongs early because browser hosting, browser packaging, and browser behavior are part of the real product.

If your app is mobile-first, Android and iOS belong early because touch layout, safe areas, text entry, packaging, emulator flow, and simulator flow are part of the real product.

If your app is command-workflow-first, Terminal belongs early because terminal cells, keyboard navigation, scrollback, and command sessions are the real product constraints.

If your output is documentation, marketing, reference, or blog pages, Static site belongs early because crawlable HTML, metadata, search, sitemap, and route generation are the target.

If your output needs request-time data, sessions, signed actions, server jobs, workers, or islands, SSR belongs early because the server request lifecycle is the target.

If your current question is still mostly about shared reducers, widgets, selectors, and layout behavior, the desktop host is often the shortest general loop on many machines. That is a workflow convenience, not the identity of the framework.

Desktop expectations

macOS, Windows, and Linux are real shipping targets, not only preview hosts.

They are usually the lightest local loop because cargo run can launch them directly without a separate browser or mobile packaging step. That makes them convenient for broad shared-runtime work, but desktop is only one host family among several real targets.

Web expectations

The Web target generates a browser host around the shared runtime. In practice, that means a WebAssembly build plus a local browser-serving path.

The checked-in proof path is examples/web-smoke/, and generated apps use the same style of launcher through ./platforms/web/run-browser.sh.

Treat the Web target as a real browser host with its own validation needs, not as a cosmetic variation of desktop.

Android expectations

The Android target generates an emulator-oriented mobile host path around the shared app.

In practice, that means Android software development kit (SDK) setup, Android native development kit (NDK) setup, generated packaging files, and the launcher script ./platforms/android/run-emulator.sh.

The checked-in repo-backed proof path is examples/mobile-smoke/, which documents the current emulator flow and environment details.

iOS expectations

The iOS target generates a simulator-oriented host path around the shared app.

In practice, that means simulator prerequisites, generated bundle support, and the launcher script ./platforms/ios/run-sim.sh.

The checked-in smoke examples and public docs treat the iOS simulator path as the current concrete validation path. As with Android, this host boundary has its own prerequisites and should be validated directly.

Terminal expectations

The Terminal target runs through the terminal shell. It is useful for command tools, setup flows, diagnostics, admin workflows, and developer tooling that should be interactive without becoming a graphical app.

Terminal validation should check cell layout, keyboard navigation, pointer support where available, bounded scrollback, command sessions, logs, and screenshots captured from the terminal renderer.

Static site expectations

The site target renders Fission widgets and Markdown content into static HTML, CSS, search assets, sitemap files, robots files, and copied assets. Use it for documentation, marketing, reference, blog, and other mostly-read pages where crawlable output matters.

Static sites are validated with fission site check, built with fission site build, and packaged with fission package --target site --format static or --format docker-image.

SSR expectations

The server target is the SSR target. It runs a Fission server app that renders HTML at request time or through revalidated cache entries. Use it when pages need server jobs, request-time data, signed actions, cache invalidation, progressive workers, or focused WASM islands.

SSR apps are validated with fission server check, run locally with fission server serve, and packaged as Docker images with fission package --target server --format docker-image.

Files and paths worth knowing

When you inspect generated output, the most important files are usually:

•

fission.toml, which records project and target configuration

•

platforms/<target>/README.md, which explains prerequisites and current status for that host

•

target-specific launcher scripts such as run-browser.sh, run-sim.sh, and run-emulator.sh

•

assets/app-icon.png, which seeds generated app icon usage

How to validate targets

Use the host that matches the behavior you need to prove.

Use desktop heavily when the question is mostly about shared runtime behavior and you want a short local loop.

Use Web when browser hosting, browser layout, browser packaging, or browser-specific behavior matters.

Use Android and iOS when mobile packaging, mobile layout, simulator or emulator launch, or other mobile host behavior matters.

Use Terminal when terminal cells, command workflow, keyboard behavior, and terminal-compatible presentation matter.

Use Static site when the output must be crawlable static HTML for documentation, marketing, reference, or blog pages.

Use SSR when the page needs request-time data, sessions, signed actions, cache revalidation, progressive workers, or focused browser islands.

Use the checked-in smoke examples and generated target folders together. The examples prove the repository's current host paths, and the generated folders show how that host shape reaches your own project.

For shell-wrapper boundaries, see Platform runtime. For target-level testing expectations, continue to Platform testing. For the learner-facing explanation of examples and host choice, see Examples and targets.