skip to content

As the lead of a team adopting EAS Update, what would you allow to ship over the air, and which EAS guardrails would you require?

level: principalimportance: should knowfreq 28%

answer

  1. JavaScript and assets only
  2. store build is the floor
  3. percentages before everyone
  4. revert and rollback rehearsed
  5. signing if the threat model says so

basics

~20 s

Allow JavaScript and asset fixes and small flag-guarded features within the current runtime version; send native and large product changes through store builds. Require per-update rollouts, a rehearsed revert and rollback, code signing where tampering matters, and traceable publishes.

solid answer

~50 s

I would draw the line on two axes. **Technically**, only JavaScript and assets can ship over the air, and only to builds with a matching runtime version, so anything touching native code, permissions or the SDK is a store release by construction. **By policy**, I would allow bug fixes, copy and content changes and small, flag-guarded features, and send large behaviour changes through the store where they are reviewed and versioned. The guardrails I would require: every production publish starts as a per-update rollout (`--rollout-percentage`) with a documented widening plan; the team has rehearsed `eas update:revert-update-rollout` and `eas update:rollback` on a staging channel; storage changes stay readable by the previous update so a rollback is safe; and code signing is on if our threat model includes tampering in transit or at the host. There is no single right line; the answer depends on release cadence, risk tolerance and store rules.

go deeper

for a junior

Be able to say that only JavaScript and assets can ship over the air, and that native changes need a store build.

for a middle

Name the EAS tools a policy would lean on: rollout percentages, revert, rollback and code signing.

for a senior

Tie each guardrail to a failure you have seen: a crashing publish, a migration that broke rollback, an unsigned publish path.

for a principal

Pick and defend a line for this specific product, stating which trade-off you accept: speed, review, operational cost or rollback safety.

## Why this is a judgement call **EAS Update** makes publishing JavaScript to production as easy as running `eas update`. That speed is the value, and the risk. A team lead has to decide how much of the product may change without a store build, and what process wraps each publish. There is no single correct policy; a banking app and a conference schedule app should answer differently. ## The hard boundary the tooling already enforces Some of the line is not a choice: - An update carries **JavaScript and assets** only. Native code, new native modules, permission strings and SDK upgrades need a new build. - Updates reach only builds whose **runtime version** matches, so a store build is always the floor your OTA changes sit on. - Store rules about code downloaded after review apply to your app; they belong in the policy, but their details are a separate subject. ## What I would allow over the air | Category | Over the air? | Reasoning | |---|---|---| | Crash and logic fixes in JavaScript | Yes | The core use case: fast repair without review delay | | Copy, images, layout tweaks | Yes | Low risk, easily reverted | | Small features behind a remote flag | Yes, with a rollout | The flag and the rollout are two independent brakes | | Storage or schema migrations | Only if the previous update can still read the data | Otherwise revert and rollback become unsafe | | Large product changes | No, ship in a store build | Reviewability, release notes and version history | | Anything native | Impossible | Needs a new runtime version and build | ## Guardrails built from EAS's own mechanisms 1. **Rollouts by default**: production publishes start with `--rollout-percentage` at a small value and widen with `eas update:edit` against agreed health signals. 2. **A rehearsed undo**: the on-call engineer has run `eas update:revert-update-rollout` and `eas update:rollback` on a staging channel, and knows a revert is a new publish that devices pick up on their next check. 3. **Backwards-readable data**: any update that changes persisted state keeps the previous update able to read it, or rollback is taken off the table for that release. 4. **Code signing where the threat model needs it**: `npx expo-updates codesigning:generate`, the certificate in `updates.codeSigningCertificate`, the private key in a secret store and only CI or named people able to publish. 5. **Traceable publishes**: every `eas update` has a meaningful `--message` and runs from a pipeline tied to a commit, so the update list reads as a changelog. ## A sample policy, written down A concrete version for a mid-sized consumer app might read: - **Allowed over the air**: JavaScript fixes, copy and asset changes, and features behind a remote flag that defaults to off. - **Store build only**: anything native, SDK upgrades, changes to onboarding or payments, and storage migrations that older code cannot read. - **Every production publish**: from CI, tied to a commit, with a `--message`, starting at a rollout percentage agreed per risk class. - **Widening**: after a fixed soak time and a comparison of failed installs and crash rate against the control update. - **Undo**: revert first and investigate second; any engineer on call may revert without approval. - **Review**: the policy is revisited whenever an incident shows a gap. ## Trade-offs to state out loud - **Speed versus review**: the tighter the gate, the more an OTA fix resembles a store release in latency. - **Rollout size versus signal**: 1% of a small user base may be too few sessions to show a crash rate; 10% of a large one may be too many users hurt. - **Signing versus operations**: signing adds key custody, rotation and new runtime versions on every rotation. - **Embedded freshness**: the longer a store build lives, the older a rollback to embedded becomes, which argues for regular store releases even when OTA could carry everything. A good answer names the constraints of the specific app, then picks a line and the mechanisms that enforce it.

  • How would your policy change for an app that stores medical or payment data?
    I would turn on code signing with the key held by the release pipeline only, cap first rollouts lower, require a second reviewer for production publishes and keep storage migrations out of over-the-air releases entirely, so a rollback is always safe. Larger behaviour changes would wait for a store build.
  • Why does a long-lived store build weaken your rollback options?
    Rolling back to embedded returns users to the bundle compiled into their binary. If that build is months old, it lacks every fix shipped over the air since, and may not read data later updates wrote, so a rollback to embedded becomes a regression in itself. Regular store builds keep that fallback fresh.

saying these in an interview costs you the question

  • Says anything can ship over the air if it is tested
  • Treats rollouts as optional for production publishes
  • Assumes rollback is always safe regardless of stored data
  • Lets any developer publish to production from a laptop