Runtime Version
What Runtime Version Is
runtimeVersion is the compatibility boundary between an installed native binary and the OTA bundles it can receive.
Bundle Drop only delivers an update when the app and bundle resolve to the same runtime version. This prevents JavaScript from expecting native code that is not present in the installed binary.
Default Literal Runtime Versions
Expo and bare React Native use the same literal runtime model by default:
module.exports = {
runtimeVersion: {
ios: "1.0.0",
android: "1.0.0",
},
// serverUrl, org, and project are generated during login
};The bundle manifest records the platform runtime during bundling. Upload fails closed if no runtime can be resolved, and there is no upload flag that silently overrides it.
When to Keep or Bump It
Keep the same platform runtime for changes that remain compatible with the installed native binary, including most JavaScript, styling, copy, and bundled asset updates.
Bump the affected platform runtime and create a new native build when compatibility changes, including:
- native iOS or Android code changes
- adding, removing, or incompatibly upgrading a native module
- changing the JavaScript engine or React Native architecture
- changing an Expo config plugin or another native build input
An iOS-only native change only requires a new iOS runtime. Android can remain on its existing compatibility line.
How Runtime Lines Behave
- Older binaries continue receiving the last compatible updates on their runtime line.
- Newer binaries receive updates published for their new runtime line.
- A channel can contain builds and bundles for more than one runtime version; compatibility is resolved when the app checks for an update.
Changing the runtime is therefore a native compatibility decision, not a channel reset.
Strict Expo Fingerprint Authority
Expo projects can optionally delegate runtime authority to the evaluated Expo configuration:
module.exports = {
projectType: "expo",
runtimeVersion: { source: "expo" },
// serverUrl, org, and project are generated during login
};This strict mode binds uploads to the exact Expo build identity and requires a matching build receipt. It is useful when your release policy requires fingerprint enforcement, but it is not the default. Literal Bundle Drop runtime versions do not require Expo receipts or upload-time fingerprint comparison.
See Expo for local and EAS Build behavior.
Keep Configuration in Source Control
Commit bundle.drop.config.js so local builds, CI, and uploads resolve the same compatibility boundary. When you bump a platform runtime, build the corresponding native binary from that configuration before publishing updates for the new line.