Distribution and packaging

Deliver validated Flutter desktop and mobile applications without turning independent distribution targets into an all-or-nothing rollout. Existing Iced archives remain historical packaging evidence, not layouts that the unreleased Flutter application must preserve.

Treat AppImage, Flatpak, Windows installers, macOS Developer ID signing/notarization, Android/iOS store packages, and shared icons/metadata as independent work packages. Each native package owns its Flutter host, the pinned PDFium and SQLite libraries its Dart bindings load, architecture validation, installation and launch smoke tests, licenses, update expectations, and platform-specific security boundaries.

Release builds remain reproducible and must not fetch mutable assets. Signing credentials stay in protected CI environments, unsigned pull-request builds exercise the same layout and validation where possible, and package metadata must not claim unsupported formats or platform behavior.

RFD 12's Flutter feasibility and parity gates precede new production packaging. Nix and existing archives may continue validating the Iced reference during migration, but new package recipes must be derived from the Flutter artifact rather than preserving Cargo-binary assumptions. Web deployment remains a separate feasibility result because it packages the bindings' browser builds rather than native libraries.

Completed baseline work and the independent package acceptance criteria are tracked in RFD 13 implementation checklist.