skip to content

Channels & Branches

1 roadmap5 questions

EAS Update publishes a bundle to a branch, and each build's channel points at one branch, so remapping a channel promotes updates without a rebuild. Interviewers ask how staging becomes production.

part ofExpo (React Native)overview, primer and where to startread it →
on this pageshow

explore

questions

5

With EAS Update, how do you ship a typo fix to production over the air, and what do --channel, --branch and --message do?

level: juniorimportance: must knowfreq 50%

answer

  1. JavaScript and assets only
  2. --channel follows the current mapping
  3. --branch writes to a named branch
  4. --message labels the update
  5. --environment on SDK 55 and later

basics

~20 s

Fix the text, then run eas update --channel production --environment production --message "Fix typo". EAS bundles the JavaScript, uploads it to the branch production points at, and compatible production builds download it on a later launch.

solid answer

~40 s

A typo is JavaScript, so it can ship over the air; anything touching native code cannot. After fixing it, run `eas update --channel production --environment production --message "Fix checkout typo"`. `eas update` bundles the app (all platforms by default) and uploads an update group. `--channel production` publishes to **whichever branch the production channel points at**, creating and linking a same-name branch if needed. `--branch <name>` instead writes to that branch regardless of mapping, so it reaches users only if a channel follows it. `--message` (`-m`) labels the update in history; `--auto` fills branch and message from the current Git branch and last commit. On SDK 55 and later, `--environment` selects the EAS environment variables used to bundle. Production builds with the same runtime version pick it up on a later launch.

code

bash · 5 lines
bash
# publish the fix to whatever branch the production channel follows
eas update --channel production --environment production --message "Fix typo on checkout screen"

# check what production builds will now receive
eas channel:view production

go deeper

for a junior

Recall that JavaScript and asset fixes can ship over the air with eas update, while native changes need a new build.

for a middle

Explain how --channel resolves to a branch, why --branch can publish to a branch nobody follows, and what --message and --environment add.

for a senior

Show a disciplined hotfix path: same environment as the build, staging first, then promote the tested update rather than re-exporting.

for a principal

Decide what the team allows over the air without review, who may publish to production, and how hotfixes are recorded.

## What can ship over the air **EAS Update** replaces the **update layer** of an app: the JavaScript bundle and the assets it references. A typo in a `<Text>` string, a wrong colour or a logic bug in a component all live there. Anything in the **native layer** — a new native module, a permission, an SDK upgrade, a change to app config that prebuild turns into native code — needs a new binary. The typo fix is the textbook OTA case. ## Publishing the fix The command: ```bash eas update --channel production --environment production --message "Fix typo on checkout screen" ``` What happens: 1. EAS CLI **exports** the project with the bundler into the `dist` directory, by default for all platforms (`--platform android` or `ios` narrows it). 2. It uploads the bundle and assets as an **update group** — one update per platform — with the **runtime version** from app config. 3. The group becomes the newest update on the target **branch**. 4. Builds whose channel follows that branch, with a matching runtime version and platform, get it the next time `expo-updates` checks, which by default is at launch. ## --channel versus --branch | Flag | Where the update goes | Typical use | |---|---|---| | `--channel production` | the branch the `production` channel currently points at | hotfixes when you think in channels | | `--branch production` | the branch named `production`, whatever points at it | branch-based flows, previews, version branches | | `--auto` | branch = current Git branch, message = last commit | Git-driven automation | Details worth knowing: - `--channel` looks the mapping up on the server. If the channel does not exist, or exists without a branch, EAS CLI creates a branch with the channel's name and links it. - If the channel is mid-rollout between two branches, `--channel` refuses and asks for `--branch`. - `--branch` never changes any mapping. Publishing to a branch no channel follows is safe for testing and invisible to users. - You cannot pass both `--channel` and `--branch`. ## --message and --environment - **`--message`** (`-m`) is a short description stored with the update and shown by `eas branch:view`, `eas update:view` and the dashboard. In `--non-interactive` mode EAS CLI requires `--message` together with `--branch` or `--channel`, unless `--auto` supplies both. - **`--environment`** names the EAS environment (`production`, `preview`, `development`) whose server-side environment variables are used while bundling. EAS CLI's help marks it as required for projects on Expo SDK 55 or later, which includes SDK 57. Use the same environment the production build used, so values baked into the bundle match. ## When users see it The update is available at once, but users see it only after the app downloads it. With default settings, `expo-updates` checks on launch; if the download finishes quickly the new bundle runs, otherwise it runs on the following launch. A typo fix therefore reaches most active users within a launch or two, without a store review. ## Recording and checking the hotfix - Write a message someone can search later, such as the ticket and screen; `eas branch:view` and the dashboard show it next to the runtime version. - In CI, `--auto` uses the current Git branch as the EAS branch and the last commit message as the message, which ties updates to commits without extra flags. - Publish for one platform with `--platform ios` or `--platform android` only when the fix really is platform-specific; otherwise the default of all platforms keeps both apps in step. - After publishing, `eas channel:view production` confirms which branch production follows and which update is now newest on it. ## A safer variant If the team has a staging build with the same runtime version, publish the fix to `--channel staging` first, verify it, then promote the **same** update to production with `eas update:republish --destination-channel production`, so production receives exactly the bundle that was tested rather than a fresh export. ## Common mistakes - Publishing with `--branch fix-typo` and wondering why nobody got it: no channel follows that branch. - Expecting the update on an older store version whose runtime version differs. - Shipping a change that also needs native code, and crashing on old binaries — the runtime version exists to prevent exactly that.

  • Why would eas update --channel production fail with a message telling you to use --branch?
    The production channel is currently mapped to two branches because a branch-based rollout is in progress. EAS CLI cannot tell which branch to publish to, so it asks for an explicit `--branch`.
  • Which parts of a fix mean it cannot ship as an EAS Update?
    Anything in the native layer: adding or upgrading a native module, changing permissions or entitlements, or config that prebuild turns into native code. Those need a new build with a new runtime version; EAS Update only replaces JavaScript and assets.

saying these in an interview costs you the question

  • eas update --branch hotfix reaches production users automatically
  • An OTA update can add a new native module
  • --message chooses which builds receive the update
  • Publishing requires a store review before users receive it
  • --channel and --branch can be combined to target both
open as a page

In EAS Update, what is the difference between a channel and a branch, and how does an installed build decide which update to run?

level: middleimportance: must knowfreq 55%

basics

~20 s

A channel is a name compiled into a build; a branch is an ordered list of published updates. Each channel points at a branch, and a build runs that branch's newest update matching its runtime version and platform.

open as a page

In EAS Update, how do you promote an update tested on staging to production, and when would you use eas channel:edit versus eas update:republish?

level: middleimportance: should knowfreq 40%

basics

~10 s

Either repoint the production channel at the tested branch with eas channel:edit, or copy the tested update group onto production's branch with eas update:republish --destination-channel production. Both reuse the tested bundle without rebuilding.

open as a page

An EAS Update hotfix published from CI makes production builds call the staging API; what does eas update's --environment flag change, and how do you prevent this?

level: seniorimportance: should knowfreq 30%

basics

~20 s

An API URL read at bundle time is baked into the update. --environment production makes eas update bundle with that EAS environment's variables and ignore local .env files; a CI job without it uses the runner's values.

open as a page

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%

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.

open as a page