skip to content

How do you preview a published EAS Update inside an Expo development build before any production channel points at it?

level: middleimportance: nice to knowfreq 25%

answer

  1. publish to an unlinked branch
  2. expo-updates in the development build
  3. Extensions tab, then Login
  4. open an update from its branch
  5. runtime version must still match

basics

~20 s

Publish the change to a branch no production channel follows, then open a development build that includes expo-updates, sign in on its Extensions tab and open the update from that branch; it must match the build's runtime version.

solid answer

~40 s

Publish to a branch nobody's builds follow, for example `eas update --branch fix-typo --message "Preview typo fix"`; with no channel linked to it, users cannot receive it. A **development build** made with `expo-dev-client` that also includes `expo-updates` can load any compatible update: open its **Extensions** tab, tap **Login** to sign in to the Expo account, and the EAS Update section lists recent updates by branch; tap **Open** on the one to preview. The update still has to match the development build's **runtime version** and platform, so the development build must be built from the same native state as production. Once it looks right, promote it by repointing a channel or republishing it to production's branch.

code

bash · 5 lines
bash
# publish somewhere no user's build follows
eas update --branch fix-typo --environment production --message "Preview typo fix"

# after approval, copy it to production's branch
eas update:republish --branch fix-typo --destination-channel production

go deeper

for a junior

Recall that you can publish to a branch nobody follows and open that update in a development build to check it.

for a middle

Explain the steps: expo-updates in the development build, Extensions tab login, opening the update, and the runtime version match.

for a senior

Build a preview practice around it: private branches per fix, development builds kept in step with production's native state, then promotion by republish.

for a principal

Decide how previews fit the release process, from pull-request previews to a persistent staging channel, and who signs off before promotion.

## The goal Before a fix reaches production, someone wants to see the **exact published update** running, not a local dev server. EAS Update supports this without touching production, because an update reaches users only through a **channel**, and a **branch** that no channel follows is invisible to them. ## Step 1: publish to a private branch ```bash eas update --branch fix-typo --environment production --message "Preview typo fix" ``` - `--branch fix-typo` creates or appends to that branch on EAS. - No channel points at `fix-typo`, so no installed build downloads it. - The update is otherwise real: bundled, uploaded, with a runtime version and a message. ## Step 2: open it in a development build A **development build** is a debug build of your own app that includes `expo-dev-client`. For previewing updates it must also include `expo-updates`. Then: 1. Open the development build and go to the **Extensions** tab. 2. Tap **Login** and sign in to the Expo account that owns the project; this is what lets the tab list the project's updates. 3. In the **EAS Update** section, find the recent update or tap the branch name to see all its updates. 4. Tap **Open** next to the update to load it. The development build then runs the published bundle instead of connecting to a local dev server. ## What must match | Requirement | Why | |---|---| | `expo-updates` in the development build | the Extensions integration depends on it | | same **runtime version** | the update's JavaScript expects the native layer it was built for | | same **platform** | Android and iOS updates are separate members of the update group | | signed-in Expo account with access to the project | the list of updates is fetched for that account | A development build made months ago with different native modules has a different runtime version and will not be offered updates built for today's production binary. Rebuild it when native code changes. ## Other ways to preview - **Preview builds on their own channel.** An internal-distribution build on a `preview` channel receives whatever is published there; useful for testers who should not use a development build. - **Per-feature channels.** Builds can be made with channels such as `preview-feature-a`, so several previews coexist. - **Runtime overrides.** `Updates.setUpdateRequestHeadersOverride({ 'expo-channel-name': 'preview' })` can point a build at another channel at runtime; Expo marks it experimental and asks you to weigh the security considerations before using it outside internal builds. ## Previews from pull requests Teams often automate the private-branch step: a CI job on each pull request runs `eas update --auto`, which uses the Git branch name as the EAS branch and the last commit message as the update message. Every pull request then has its own EAS branch, reviewers open its update in their development builds, and nothing reaches users because no channel follows those branches. Expo documents this pattern with GitHub Actions; the key design point is only that preview branches are never linked to a production channel. ## From preview to production When the preview is approved, it reaches production through the same mechanisms as any tested update: 1. `eas channel:edit production --branch fix-typo` makes production follow the branch. 2. Or `eas update:republish --branch fix-typo --destination-channel production` copies that update onto production's branch. For a one-off hotfix, republishing is usually the tidier choice, because production keeps following its long-lived branch. ## Pitfalls - Opening the update in **Expo Go** instead of a development build: previewing your own updates this way needs your development build with `expo-updates`. - Forgetting to sign in on the Extensions tab, so no updates are listed. - Previewing an update exported with a different `--environment` from the one production will use.

  • Why is publishing to a branch with no linked channel safe for previews?
    Builds request updates by channel, and the server serves only branches linked to that channel. A branch nothing points at is never served to installed builds; only a development build told to open it explicitly will load it.
  • A tester's development build shows no updates in the Extensions tab; what do you check?
    That the development build includes `expo-updates`, that the tester signed in with an account that has access to the project, and that the published update's runtime version and platform match the development build.

saying these in an interview costs you the question

  • Any published update reaches production users immediately
  • A development build can run updates for any runtime version
  • Previewing requires publishing to the production channel first
  • The Extensions tab works without signing in to Expo
  • A preview needs a new store build for each update