ota-update-strategylisted

# ota-update-strategy Use when planning to ship a change to an Expo app already in users' hands. The fundamental choice: **JS-only change** → EAS Update (minutes); **native change** → EAS Build + store submit (hours/days). Getting this wrong means either users running broken apps or unnecessary store rejections. ## The fundamental rule | Change type | Path | Speed | |---|---|---| | JS bug fix (logic, UI text, layout) | EAS Update | Minutes | | Adding a new screen (no new native dep) | EAS Update | Minutes | | Changing a string in `app.config.ts` env | EAS Update if same plugins | Minutes | | New `expo-X` package added to plugins | EAS Build + submit | Hours + store review days | | Native config changes (Info.plist, permissions) | EAS Build + submit | Hours + store review | | New native module | EAS Build + submit | Hours + store review | | Bump SDK version | EAS Build + submit | Hours + store review | When in doubt: if the change touches `plugins:` or `ios:`/`android:` config in `app.config.ts`, it needs a rebuild. ## Branches and channels (mental model) EAS Update splits the publishing target in two layers: - **Branch** — where you PUBLISH an update (`eas update --branch production`) - **Channel** — what the BUILD reads from (declared in `eas.json` per profile) Builds read from a channel; channels point at branches; you publish to branches. ```jsonc // eas.json "production": { "channel": "production", // ... } ``` This build is on channel `production`. By defau