What problem does it solve? Shipping a change to an Expo app already in users' hands forces a choice: push a JS-only update over the air in minutes, or rebuild the native binary and resubmit to the stores over days. Choosing wrong means silently skipped updates, broken apps, or unnecessary store rejections. ## Core Features & Use Cases - Change-type decision table: Maps each change (JS fix, new screen, new native dependency, SDK bump, permission change) to either EAS Update or EAS Build plus store submission. - Runtime version guidance: Explains the fingerprint, appVersion, and sdkVersion policies and why fingerprint prevents silently skipped updates. - Channels, branches, and rollback: Covers publishing to branches, repointing channels, republishing known-good updates, and testing updates on production-channel builds. - Use Case: You added a new expo package to your plugins and want to push a quick OTA fix. The skill flags that plugin changes alter the runtime fingerprint, so old builds will ignore the update and a full EAS Build plus store submission is required. ## Quick Start Ask the assistant whether your planned Expo app change can ship as an EAS Update or requires a full rebuild and store submission.