Baselines and patches

Hyfens separates a normal native app release from a signed patch. A patch is bound to one exact baseline and supports only changes the released compiler/runtime accepts.

The native release is the baseline

hyfens release android or hyfens release ios creates a target-specific baseline using the normal Flutter release build path. The release establishes the app and build identity that later patch checks use. The initial binary still needs to be built and distributed through the app's normal release channel.

The CLI option --metadata-only is a test convenience that skips a Flutter build. It is not evidence that a customer release has been built or accepted.

A patch must fit the baseline

hyfens patch android or hyfens patch ios analyzes changes against the selected exact release, compiles supported changed code, signs the resulting artifact locally, and verifies it before deployment. The patch format and runtime enforce the release binding and supported capabilities; the command is not a general-purpose replacement for a store build.

Changes to native code, app manifests, permissions or entitlements, dependency graphs, native plugins/configuration, engine behavior, or added/changed/removed assets and fonts need a new native baseline and may require the platform's normal review. Unsupported source constructs should fail analysis; do not assume that any Dart or Flutter change can be patched.

The tagged support matrix describes several language and Flutter areas as partial or untested. Its tested toolchain family is Flutter 3.47.x and Dart 3.13.x. A Flutter framework version range is not the same as Hyfens compatibility evidence.

Publishing is not device confirmation

hyfens deploy registers release and patch metadata, uploads the exact artifact bytes, and asks the selected control plane to promote it with its authorization and preconditions. A successful command confirms the control-plane operation. It does not confirm that every installed app downloaded, validated, or applied the patch.

The released Flutter integration polls immediately at startup and then every two seconds by default. A device still needs network access and a matching app, platform, and baseline. When the service is unavailable, the runtime keeps its current patched state or baseline and can try again later. Do not interpret a published artifact or successful deploy as instant device delivery.

When the runtime is restarted while activation is pending and unconfirmed, it falls back to the last-known-good patch or the baseline. The integration’s activation confirmation is not application crash monitoring or a guarantee of health after activation.

Full integration status

The v0.1.10 release contains Android/iOS CLI and Flutter integration code. Its tests include controlled fixtures and service boundaries, but the release’s independent real-app acceptance matrix is not established as complete. These docs therefore do not present a verified customer recipe for building a baseline, publishing a test patch, and observing it on a real app.

Start with installing the CLI, inspect the exact installed command options with hyfens <command> --help, and use the CLI reference. For a patch that is missing or not applied, follow update troubleshooting.