Desktop packages
Desktop packaging takes the shared Fission app and gives it the operating-system metadata users expect: name, icon, bundle identity, installer shape, signing references, and a predictable artifact manifest.
1. Check the desktop target
Start with readiness. It catches missing target setup and packaging tools before the release build starts.
fission readiness package --project-dir . --target macos --format app
fission readiness package --project-dir . --target windows --format msix
fission readiness package --project-dir . --target linux --format run
Readiness should confirm the target exists in fission.toml, the app has usable icons, the package identity is present, and the platform tools needed for the selected format are available.
2. Choose the package format
Target | Format | Use it for |
|---|---|---|
macOS | .app | Local app-bundle validation and direct distribution. |
macOS | .pkg | Installer-based distribution and managed deployment. |
Windows | .exe | Signed executable, or a project-defined offline installer flow. |
Windows | .msi | Enterprise or managed Windows installer flow. |
Windows | .msix | Microsoft Store and modern Windows package identity workflows. |
Linux | .run | Self-contained Linux installer artifact. |
Use the smallest format that proves the next step. For example, use .app while validating icon, dock, and permission behavior on macOS; move to .pkg when installer behavior matters.
3. Build the package
fission package --project-dir . --target macos --format app --release
The package command writes the platform artifact and an artifact-manifest.json under target/fission/release/<target>/<format>/. Use that manifest for release commands instead of passing a raw file path.
For macOS apps with native extensions, declare the Xcode project and products
under [[native.modules]] in fission.toml. Fission builds the native schemes,
embeds app extensions and system extensions in their platform-defined bundle
locations, signs those nested products, and signs the containing app last. The
same declaration is used by fission build, fission test, fission run, and
fission package; app-specific build scripts should not duplicate that work.
Linux Cargo-native products use [native.modules.linux]. Fission builds and
tests the declared package, stages runtime files and privileged helpers into
development and package roots, and embeds a digest-bearing native-products
manifest in Linux .run payloads. privileged-helper is packaging metadata;
Fission never silently adds setuid bits, capabilities, or an elevation policy.
The application installer remains responsible for an explicit, auditable
privilege transaction.
Windows MSBuild/WDK products use [native.modules.windows]. Runtime products
are staged beside the app for local runs and are exposed to package scripts in a
structured native-products manifest. Products marked driver-package are
installer inputs and are deliberately excluded from MSIX manifests. Configure
package.windows.exe_installer_script when windows/exe must produce a setup
program rather than stage the application executable itself. Set
nuget_packages_config and nuget_packages_directory when the native project
pins the supported WDK NuGet packages; Fission restores them non-interactively
before every MSBuild invocation.
4. Verify the result
Open or install the produced package on the target operating system. Check the app name, icon, dock or taskbar behavior, permission prompts, window title, and any capability the app needs. Packaging is not complete until the installed app behaves like an app, not like an unnamed development binary.
Next steps
Read Release and distribute when the desktop artifact is ready to upload. For exact manifest fields, use the fission.toml reference.
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