# 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.

## What is a React Native OTA update? {#what-is-ota}

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? {#compatibility}

| Change | Delivery path | Check before publishing |
| --- | --- | --- |
| JavaScript bug fix or screen copy | OTA candidate | Uses only native APIs already in the installed app |
| Bundled images or styles | OTA candidate | Assets are included and render in a Release build |
| Native library, permission or Config Plugin change | New native build | Rebuild, distribute and register the new baseline |
| React Native, Expo SDK or Hermes upgrade | Plan a new native build | Validate the resulting native runtime and bundle together |
| Distribution channel identity | New Pakta native build | The channel is embedded in the installer |

Expo describes the same underlying native/update boundary through [runtime versions](https://docs.expo.dev/eas-update/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? {#delivery}

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](/docs/publish) and [production checklist](/docs/bestpractice).

## Which OTA approach fits your app? {#choose}

| Starting point | Evaluate | First decision |
| --- | --- | --- |
| An existing EAS Update workflow | EAS Update and its runtime/channel model | Is changing the OTA client necessary? |
| An app using Microsoft CodePush | Standalone CodePush or a replacement SDK | Must you preserve the existing client protocol? |
| A React Native or native Expo app evaluating Pakta | `rn-update` and Pakta release management | Can you ship a new native build and validate compatibility? |
| A HarmonyOS React Native app | Pakta's HarmonyOS integration | Verify the native toolchain and a signed device build |

Read the [Expo Updates comparison](/docs/expo-updates-vs-pakta) or [CodePush migration guide](/docs/codepush-alternative) before selecting an integration. Compare actual runtime support, recovery behavior and operational responsibilities, then test your own app.

## How should you test OTA updates? {#verify}

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](/docs/channels), watch [version health](/docs/analytics), 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? {#native-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](/docs/bestpractice#store-review) before distribution.

Ready to try it? Follow [Quick start](/docs/introduction), then [Expo setup](/docs/expo) or [native integration](/docs/getting-started).