Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Release an Expo app and its Cloudflare Worker as two coordinated deployables: approve the signed native binary and its compatible JavaScript update path, then independently verify the Worker deployment and its runtime assumptions. Whether a change needs a new app build or can ship over the air depends on native changes and runtime compatibility—not simply on whether the JavaScript works in development.

Start by pinning down what you are releasing

Before building or publishing, record the exact inputs for this release. SDK 57 is a framework version, not a release checklist: the project’s installed Expo patch and dependencies determine which fixes and upgrade steps apply.

  • App commit and lockfile, plus the installed Expo SDK patch version.
  • Whether native iOS and Android projects are generated with Continuous Native Generation (CNG) or maintained directly.
  • EAS build profile, target platforms, app version, and runtime-version strategy.
  • Intended store track or release state, and the OTA channel and environment mapping.
  • Worker commit, deployment environment, configuration, and the API routes the app depends on.

Expo announced SDK 57 on June 30, 2026. It upgrades React Native from 0.85 to 0.86 and keeps React 19.2. Expo says React Native 0.86 is intended to have no breaking changes from 0.85, but still advises reviewing the React Native release notes and Expo’s full changelog before upgrading: Expo SDK 57 release notes.

Check SDK 57 patch-level fixes

Confirm the project’s exact Expo patch and relevant dependencies before treating a documented issue as applicable. Expo says expo@57.0.9 updates React Native to 0.86.2 and resolves a Hermes V1 memory regression affecting apps that import react-native-worklets or react-native-reanimated. This does not establish that every app using those packages experiences the regression. Expo says expo@57.0.17 updates React Native to 0.86.3 and resolves a development startup-time regression, which it says does not affect production apps. Do not treat an unsupported experimental worklets bundle mode as a production workaround.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Regenerate or update native projects appropriately

SDK 57 changes how expo prebuild handles existing native directories: by default it clears and regenerates android and ios; use --no-clean to apply changes to existing folders. For CNG projects, follow Expo’s upgrade checklist for regenerating native folders. For projects that maintain native directories, apply relevant native changes and run pod install. Align dependencies, check Expo Doctor and the full changelog, and create a new development build if the project uses expo-dev-client.

Choose between a new build and an OTA update

A store-submitted binary and an over-the-air (OTA) update serve different release needs. Expo’s production workflow fingerprints native project characteristics, reuses a matching build where possible, and otherwise creates and submits one; when a new native build is unnecessary, it can publish an OTA update. Treat that as a decision model, not proof that any particular change qualifies: verify the project’s runtime-version configuration and the installed binaries targeted by the update. See Expo’s production workflow and runtime versions.

Delivery path Use it when Gate checks
New native build and store submission A native code or configuration change requires a new binary, or no suitable build exists for the native fingerprint. Platform coverage, build profile and signing, binary validation, intended store track, and any store review steps.
OTA update to installed builds The change is eligible for an update and the installed binary’s runtime is compatible. Target runtime versions, channel mapping, staging parity, and a defined promotion or rollback procedure.

These paths are complementary over an app’s release lifecycle, not interchangeable for every change. If the change requires native capabilities absent from an installed binary, an OTA bundle cannot supply them; plan a new build and submission.

Gate the binary and store release separately

EAS Submit transfers signed Android .aab or iOS .ipa binaries to store services. A successful upload is not the same as a completed store release. Expo’s EAS Submit guide describes the upload workflow; track selection and subsequent store work remain part of the gate.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Android

Confirm the upload is going to the intended Google Play track. For a new app, Expo says the default submission is to internal testing. Listing details and promotion through the intended release stages still need completion; record the target track and verify the resulting state in Play Console.

iOS

An uploaded build becomes available in TestFlight after processing, but that is not an automatic App Store production release. Complete App Store Connect metadata and screenshots, select the build, and submit it for App Review as appropriate. Track upload, TestFlight availability, review status, and production release as distinct states.

Stage and promote OTA updates against production conditions

Validate an update against a staging build using the same runtime as production, then confirm the production channel targets the compatible runtime versions. Expo’s EAS Update deployment guide describes staging through a store beta track or internal distribution.

  1. Install the staging build and verify its runtime version and channel.
  2. Test the update on that build, including the app’s critical flows and any configuration-dependent behavior.
  3. Before promotion, compare staging and production channel, environment-variable, and signing configuration with the intended release setup.
  4. Where using Expo’s promotion flow, promote the same tested commit with matching environment variables and signing configuration. Republishing a verified bundle can preserve the exact tested code.

Define in advance which installed runtime versions the update should reach. An update that passes on one staging binary is not evidence that it is compatible with every installed production runtime.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Validate the Worker as a separate runtime and deployment

Do not assume that code or packages working in Node.js will work unchanged in Cloudflare Workers. EAS Hosting’s runtime reference says it is built on Cloudflare Workers: requests run in V8 isolates rather than full JavaScript processes, and many familiar Node.js APIs are not directly available. Compatibility modules cover some needs, but support depends on the API and project configuration. See Expo’s Worker runtime reference.

Test the deployed Worker—or a production-equivalent deployment—not just a local Node.js process. Include the app’s critical API calls and check authentication, configuration, error handling, and dependencies used by the routes. Verify the project’s required compatibility settings, bindings, and secrets in its actual deployment environment. The correct flags, deployment command, and rollback process are specific to the Worker project.

Make the release gate explicit

Vendor documentation provides the general build, submission, update, and runtime workflows, but it cannot set your team’s operational policy. Put the project-specific decisions in the release record so that approval is actionable:

  • Which automated test suites and manual checks must pass for the app and Worker.
  • Which store track, audience, OTA channel, and runtime versions are in scope.
  • Required staging evidence and the conditions for promoting an update or binary.
  • Required Worker endpoint smoke tests, configuration checks, and secrets validation.
  • Rollout percentage, monitoring signals and window, rollback trigger, and named rollback owner.

Set these thresholds to fit the app’s risk and release process; there is no universal rollout percentage or monitoring window established by the general platform workflow.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.