When EAS Update Ships but the Bug Won't Die — Why OTA Stalls Silently, and How I Operate Around It

Prevent runtimeVersion drift by design

I'll call it drift when runtimeVersion quietly diverges over time. The policy you choose changes this enormously.

// app.json
{
  "expo": {
    "runtimeVersion": { "policy": "appVersion" },
    "updates": {
      "url": "https://u.expo.dev/YOUR_PROJECT_ID",
      "enabled": true,
      "checkAutomatically": "ON_LOAD",
      "fallbackToCacheTimeout": 0
    }
  }
}

Each policy has a temperament:

The decision axis is simple. If you want OTA to reach as many users as possible, sdkVersion wins because its runtimeVersion changes rarely. If you never want to get native compatibility wrong, fingerprint is the safe pick — it's computed from a hash of your native configuration, so it won't ship JavaScript to an incompatible binary and crash it.

In practice I lean on sdkVersion for small apps that stay on one SDK, and fingerprint for apps where I add and remove native modules. I reserve appVersion for cases where I have a clear intent to re-scope OTA per release. Choosing appVersion without that intent quietly strands users on older builds every time you bump the version.

See adoption in numbers, not assumptions

To turn "it should be landing" into "it is landing," instrument adoption on the device. expo-updates exposes the identity of the running bundle at runtime.

import * as Updates from "expo-updates";
 
export function reportUpdateState() {
  // Run on boot to make the running bundle observable
  const state = {
    updateId: Updates.updateId ?? "embedded",   // null if running the embedded bundle
    channel: Updates.channel ?? "unknown",
    runtimeVersion: Updates.runtimeVersion ?? "unknown",
    isEmbedded: Updates.updateId == null,
    createdAt: Updates.createdAt?.toISOString() ?? null,
  };
 
  analytics.track("app_boot_update_state", state);
  return state;
}

Aggregate that event and you can see the share of devices running the latest updateId. If the embedded share hasn't dropped hours after publishing, that's an unambiguous sign the update isn't being adopted. Since I started checking this adoption rate on every publish, I've been able to sense "fixed but not actually fixed" before the next deploy.

Why check at runtime at all? Because a successful eas update is a server-side fact, not a device-side one. This boot event is what closes the gap between the two.

When you need it now, don't make users wait

The default checkAutomatically: "ON_LOAD" checks for an update on launch and applies a downloaded update on the next launch. So even an emergency fix stays on the old bundle until the user closes and reopens the app. When checkout is broken, that one beat can be unacceptable.

import * as Updates from "expo-updates";
 
// Only for high-urgency fixes: fetch and apply on the spot
export async function applyCriticalUpdateIfAny() {
  if (__DEV__) return; // OTA does not run in dev builds
 
  try {
    const result = await Updates.checkForUpdateAsync();
    if (!result.isAvailable) return;
 
    await Updates.fetchUpdateAsync();
    // It's kinder to tell the user before reloading
    await Updates.reloadAsync();
  } catch (e) {
    // It keeps running on the old bundle, so record instead of swallowing
    analytics.track("ota_force_apply_failed", { message: String(e) });
  }
}

The point is not to run this forced path for every update. Calling reloadAsync on every launch interrupts whatever the user was doing. I route through this path only for updates flagged as urgent, and let everyday updates take the default next-launch apply — which avoids flicker and interruption.

Rollback isn't one thing — match the method to the incident

"Revert the bad update" sounds singular, but the correct mechanism changes with the situation. Get it wrong and you create a second incident: you think you rolled back, but you didn't.

The one I reach for most is a republish of the previous good update.

# Pick the previous good update group and re-ship it
eas update:list --channel production --json --non-interactive \
  | jq '.[1] | {id, message}'   # [0] is the bad one, [1] is the prior
 
eas update:republish --channel production --group GOOD_GROUP_ID \
  --message "Rollback: revert the checkout-defect update"

When you decide to distrust the OTA mechanism itself for a moment, rolling back to the embedded bundle is the right move. It isn't "stop sending new JavaScript" — it's an explicit instruction to return to the binary as shipped to the store, pulling devices back to a known state.

# Send everyone back to the store-reviewed embedded bundle
eas update:rollback --channel production \
  --message "Emergency: retreat to embedded bundle"

The deciding question is where the fault lives. If a specific update is the problem, republish is enough. If you suspect the OTA path itself or a runtimeVersion mismatch, retreating to the reviewed binary is safer. Since I started asking "is the cause the update's content, or the delivery machinery?" first, I hesitate far less over which rollback to use.

Stop shipping to everyone at once

OTA's power to reach all users instantly means a bad update also reaches everyone instantly. Staged rollout softens that. Ship to a slice first, watch adoption and anomalies, then widen.

# Roll out to only 10% of users first
eas update --channel production --message "Profile revamp" \
  --rollout-percentage 10
 
# Watch adoption and crash-free for a while, then widen if clean
eas update:edit --rollout-percentage 100

The evidence for that decision comes from the boot event above plus crash metrics. If, right after the 10% rollout, the crash-free rate among devices running that update is clearly below the population, you can stop before going to 100%. Adding this "observe before widening" beat has, on several occasions, let me cancel an update before it became a fleet-wide outage. OTA's speed is a fang when the update is bad; staged rollout is the insurance that blunts it.

The pre-publish check I run for myself

Finally, the check I always run right before publishing. Nothing exotic — but trouble showed up precisely on the days I skipped it.

First: does the runtimeVersion of the update I'm about to publish match the runtimeVersion of the build currently live in the store? Next: for an emergency fix, am I routing through the immediate-apply path rather than staged rollout — and conversely, am I not mistakenly calling reloadAsync on every launch for routine updates? And: if I end up reverting, have I decided in advance whether republish or an embedded rollback is the right call? Saying those three out loud shrinks the post-publish anxiety considerably.

OTA is a dependable way for a solo developer to dismantle the review wall. It also carries a quiet gap between the success message and the actual rollout. Making that gap visible in numbers is, in my ongoing experience, the surest way to cut down on the late-night support emails.

If this helps you isolate your own "it won't arrive" a little faster, I'm glad.