Documentation

React Native OTA update guide

Learn how React Native OTA updates work, what requires a native build, and how to test differential delivery, staged rollout and recovery.

Updated 2026-09-15

On this page

What is a React Native OTA update?

A React Native over-the-air (OTA) update delivers JavaScript and bundled assets to an already installed app. The installed native runtime must be able to run that update. Pakta uses the rn-update SDK and pakta CLI to publish these updates to Android, iOS and HarmonyOS apps, including native Expo builds on Android and iOS.

For example, changing a screen label can fit an OTA release. Adding a native camera module requires a new native build first. OTA delivery does not replace native releases or store requirements.

Which changes can ship over the air?

ChangeDelivery pathCheck before publishing
JavaScript bug fix or screen copyOTA candidateUses only native APIs already in the installed app
Bundled images or stylesOTA candidateAssets are included and render in a Release build
Native library, permission or Config Plugin changeNew native buildRebuild, distribute and register the new baseline
React Native, Expo SDK or Hermes upgradePlan a new native buildValidate the resulting native runtime and bundle together
Distribution channel identityNew Pakta native buildThe channel is embedded in the installer

Expo describes the same underlying native/update boundary through runtime versions. Pakta uses its own native-package targeting and compatibility checks; Expo runtimeVersion is not a Pakta deployment parameter.

How does Pakta deliver an update?

  1. Integrate rn-update into the app and produce a Release installer.

  2. Register the exact installed native package as the update baseline.

  3. Build a .ppk containing compatible JavaScript and assets with the CLI.

  4. Publish it to the intended application, channel and native version.

  5. The app checks eligibility, downloads an update, then activates it according to the configured strategy.

  6. Observe download, activation and health events before increasing the rollout.

Differential delivery can reduce downloaded bytes when a useful patch is available; a full package remains the fallback. Savings depend on the baseline and changed content. See the first-release walkthrough and production checklist.

Which OTA approach fits your app?

Starting pointEvaluateFirst decision
An existing EAS Update workflowEAS Update and its runtime/channel modelIs changing the OTA client necessary?
An app using Microsoft CodePushStandalone CodePush or a replacement SDKMust you preserve the existing client protocol?
A React Native or native Expo app evaluating Paktarn-update and Pakta release managementCan you ship a new native build and validate compatibility?
A HarmonyOS React Native appPakta's HarmonyOS integrationVerify the native toolchain and a signed device build

Read the Expo Updates comparison or CodePush migration guide before selecting an integration. Compare actual runtime support, recovery behavior and operational responsibilities, then test your own app.

How should you test OTA updates?

Use a real Release build with Metro disconnected. Change one visible label, publish to an internal channel, check for an update and activate it using your chosen strategy. Confirm the expected update hash and version, then test offline startup and recovery. A development reload alone does not verify OTA delivery.

Start production with a small rollout, watch version health, and retain a compatible stable package. Cancelling a deployment prevents further distribution; it does not uninstall updates already running on devices.

Can OTA replace an app-store release?

It can deliver compatible JavaScript and asset changes to a prepared native app. It cannot add missing native code, install the OTA SDK into an old binary or move that binary to a new native runtime. Review the store-release checklist before distribution.

Ready to try it? Follow Quick start, then Expo setup or native integration.