Reference overview
The Learn and Docs sections teach Fission in lifecycle order. The Reference section is the place you come back to when you already know roughly what you are building and need to confirm a contract, a type, a lifecycle rule, or the right subsystem for a problem.
That difference matters.
A learning page is designed to introduce ideas slowly. A reference page is designed to answer questions precisely. Good reference documentation should still be readable, especially for a newer user, but its main job is to help you look something up quickly without losing the architectural meaning behind the public contract.
Use this section when you are asking questions such as these:
•
What exactly belongs in component conversion?
•
When should I use a job instead of a service?
•
What does Env hold today?
•
Which shell wrappers expose which builder methods?
•
Which widget family should I browse for this screen?
How to use the reference effectively
The fastest way to use this reference well is to identify the layer your question belongs to before you start clicking.
If your question is about app behavior, start in the core runtime pages. That is where the shared contracts live: widgets, state, reducers, effects, resources, environment, input, the rendering pipeline, testing, and diagnostics.
If your question is about how the app reaches macOS, Windows, Linux, Web, Android, iOS, Terminal, Static site, or SSR output, move to the platform pages. Those pages explain shells, targets, target-level testing, and where platform responsibility begins and ends.
If your question is about scaffolding or day-to-day project setup, go to the command-line interface page. If your question is about authoring user interface, go to the widget catalog and then into the relevant widget family.
In other words, treat the reference as a subsystem map. Do not search for type names alone. Start from the job the code needs to do.
Core runtime reference
The core runtime is the heart of Fission. These pages describe the shared model that stays consistent across macOS, Windows, Linux, Web, Android, iOS, Terminal, Static site, and SSR targets.
Start with Widget authoring boundary when you need to confirm what a component is, what conversion is allowed to do, or how BuildCtxHandle and ViewHandle divide responsibility.
Open State system when your question is about GlobalState, typed Action values, reducers, ReducerContext, or selectors.
Move to Commands, services, and jobs and Resources and capabilities when the question is about async work, host integration, timers, or long-lived background behavior.
Use Environment, input, and input method editor for the public input and environment contracts, Animations, portals, and media for runtime-owned motion and overlay/embed behavior, and Rendering pipeline when you need the staged view from component conversion to presentation.
Round that out with Platform runtime, Testing and diagnostics, and Theming and internationalization when your question crosses into shells, verification, or global presentation inputs.
Platform reference
The platform pages explain what happens after the shared runtime reaches a real host.
Targets is the page to open when you need to understand generated host output, target folders, and the practical expectations for macOS, Windows, Linux, Web, Android, iOS, Terminal, Static site, and SSR targets.
Accessibility reference is the support matrix for native screen-reader bridges, semantic HTML output, role mapping, exported node data, and known gaps. Accessibility and internationalization focuses on how semantic meaning and locale-sensitive behavior connect to platform adapters and testing together.
Testing explains target-level validation: what can be proved headlessly, what needs a live shell, and what the current host-level test APIs look like.
command-line interface reference
The command-line interface is part of the public workflow, from project setup through run, logs, readiness, package, release content, distribution, and release receipts.
Open command-line interface overview when you want the exact scaffold and target-management commands, the meaning of their major flags, and the files they generate. Open the fission.toml manifest when you need the complete project manifest schema for targets, capabilities, site builds, packaging, signing, release metadata, publishing providers, beta testing, and workflows.
Maintainers preparing a framework release should use Fission release checklist for the exact version bump, changelog, blog post, crates.io, GitHub release, tag, and website verification sequence.
Widget reference
The widget reference is organized by family because most user interface work begins with a job, not with a complete alphabetical scan.
Start with Widget catalog for the full map, then go to the family page that matches your task: Layout, Inputs, Display and data, Overlays and navigation, or Media.
Each family page points to the dedicated widget pages, and those dedicated pages are where you confirm individual fields and usage details.
A good working pattern
When you are learning a subsystem for the first time, begin with the Learn or Guides pages. Once you are implementing the real feature, keep the matching reference page open beside your code. That combination usually gives the best result: explanation first, then precise lookup.