Build and package
Packaging turns a working Fission app into something another person, device, store, host, or deployment system can consume. It is separate from distribution: packaging creates the artifact, distribution uploads or submits it.
Use this overview to choose the correct target page, then follow that page for the exact package shape.
The package loop
A reliable package flow has four steps:
Step | Command shape | Why it exists |
|---|---|---|
Check readiness | fission readiness package ... | Finds missing SDKs, generated targets, signing references, icons, package ids, and provider tools early. |
Package | fission package ... | Builds the target artifact and writes an artifact-manifest.json. |
Verify locally | Target-specific run, install, serve, or open | Proves the packaged output behaves like the product users will receive. |
Hand off to release | fission release-content ... and fission distribute ... | Uses the manifest instead of guessing which file should be uploaded. |
Do not skip readiness when preparing a release. It is cheaper to discover a missing Android NDK, Xcode tool, icon, or signing reference before the package command starts.
Pick the target page
Output | Start here | Typical package formats |
|---|---|---|
Windows, macOS, Linux app | .exe, .msi, .msix, .app, .pkg, .run | |
Android or iOS app | .apk, .aab, .ipa | |
Browser app | static web artifact directory or archive | |
Terminal app or command tool | release binary and manifest | |
Documentation, marketing, reference, blog | static artifact or Docker image | |
Ecommerce, portal, dashboard, dynamic web process | Docker image |
If a page is mostly read-only and should be crawlable, use the static site target. If it needs request-time data, sessions, signed actions, cache revalidation, workers, or islands, use the server site target. If it is a full interactive browser app, use the web target.
Artifact manifests are the handoff point
Every package format should produce an artifact-manifest.json. That manifest records project identity, target, format, profile, paths, hashes, sizes, MIME types, validation checks, and related files.
Release commands should consume the manifest. That keeps publishing safe to retry because the command can tell exactly what was built and what it is about to upload.
Signing boundaries
Signing is platform-owned. Fission orchestrates checks, configuration, command flow, and receipts, but platform signing should use the tools provided by the platform owner.
Do not commit signing passwords, private keys, tokens, or certificates into fission.toml. Use CI secrets, environment variables, authenticated platform tooling, operating-system key stores, or the Fission credential vault.
Next steps
After packaging, move to Release and distribute. If the release needs notes, screenshots, or store metadata, start with Release content.
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