Cross-platform contract and native release safety

Part 16 · Further improvements

Cross-platform contract and native release safety

Prerequisites: 15-module-design-choice

Native API changes require a new binary; the update must match its compatible runtime. Nodes: Native sources, Build binary, Installed app, JS update, Runtime version. — Native API changes require a new binary; the update must match its compatible runtime. [S19] [S20]

Baseline verified

Record the public JS API, native dependencies, platform permissions, config plugins and runtimeVersion for each release. An OTA update replaces a compatible JS layer, not the compiled native layer.

[S19] [S20]

Proposed improvement synthesis

CI can build both platforms, exercise JS contract tests against native implementations, and test an update against a preview binary with the same runtimeVersion before rollout. This is a proposed gate, not a claim about an existing pipeline.

[S19] [S20]

Trade-off verified

A strict fingerprint-based runtime policy may require more binaries but reduces accidental compatibility mistakes; a manual policy offers control and demands discipline.

[S19]

Pitfall verified

Changing AndroidManifest.xml or Info.plist manually in a CNG project can be overwritten at prebuild. Preserve native configuration in app config/plugins and verify generated outputs.

[S20]

Keep this: A JS update can target only a binary containing compatible native modules and configuration.

Check yourself: Can an OTA update add a newly installed native library to users’ existing binary?

No. Native code must be compiled into a new Android/iOS build; only compatible JS updates can target it.