Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An Expo over-the-air (OTA) update is a production release that can reach people who already have your app installed, with no new store binary. That speed is the benefit and the risk. What limits the damage is not the delivery mechanism itself but four controls: runtime compatibility, how far the update is distributed, code signing, and your ability to recover. The sections below explain what each control does, where it stops, and the order you should apply them in.
Why the runtime version decides what an update can break
Every installed build of an Expo app contains native code, such as native modules and the native shell. An OTA update only replaces the JavaScript and assets that run on top of that native code. The runtimeVersion value is the boundary between the two. A build only accepts updates whose runtime version matches its own, so the value tells the client whether a given update is safe to run against the native code it already has.
Expo’s documentation warns about the failure mode that matters most here: if you change native code and forget to change the runtime value, an incompatible update can look compatible and be delivered to builds that cannot run it. The rule is simple to state. If an upcoming change requires native code, ship a new build and make sure its runtime version differs from the previous one. (Expo’s runtime version documentation and How EAS Update works cover the mechanics.)
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteChoosing a runtime version policy
Expo offers more than one way to derive the runtime version. Expo’s deployment guide recommends appVersion as its policy in that guide. Its runtime version guide also describes fingerprint, which reflects native changes automatically. Neither is universally correct, so treat the trade-off below as the decision, and check the current Expo documentation for the policy your project should use.
#1 Best Overall
| Policy | How the runtime value changes | Main strength | Main cost |
|---|---|---|---|
appVersion |
Tied to your app version; changes when you increment it | Simple to reason about and recommended in Expo’s deployment guide | Depends on the team bumping the app version whenever native code changes; a missed bump is the stale-runtime risk |
fingerprint |
Derived from the native project, so native-impacting changes produce a new value automatically | Captures native changes without relying on a manual bump | Can require more builds; Expo’s runtime version guide notes this trade-off, so check its current guidance on maturity and suitability |
Whichever policy you pick, write the decision down before your first release so every developer applies it the same way.
The safe release sequence
Most of the risk is removed before an update is published. Work through the sequence below for every production update, and treat any skipped step as a conscious exception.
- Confirm the change is JavaScript-only. If the update touches native modules, native configuration, or anything that changes the native build, ship a new store build with a new runtime version instead of an OTA update.
- Build a preview or staging app on the same runtime as production. Use production-like configuration, and keep its environment variables and code-signing configuration aligned with production. Expo’s deployment guide recommends this matching explicitly (Deploy updates).
- Test on a realistic device with realistic stored data. A fresh install with empty storage will not reveal problems in data written by the previous version. Test upgrades from older installed versions that have real local state.
- Publish the update you actually tested. Where your workflow allows it, promote the tested update rather than rebuilding a different one, so the bits you verified are the bits users receive.
- Roll out to a small audience first. Staged percentage rollouts limit how many devices receive a bad update before you see the problem (see the next section).
- Watch the signals before widening the rollout. Keep the update under observation until error rates are stable.
Limit exposure with staged rollouts and monitoring
Publishing to everyone at once is faster. A staged percentage rollout is slower but limits the initial exposure, and it gives you time to measure error rates before the update reaches the whole user base. Expo’s runtime version guidance says to cancel a rollout when errors rise, and to roll back if the update is already fully rolled out.
EAS Update Insights gives you the signals to act on. Expo’s introduction lists crash rates, install and launch counts, unique users, payload size, and the split between OTA and embedded usage (EAS Update). Decide in advance which thresholds would make you pause, so that the decision does not depend on how the dashboard looks on the day.
Rank #3
Code signing: verifying that an update is authentic
Without signing, a client trusts an update because it arrived through the configured delivery path. End-to-end code signing adds a second check. The client verifies the update’s signature before applying it, which helps protect against tampering in transit or at the hosting layer.
The trade-offs are real. According to Expo’s code signing documentation (End-to-end code signing with EAS Update), EAS Update Code Signing is limited to Production or Enterprise plans. The certificate is embedded in the build, so a change to the signing certificate or key configuration requires a new runtime and a new build. Before adopting it, confirm that your plan qualifies, decide who holds the private key, keep that key restricted, and write a rotation procedure. Rotation is much easier to plan than to improvise after a leak.
Rolling back a broken update
Expo documents two rollback targets, and they answer different questions.
| Rollback target | What affected clients run afterward | When it fits | Limit |
|---|---|---|---|
| A previously published update | That earlier JavaScript and assets, delivered as an update | A known-working update exists and is compatible with the native build in the field | Does not undo changes already written to persistent data |
| The embedded update | The code packaged inside the installed binary | Published updates are unsafe and the embedded code is the last known-good state | Does not undo changes already written to persistent data; the embedded code may be old |
The key constraint appears in both Expo’s rollbacks guide and its error recovery documentation: neither option reverses incompatible persistent-data changes. If a newer update has migrated local data into a shape that an older update cannot read, rolling back can make things worse. In that case, check persistent data and migrations first, then publish a tested fix forward rather than reverting.
Recovery steps when an update breaks
- Pause or cancel the rollout so the problem stops spreading.
- Identify whether the failing update changed the data format or migrations. If it did, do not revert without testing the older code against data the newer version has already written.
- If a known-safe prior update exists and reads your current data, republish it or point clients to the embedded update, depending on which is safer.
- If no safe rollback exists, ship a tested fix forward and roll it out through the same staged process.
Overrides and automatic recovery
Expo’s override documentation covers a configuration that can remove the safety net. Overriding the update URL or request headers at runtime in a production build, with anti-bricking safeguards disabled, can remove the embedded fallback and prevent automatic recovery after a crash. Expo documents this feature as intended for preview builds (Override update configuration at runtime). Keep production builds on the standard configuration.
Even with recovery enabled, do not treat it as a guarantee. Expo’s error recovery page states: “It is not a full safety net that protects your end users from the results of errors; in many cases, users will still see a crash.” (EAS Update error recovery). The practical lesson is that testing and staged rollout do the real protecting, and recovery is the fallback.
Pre-publish checklist
- The change is JavaScript-only, or it has a new runtime version and a new build.
- The runtime version policy is documented and was applied to this change.
- Staging matches production runtime, environment variables, and signing configuration.
- The update was tested on a device upgraded from an older version with real stored data.
- Rollout starts at a small percentage, with error thresholds agreed in advance.
- A rollback path is identified, including whether any data migration makes rollback unsafe.
- Production uses standard update configuration, with no URL or header overrides.
Used together, these controls turn an OTA update from a loaded gun into an ordinary release with a defined blast radius. None of them removes the need for careful testing, because an update that passes every gate can still contain a bug that only real users reach.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
