An Expo update must be compatible with the native code in the installed app that receives it. A JavaScript change can work in a developer's new build and still fail for users whose older binary lacks the required native capability.
Expo's runtime-version documentation explains the relationship between the native build and the update layer. Treat runtime compatibility as a release boundary, not as a version string to reuse automatically.
List the audience before the change
Identify which installed builds may receive the update, on which platforms and through which channels. A successful preview on one recent device does not establish compatibility with every supported binary.
Record the runtime policy used by the project and how it changes when native dependencies change. If the policy relies on a manually maintained version, make that maintenance an explicit review step.
Keep application version, runtime version and content revision distinct in release notes and internal records.
Classify the candidate update
Separate copy or application-logic changes from additions that require native code. A newly imported library may introduce a native dependency even when the visible change looks small.
Inspect configuration and dependency diffs alongside JavaScript. The relevant question is what the installed binary must already contain for the update to run.
Do not assume that an update service can add an absent native capability to an existing binary.
Use a representative companion workflow
Pokopedia describes an unofficial game companion with bundled reference content and progress tracking. It appears in the Expo catalogue, but the listing does not disclose its update configuration.
For an independently developed companion app, an update might alter a search screen, add a native feature or change stored progress. These are different compatibility problems and should have separate acceptance criteria.
Preserve the distinction between updating reference content and migrating the user's own records.
Test the update on the intended runtime
Create or use a preview build with the same native runtime as the production audience and a separate update channel. Apply the candidate update there and complete a representative task.
Include a previously installed build with existing synthetic data. A fresh installation can hide assumptions about migrations or previously cached assets.
Record the native artifact, runtime, update identifier and platform. This evidence is more useful than a statement that the latest development build opened successfully.
Plan observation and rollback
Define which errors would stop promotion or trigger rollback. A gradual rollout can provide a bounded observation window, but only if someone monitors the relevant signals and can identify the affected update.
Check data compatibility before promising rollback. An older update may not understand records written by the newer one. Keep migrations compatible with the recovery plan wherever possible.
The Expo offline-progress guide examines those records in more detail. Together, runtime and data compatibility help preserve the user's working app while the product evolves.
A release should be identifiable after installation as well. Provide a support-visible version reference that lets an operator connect a reported problem to the native build and update, without asking the user to understand the implementation.
Stardew Valley Tracker
IcyZip
Xeramail Temp Mail