Prompt
Design an EAS Update channel strategy with development, staging, and production channels. Write the eas.json configuration that maps branches to channels.
Solution
Channels exist to prevent one specific disaster: an untested JS bundle landing on production users' devices. A channel is baked into the binary at build time — a production build points at the production channel forever. A branch is where you publish updates. The channel→branch mapping is server-side, so "promote to production" is an explicit, auditable act (point the production channel at a tested branch, or republish) rather than a side effect of running the wrong command.
The strategy: one channel per environment, matching build profiles in eas.json. Developers publish freely to development; QA validates on staging builds; only vetted updates reach production. Rollback falls out of the same mechanism — republish the last known-good update and clients pick it as newest.
The safety boundary a senior states unprompted: OTA replaces JS and assets only, gated by runtimeVersion. Any native change rides a store release; an update whose runtime version doesn't match the installed binary is never served, because JS calling native code the binary lacks is an unfixable crash loop.
Red flag: answering "CodePush" as your current OTA tool. CodePush was retired with App Center in 2025 — EAS Update is the current answer, and naming the dead brand dates your production experience.
Say it: "Channels are baked into the binary, branches are where I publish — promotion to production is an explicit server-side mapping, gated by runtimeVersion so an update can never outrun its native code."