skip to content

What does eas update:rollback do in EAS Update, and when does it roll back to the embedded update instead of a published one?

level: middleimportance: must knowfreq 46%

answer

  1. rollback is a new publish
  2. republishes the previous update group
  3. no previous group means embedded
  4. target must be the latest group
  5. isRollBackToEmbedded on the client

basics

~20 s

eas update:rollback undoes the latest update on a branch by publishing again: it republishes the update group before it, or, when none exists for that branch and runtime version, publishes a roll-back-to-embedded directive that returns clients to the bundle inside their binary.

solid answer

~50 s

`eas update:rollback` is how you undo an ordinary, fully released EAS Update. It does not delete anything on devices; it publishes. Given an update group ID, which must be the latest group for its branch and runtime version, it looks up the group published before it and **republishes** it, so that older code becomes the newest update and clients move to it on their next check. If there is no earlier group for that branch and runtime version, it publishes a **roll back to embedded** update instead, a directive telling clients to run the bundle compiled into their binary; on the device, `checkForUpdateAsync()` reports it with `isRollBackToEmbedded: true`. Run without an ID, it asks interactively whether to roll back to a published update or the embedded one. Publishing a new update afterwards reaches all clients again.

go deeper

for a junior

Know that eas update:rollback exists and that it rolls back either to an earlier published update or to the embedded one.

for a middle

Explain why a rollback is a new publish, how the command picks between the previous group and embedded, and how the client sees isRollBackToEmbedded.

for a senior

Judge whether a rollback is safe given stored data, and choose between rollback, rollout revert and a fix-forward.

for a principal

Define when on-call may roll back without review and how stale the embedded bundle is allowed to get before rollback to embedded stops being an option.

## Rolling back means publishing In **EAS Update**, devices always move towards the newest update on their channel's branch for their runtime version. So you cannot "un-publish" your way back to older code: a rollback has to make older code the newest thing on the branch. `eas update:rollback` does exactly that, in one of two ways: - **Roll back to a previously published update**: republish an earlier update group as a new group. - **Roll back to the embedded update**: publish a special directive telling clients to run the bundle that shipped inside their binary. ## How the command chooses With a group ID (required in non-interactive mode): 1. It loads that group, which must be the **latest** group for its branch and runtime version; rolling back something that is no longer on top would make no sense. 2. It looks for the group published **before** it on the same branch and runtime version. 3. If one exists, it republishes it, with a default message like `Roll back to "<old message>"` unless you pass `--message`. 4. If none exists, it publishes a **roll back to embedded** update on that branch and runtime version. Without an ID, the command asks "Which type of update would you like to roll back to?" and hands off to the republish flow or to `eas update:roll-back-to-embedded`. `--platform` defaults to `all`, and `--private-key-path` signs the result when code signing is on. ## What clients see | Rollback type | What the client receives | Result on the device | |---|---|---| | To a published update | A new update whose code equals the older one | Downloads and runs it like any update | | To embedded | A **rollback directive**, not a bundle | `checkForUpdateAsync()` returns `isRollBackToEmbedded: true`; the embedded bundle runs | Either way devices change on their **next update check**, under their normal launch settings, so a rollback shortens exposure rather than ending it instantly. ## A worked example Suppose the `production` branch, runtime version `1.4.0`, holds two groups: **A**, published last week and healthy, and **B**, published this morning and crashing. - `eas update:rollback B` finds A as the previous group and republishes it as **A'**, a new group with A's code. Devices on B move to A' on their next check; devices already on A move to A', which changes nothing visible. - If B had been the **first** group ever published for `1.4.0` on that branch, there would be no A. The command would publish a roll back to embedded instead, and devices would return to the bundle from their `1.4.0` store build. - Running the command on A while B exists fails, because A is no longer the latest group; the command only undoes the top of the stack. ## After the rollback The next ordinary `eas update` on that branch reaches **all** clients again, including those that rolled back to embedded. So the usual flow is roll back, fix, publish. ## Rollback versus reverting a rollout | You have | Use | |---|---| | An update released to 100% | `eas update:rollback` | | An update still at a rollout percentage | `eas update:revert-update-rollout` | Both end up republishing the previous state; the revert also deletes the rollout group so the branch is free for the next publish. ## Caveats interviewers probe - **Data compatibility**: a rollback runs older code against whatever the bad update stored. If storage was migrated, the older code may crash on it; the Expo docs warn that rolling back is not always safe for this reason. - **Embedded can be very old**: rolling back to embedded sends users to the code from their store build, which may lack weeks of fixes shipped over the air since. - **Per runtime version**: the rollback acts on one branch and runtime version at a time; builds on other runtime versions are unaffected. - **Nothing native changes**: rollbacks, like updates, only swap JavaScript and assets.

  • Why is rolling back to the embedded update riskier than it sounds?
    The embedded bundle is whatever shipped in the store build, possibly weeks older than the last good over-the-air update. Users lose every fix published since, and that old code must still read any data later updates wrote. Rolling back to the last good published update is usually the gentler move when one exists.
  • Can you run eas update:rollback against an update that is no longer the latest on its branch?
    No. The group you pass must be the latest one for its branch and runtime version, because the command republishes the group before it. To return to an older point in history you republish that specific group directly, which is the republish workflow rather than a rollback.

saying these in an interview costs you the question

  • Believes rollback deletes the update so devices fall back automatically
  • Thinks rollback restores data the bad update changed
  • Assumes roll back to embedded means the most recent good update
  • Expects devices to switch the instant the rollback is published
  • Thinks publishing after a rollback skips devices that went to embedded