Limits of OTA Updates and Runtime Versions

WHAT THIS TESTS Whether you understand that OTA only swaps the JS layer and how to prevent shipping incompatible updates.

A GOOD ANSWER COVERS OTA updates can replace the JavaScript bundle and bundled assets, nothing more. Any change that touches the native binary cannot ship OTA: adding or upgrading a native module, bumping the React Native version, changing native permissions or entitlements, modifying app icons or splash screens defined natively, or altering Info.plist or AndroidManifest entries. To prevent a JS bundle landing on an incompatible native shell, OTA systems use a runtime version: each binary advertises a runtime version, and the update server only serves bundles compiled for that same runtime version. When you make a native change you bump the runtime version, which means existing installs stop receiving OTA updates until users download the new store build. Your code should detect this gracefully, for example checking for the latest store version and prompting users to update when a required native change exists, rather than silently failing.

COMMON WRONG ANSWERS Claiming you can OTA a native dependency upgrade. Ignoring runtime versions and assuming all installs get every bundle. Believing OTA lets you bypass store review for major feature or policy-relevant changes.

LIKELY FOLLOW-UPS How runtime versions are set, manually or derived from native fingerprints. How to force users onto a new native build. Whether store policies restrict what behavior OTA may change after review.

ONE CONCRETE EXAMPLE You add the camera native module, which requires native permission changes, so you bump the runtime version and submit a store build. Installs on the old runtime no longer receive the new JS bundle; your app checks the published store version and shows an update-required prompt so those users move to the new binary.