eas-ota-discipline

Validates Expo EAS Update publishes against the runtimeVersion fingerprint rule.

Updated Aug 21, 2026
One-click install
npx skills add https://github.com/allen-hsu/mobile-shipkit --skill eas-ota-discipline-allen-hsu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eas-ota-discipline
Source: https://github.com/allen-hsu/mobile-shipkit/tree/main/skills/eas-ota-discipline
Command: npx skills add https://github.com/allen-hsu/mobile-shipkit --skill eas-ota-discipline-allen-hsu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Expo OTA updates silently fail to reach users when the update's runtimeVersion fingerprint does not match the installed builds, and eas update gives no warning. This Skill enforces a publish-and-verify discipline so updates actually arrive on devices. ## Core Features & Use Cases - Fingerprint verification: Compares eas update:list against eas build:list after every publish to confirm the runtimeVersion values match exactly. - Fingerprint-breaking change list: Identifies which changes (native packages, SDK upgrades, app.json native config, stray ios/android directories) require a new binary instead of an OTA. - Channel-branch-profile mapping: Provides the standard eas.json triple (development/preview/production) and matching app.json configuration with the fingerprint runtimeVersion policy. - Use Case: A tester reports an update never arrived. Run the section 2 comparison, discover the fingerprint mismatch caused by a newly added native package, and cut a new binary instead of republishing OTA. ## Quick Start Ask the agent to publish the current change with eas update to the production branch and verify the runtimeVersion matches the latest build.

Frequently Asked Questions about eas-ota-discipline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why did my EAS update publish but users never received it?

The update's runtimeVersion fingerprint does not match the installed builds, so delivery silently fails. Compare `eas update:list` with `eas build:list` immediately after publishing; the runtimeVersion values must match exactly.

How do I check the runtimeVersion fingerprint before publishing an OTA update?

Run `npx expo-updates fingerprint:generate` locally and compare the result with the latest build's runtimeVersion from `eas build:list`. If they differ, your native layer has changed and the OTA will not reach anyone.

Which changes require a new binary instead of an EAS OTA update?

Adding native packages, upgrading Expo SDK or React Native, editing native app.json config (icon, name, splash, permissions), unpatchaged node_modules edits, and stray ios/ or android/ directories all break the fingerprint and require a rebuild.

How long does an EAS OTA update take to apply on user devices?

An update takes effect on the second cold start: the first launch downloads it and the second applies it. Icon, name, and splash never update via OTA because they are part of the installed package.

How should channel, branch, and build profile be configured in eas.json?

Bind one channel per build profile (development, preview, production) and let the channel map to the same-named branch by default. Publish with `eas update --branch <name> --environment <name>` using matching names, and verify with `eas channel:view`.