Skip to content

Expo EAS Update problemExpo: you published an EAS Update, and the app still shows the old version

The eas update command finished, the dashboard shows the update, and the app on your phone still runs the old code. An installed build only takes an update that matches its runtime version and channel, and by default it applies the update on a later launch. Here is each check from Expo’s debugging guide, or hand it over at a fixed price.

Short answer

First, close the app fully, open it, then close and open it again: by default the update downloads on one cold start and loads on the next. If it still doesn’t appear, compare the build’s runtime version and channel on the Deployments page with your update’s runtime version and branch, map the channel to the branch you published to, and check whether the update crashed and rolled back.

Why the update isn’t loading, and the fix

  1. 01

    The app hasn’t been restarted enough times

    “the end user will only load the update when they cold boot the app after an update has been published, and then at some point kill and restart the app” Expo, Download updates

    By default the app checks for an update when it starts from a killed state and downloads it in the background without waiting. The new code runs the next time the app is killed and started again, so one restart is often not enough.

  2. 02

    The runtime version doesn’t match the build

    “A build and an update are compatible when they share the same runtime version and platform.” Expo, Debugging EAS Update

    An update only goes to builds with the same runtime version. If the build was made before you changed runtimeVersion or the app version (with the default appVersion policy), the update targets a different runtime and the build ignores it. Rebuild, or publish for the runtime the build has.

    "expo": {
      "runtimeVersion": {
        "policy": "appVersion"
      }
    }
  3. 03

    The build’s channel points at a different branch

    “When a channel and branch are linked, an app with a channel will get the most recent compatible update on the linked branch.” Expo, Debugging EAS Update

    A build has a channel, set in eas.json when it was built, and the channel is linked to a branch. If you published to a branch the channel isn’t linked to, the build never sees it. Check the mapping on the Channels page and change it if needed. If the build itself has the wrong channel, remapping won’t help: fix the channel in eas.json and rebuild. The eas update output prints the branch and runtime version it published to, which is the quickest check.

    # eas channel:edit [channel-name] --branch [branch-name]
    # Example
    eas channel:edit production --branch release-1.0
  4. 04

    The update crashed and the app rolled back

    “EAS Update is designed to automatically roll back to the previous update if it detects that a new update crashed shortly after launch.” Expo, Debugging EAS Update

    If the Deployments page looks right but the app still shows the previous code, the new update may crash on launch, for example because it relies on native code the build doesn’t have. Expo also says a common reason a new update doesn’t work while the embedded code does is a missing environment variable. Reproduce it on your own device and read the expo-updates logs.

Checked against the vendor’s docs on : Expo docs: Debugging EAS Update; Expo docs: Runtime versions and updates; Expo docs: Download updates.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Expo EAS build failed · Expo app crashes in production

Questions

More on this error

I added a native library. Can I ship it with an update?

No. Expo says any time native code is updated, a new build is required before publishing an update. Raise the runtime version, make a new build, and publish updates for that runtime.

How do I make users get updates sooner?

Expo’s download guide covers checking for an update at launch with your own loading screen, or downloading in the background and reloading. The default doesn’t block startup, so users see an update one launch later.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.