Expo Updates fallback after a failed OTA launch: what triggers the revert and can it be forced?

Short answer

In recent Expo SDKs, a failed OTA launch triggers an automatic fallback to the embedded binary on the next cold start. There is no supported client-side API to force a rollback or invalidate an update programmatically. Documented behavior is largely consistent across iOS and Android, though the underlying storage and crash-detection paths differ.

What triggers the revert

expo-updates is designed to record a successful-launch marker once the JS bundle has loaded and the app reaches a stable state. If the process terminates or the bundle fails to execute before that marker is written, the next launch treats the update as failed and reverts to the binary embedded in the native build.

The timing of the failure matters:

• Load-time failure (syntax error, missing asset, immediate throw): The marker is never set, so the next launch falls back automatically.
• Post-launch crash (app loads, marker is set, then crashes later): The automatic fallback may not trigger, leaving users on the bad update until a corrective update is published.

Exact timing thresholds and fallback asset selection have been refined across SDK releases, so confirm the behavior against your installed expo-updates version.

Can you force a rollback?

No supported client-side API exists to invalidate an update or force a rollback from JavaScript. Recovery is server-side:

1. Publish a corrective update to the same channel.
2. Use EAS Update channel controls to repoint the channel to a known-good release.

Clearing app data or reinstalling removes the update cache, but that is a manual user action, not a programmatic mechanism.

iOS and Android differences

Recent Expo SDKs document the same fallback model on both platforms: launch-failure detection, marker persistence, and embedded-binary fallback. The implementation details differ, but no platform-specific rollback API is exposed, and neither platform offers a supported "revert to previous OTA" option.

Verification plan

To confirm this on your installed version:

1. Install a build with expo-updates on a physical device.
2. Publish a bundle that throws during initialization to a test channel.
3. Launch once to trigger the failure, then relaunch and confirm the app reverts to the embedded bundle.
4. Inspect device logs or expo-updates logging to verify whether the launch-failure marker was set before the crash.

One diagnostic question

Is your concern a bundle that fails to load (immediate crash on launch), or one that loads successfully but crashes later? If it is the latter, the automatic fallback may not apply, and your recovery process must rely on publishing a corrective update rather than waiting for the revert.