Over-the-Air Updates with Expo: Risks and Best Practices

Key facts, with sources

• 71% of State of React Native 2024 respondents reported using Expo's EAS Build, ahead of manual builds with Xcode (59.7%) and Android Studio (54.5%). (InfoQ)
• Expo SDK 52, released November 12, 2024, enabled the New Architecture by default for all new projects, and Expo Go for SDK 52 and higher supports only the New Architecture. (Expo Changelog)
• The official React Native documentation now recommends starting new apps with a framework, naming Expo, rather than initializing a bare project. (React Native documentation)
• EAS build caching can speed up subsequent Android and iOS builds by up to 30% and is available to all users at no additional cost as of the SDK 57 cycle. (Expo Changelog)
• Doctolib runs Expo tooling without EAS to scale developer experience on a healthcare app serving 90 million users, showing Expo's open-source tools work independently of its paid cloud services. (Doctolib Engineering (Medium))

What OTA can and cannot change

An EAS Update delivers a new JavaScript bundle and assets — images, fonts, translations — to binaries already on users' devices. It cannot change anything native: no new native modules, no permission changes, no app icon or splash updates, no SDK upgrades. The mental model I give teams: if the change would require running prebuild again, it needs a store build.

The dangerous failures live at the boundary. You add a library with native code, it works in your development build, you publish an OTA update, and every production user crashes on launch because their binary lacks the native half. This exact incident shows up repeatedly in rescue projects I take on. Everything else in this post is essentially machinery to make that mistake impossible.

Runtime versions: use the fingerprint policy

Runtime versions are the compatibility contract: an update only installs on binaries with a matching runtime version. You can manage this by hand, but humans forget to bump versions after native changes — which recreates the crash scenario above. The fingerprint policy removes the human: Expo hashes the native-relevant parts of your project (dependencies with native code, config affecting prebuild) and derives the runtime version from it. Change anything native and the fingerprint changes, so old binaries simply never receive the incompatible update.

This is the single highest-leverage OTA setting. Every project I set up uses it unless there's a specific reason not to.

{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": {
      "checkAutomatically": "ON_LOAD"
    }
  }
}

Channel discipline: preview before production

Channels bind builds to update streams: a binary built with channel preview only sees updates published to preview. My standard flow is two channels minimum. Every update is published to preview first, verified on real devices by whoever owns QA, then published to production. The verification step is non-negotiable — OTA bypasses store review, which means it also bypasses the accidental safety net review provided.

The eas update:rollback command is the emergency brake: it re-points a channel at the previous update (or the bundle embedded in the binary), and clients pick it up on their next check. Rehearse this before you need it — the first time your team runs a rollback should not be during an incident.

# Publish to preview and verify on device first
eas update --channel preview --message "Fix checkout crash"

# Promote the verified fix to production
eas update --channel production --message "Fix checkout crash"

# Emergency brake: re-point production at the previous update
eas update:rollback

Store policy: the line you must not cross

Both app stores explicitly permit JavaScript-level updates for React Native apps — this is settled, and OTA itself is not a policy violation. What violates policy is using updates to materially change what the app is: unlocking features that weren't in the reviewed build, changing the app's purpose, or routing around review for things reviewers care about, like payment flows.

My rule for clients: OTA is for fixes, copy changes, tuning, and incremental iterations of already-reviewed features. Anything a reviewer would want to see — new purchase flows, new permission-triggering features, significant new surfaces — goes through a store build even though OTA could technically deliver it. Losing a developer account over an update shortcut is a catastrophically bad trade for any startup.

Operational habits that keep OTA boring

A few habits separate teams that run OTA safely from teams that get burned. Write meaningful update messages — during an incident, an update history full of 'fix' is useless. Tag your error tracking with the update ID so crash reports map to the exact bundle that caused them; without this, debugging production OTA issues is guesswork. Understand your download timing: by default an update fetched during one session typically applies on the next launch, so don't expect instant fleet-wide cutover, and don't panic when metrics shift gradually.

Finally, resist update frequency creep. OTA makes shipping so cheap that teams start pushing multiple updates daily, which erodes QA discipline and makes regressions hard to attribute. I aim for deliberate, batched updates with a verification pass — the speed is there for emergencies, not as a substitute for a release process.

When to hire senior help

Senior help pays off when deciding between managed and prebuild workflows, setting up EAS-based CI/CD and OTA update channels, or untangling a project that was ejected prematurely. An experienced Expo engineer can usually configure build, submit, and update pipelines in days, a task that costs first-time teams weeks of trial and error. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Expo Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Ejecting to the bare workflow at the first native requirement instead of using config plugins and development builds, permanently giving up managed upgrades
• ✕Testing only in Expo Go and misconfiguring runtime versions for expo-updates, so an OTA update ships JavaScript that crashes against mismatched native binaries
• ✕Burning EAS build minutes on every commit in CI without caching or local builds, turning a convenience service into a surprise line item
• ✕Skipping several SDK upgrades in a row, then being forced into a large breaking migration when app store target API level deadlines arrive

Frequently asked questions

Sources

• InfoQ
• Expo Changelog
• React Native documentation
• Expo Changelog
• Doctolib Engineering (Medium)