Ship OTA Updates with Confidence

Bundle Drop is an over-the-air update platform for React Native that lets you ship JavaScript and bundled asset changes without submitting a new App Store or Play Store build every time.

It is designed for teams that want faster fixes, channel-based release tracks, staged rollouts, rollback safety, and a clean separation between native app releases and OTA-delivered JS changes.

Read more in the docs: Introduction, Channels, and Staged Rollouts.

You install the Bundle Drop SDK in your React Native app, connect the app to a Bundle Drop project with bundle.drop.config.js, and upload bundles to a specific channel such as General, Beta, or QA.

At runtime, the app checks its active channel for a compatible update. If a matching bundle exists for the installed native binary, it can be downloaded and applied immediately or on the next launch depending on your update policy.

Read more in the docs: Introduction, Installation, SDK Integration, and Update Policies.

Create a project, install the package in your React Native app, and log in with the CLI. Login generates the project config and launches the project-aware setup for Expo or bare React Native.

Then upload your first bundle to a channel and let the app check for compatible updates at runtime. For most teams that is the whole path from install to a first OTA publish.

Read more in the docs: Installation, Project Creation, CLI, and Uploading.

Yes. Microsoft retired App Center CodePush, and Bundle Drop is a drop-in replacement for OTA updates. CodePush deployment keys map to channels, codePush.sync() maps to update policies, and rollback and staged rollouts are built in.

The CLI detects an existing CodePush setup, previews the matching Bundle Drop integration, and gives you a short cleanup checklist. It preserves the host and app delegate structure already used by the project.

Read more in the docs: Migrate from CodePush, Installation, and Channels.

Bundle Drop supports Expo SDK 54–57 and bare React Native 0.71+ on iOS and Android, with both React Native architectures.

Expo projects use the Bundle Drop config plugin and an Expo-preserving Metro wrapper across managed/CNG, prebuild, and EAS workflows. Bare projects use autolinking and project-aware native setup.

Read more in the docs: Installation, Expo, and SDK Integration.

Bundle Drop supports React Native apps on iOS and Android. Updates are resolved per platform, and the system only delivers bundles that match both the target platform and the installed runtime version.

That means older binaries can stay on the last compatible OTA line while newer native releases move onto their own runtime boundary safely.

Read more in the docs: Installation, Runtime Version, and SDK Integration.

JavaScript and bundled assets, which is the part of your app that ships inside the JS bundle. That covers UI changes, logic fixes, copy updates, and bundled images.

Native code changes, such as new native modules, updated native dependencies, or permission changes, still require a normal store release. When native code changes you move to a new runtime version so OTA updates stay compatible with the binary your users already have.

Read more in the docs: Introduction and Runtime Version.

No for JavaScript and bundled asset changes. That is the main benefit of OTA delivery: you can ship compatible JS updates without waiting on another store review cycle.

You still need a normal store release when native code changes. In that case, you should ship a new app binary and move that binary line to a new runtime version so OTA updates stay compatible.

Read more in the docs: Introduction, Runtime Version, and Uploading.

Not for the kind of updates Bundle Drop delivers. Shipping JavaScript and asset updates to an interpreted runtime is an established, widely used pattern on both stores, and it is how React Native OTA has worked for years.

The expectation is that OTA updates improve or fix your existing app rather than change its core purpose, and that you never ship native code this way. Bundle Drop is designed around exactly that boundary: JS and assets over the air, native changes through a normal release. You remain responsible for following the current store guidelines for your app.

Read more in the docs: Introduction and Runtime Version.

Channels are named update streams inside a project. Your app checks a specific channel for updates, and each upload is published to a specific channel as well.

Teams typically use channels to separate production, beta, QA, internal testing, or feature-specific release tracks. That lets you test on one track without affecting the others, and you can promote a proven bundle forward instead of re-uploading it.

Read more in the docs: Channels, Production Channels, and Staged Rollouts.

A production channel is the one channel in a project that represents your real-user release path. Only one production channel can be set per project at a time.

It mainly exists to control retention more deliberately. Without a production channel, bundles follow the default 30-day retention behavior. When a channel is marked as production, new bundles uploaded or promoted into it can follow longer retention policies such as 90 days, 180 days, or never expiring automatically.

Read more in the docs: Production Channels, Channels, and Rollback.

Targeted rollout lets you limit a release to users who match specific user property rules such as plan tier, country, or role. It works alongside staged rollout rather than replacing it.

In practice, Bundle Drop first applies the targeting rules to find the eligible audience, then applies the rollout percentage to that matched group. Managed publishing still acts as the channel-level gate behind the scenes.

Read more in the docs: Targeted Rollout, Staged Rollouts, and Managed Publishing.

Yes. Rollback moves users off a problematic OTA bundle and back to the previous working version for that channel.

This is not a separate reverse update that you have to build and publish. If there is no previous OTA bundle to return to, Bundle Drop can fall back to the native bundle that shipped with the app binary.

Read more in the docs: Rollback, Staged Rollouts, and Channels.

Bundle Drop includes automatic crash protection on the device. If a new OTA update keeps failing before it can be marked healthy at startup, the SDK automatically rolls back to the last known good bundle — or to the original native bundle if there isn't a previous OTA version.

The failed bundle is remembered and blocked on that device so it is not retried, while other devices are unaffected. You can tune the threshold with maxCrashCount, or switch to manual health reporting once your app reaches a known-good startup point.

Read more in the docs: Rollback and Update Policies.

Bundles are served over HTTPS through signed, time-limited download links rather than public URLs, and the SDK verifies each bundle before applying it. If a download is incomplete or fails verification, the app keeps running the version it already has instead of applying a broken update.

Combined with rollback, that means a bad or tampered update should not leave your users stuck on a broken build.

Read more in the docs: Rollback and Installation.

Yes. Bundle Drop supports automated publishing flows through the CLI. In local development you normally use interactive login, but in CI you pass a Personal Access Token with --token.

That makes it straightforward to upload from GitHub Actions, GitLab CI, Bitrise, or any other pipeline that can securely provide a token from its secret store.

Read more in the docs: CI/CD, CLI, and Uploading.

Yes. Bundle Drop has a free plan that is suitable for hobby projects, small teams, and early validation before you need larger rollout capacity.

If you want the latest plan limits, device allowances, or upgrade options, check the pricing page directly because those details can change over time.

See Pricing, and if you are evaluating the workflow itself start with the docs.