OTA update (EAS Update)

The production flow Expo recommends: eas update --channel staging on a test build, verification, then eas update:republish --destination-channel production to promote the exact same bundle, or eas update --channel production if environment variables differ. --rollout-percentage enables a gradual rollout, eas update:rollback returns to the previous update or to the one embedded in the binary. App-side behavior is set in app.json (updates.checkAutomatically, fallbackToCacheTimeout) and through the Updates API (checkForUpdateAsync, fetchUpdateAsync, reloadAsync) for teams that want to offer a reload instead of waiting for the next cold start.

Pitfall number one is the incompatible update: JavaScript calling a native module absent from the installed binary. The runtime version exists for that, and the fingerprint policy computes it from the actual native code. Number two: publishing an update from a dev machine with staging EXPO_PUBLIC_* variables. Number three: forgetting that the stores have rules; an update that changes app behavior beyond a fix is still subject to their terms.

In an audit I look at eas update:list --branch production, the channel-to-branch mapping (eas channel:list), and whether crashes carry an update identifier in the monitoring tool, otherwise nobody knows which code is actually running on users’ phones.