void-ota-update-strategy

Decides between EAS Update and EAS Build for shipping Expo app changes.

Updated May 29, 2026
One-click install
npx skills add https://github.com/voidcorp-core/void-harness --skill void-ota-update-strategy-voidcorp-core
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: void-ota-update-strategy
Source: https://github.com/voidcorp-core/void-harness/tree/main/packages/cli/core-assets/packs/pack-mobile/skills/void-ota-update-strategy
Command: npx skills add https://github.com/voidcorp-core/void-harness --skill void-ota-update-strategy-voidcorp-core

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about void-ota-update-strategy

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

FAQPage Schema
How do I decide between EAS Update and EAS Build for an Expo change?

JS-only changes like bug fixes, UI text, and new screens without new native dependencies ship via EAS Update in minutes. Anything touching plugins, iOS or Android config, native modules, or the SDK version requires EAS Build plus store submission.

What runtime version policy should I use with expo-updates?

Use the fingerprint policy, which hashes the SDK, native plugins, and native dependencies so adding native code automatically changes the runtime version. The appVersion and sdkVersion policies are legacy and can silently skip updates when versions are not bumped.

Why is my EAS Update not applying on users' devices?

The update's runtime version likely does not match the installed build's runtime version, so expo-updates silently skips it. This happens when a native dependency or plugin changed; verify with eas update:list and the Updates.updateId value in the app.

How do I roll back a broken OTA update in Expo?

Publish a new update that reverts the change, since newer updates win and there is no delete. For a hard halt, use eas update:republish with a known-good update ID or repoint the production channel to a stable branch with eas channel:edit.

What changes cannot be shipped through an OTA update?

Native code changes, SDK bumps, new permissions, bundle ID or name changes, app icon changes, and splash screen changes cannot go OTA because they live in the pre-built native shell. These all require EAS Build and store submission.