Ship OTA Updates with Confidence

Bundle Drop is an over-the-air update platform for React Native. It delivers compatible JavaScript and bundled asset changes without requiring a new App Store or Play Store build for every update.

Native releases and OTA releases remain separate: native binaries define the compatibility boundary, while channels, staged rollouts, and rollback control how eligible updates reach installed apps.

Learn more: Introduction · Why React Native teams use OTA updates

An installed app checks its active channel for the newest update that matches its platform and runtime version. If an eligible update exists, the SDK downloads and verifies it. Depending on policy, activation can remain under application control, happen immediately, or wait for the next cold launch.

The installed native binary remains the compatibility boundary. An OTA release cannot make an incompatible binary eligible for JavaScript or assets that depend on newer native code.

Learn more: Introduction · Update Policies

OTA delivery is for JavaScript and assets already supported by the installed native binary, including UI, application logic, copy, and bundled images. A new native dependency, permission, config-plugin change, engine change, or other native build input requires a store release.

A useful test is whether the change needs a different iOS or Android binary. If it does, ship that binary first and move it to an appropriate runtime version before delivering dependent OTA updates.

Learn more: When an OTA update isn't enough · Runtime Version

Bundle Drop supports React Native apps on iOS and Android. Update eligibility is resolved separately for each platform and runtime version, so an iOS release cannot receive an Android bundle and an older binary can remain on its last compatible OTA line.

The supported React Native and Expo version matrix changes as their release lines evolve, so the installation guide is the source of truth for current compatibility.

Learn more: Installation and compatibility · Runtime versions explained

Yes. Bundle Drop supports bare React Native apps on iOS and Android. The package uses autolinking, while the project-aware setup connects Metro and the existing native bundle-resolution paths without replacing the app's host or delegate structure.

Because setup changes native integration, install a new release binary before testing OTA behavior. The installation guide contains the current React Native compatibility range and platform-specific checks.

Learn more: Bare React Native integration · SDK Integration

Yes. Bundle Drop supports Expo managed and Continuous Native Generation projects. Its config plugin applies the native integration during prebuild or EAS Build, so the ios and android directories do not need to be committed to the repository.

Expo Go and development-client builds keep Metro in control and do not test installed OTA startup. Create and install a non-Debug native build first. If expo-updates is active, migrate it explicitly and rebuild because both systems cannot own native startup in the same binary.

Learn more: Bundle Drop for Expo · Expo setup guide

OTA updates can be used within Apple and Google's rules, but no OTA provider can guarantee store approval. Your team remains responsible for the current review guidelines and for ensuring that an update does not bypass requirements that apply to a new app binary.

Keep OTA changes within the capabilities and purpose of the reviewed native app. Native code, permissions, and changes that materially alter the binary still belong in a normal store release.

Learn more: When an OTA update isn't enough · Runtime Version

Create a Bundle Drop project, install the package, and sign in through the CLI. The project-aware setup detects Expo or bare React Native, previews the required configuration, and asks before applying it.

Build and install the resulting native integration, then upload a compatible JavaScript bundle to a channel. The app can begin resolving OTA releases from that channel on subsequent launches.

Learn more: Installation · Uploading

Yes. Bundle Drop provides a project-aware migration path from CodePush, but the systems are not treated as exact drop-in equivalents. Deployment keys, sync behavior, release targeting, and rollback have corresponding concepts that should be reviewed rather than renamed mechanically.

The setup detects an existing CodePush integration and previews the Bundle Drop changes. In bare projects, it preserves the current native host and delegate structure where possible; Expo projects use the config-plugin path. Every migration requires a new native binary.

Learn more: CodePush migration guide · Choosing an OTA strategy after CodePush

Channels are named OTA release streams inside a project. An app checks a specific channel, and each upload or promotion publishes a bundle to a channel, allowing production, beta, QA, or other release tracks to progress independently.

A channel is not the same as an app-defined environment or a runtime version. Those concepts answer different questions about business context, native compatibility, and release flow.

Learn more: Channels · Release channels vs environments

A production channel is the single channel in a project designated as the real-user release path. It uses the same compatibility and resolution model as other channels, while enabling production-specific retention choices and making that operational role explicit.

It is still a release stream, not an app environment. Changing a channel's production designation does not change the app-defined environment or make an incompatible runtime eligible.

Learn more: Production Channels · Release channels vs environments

Targeting rules define which installations are eligible for a release, while the rollout percentage controls how much of that matched audience receives it. Multiple targeting rules are evaluated as alternatives, so matching any configured rule can make an installation eligible.

Managed publishing must be enabled for rollout state and percentage to gate delivery. A stable installation bucket keeps percentage behavior consistent across checks; if an installation is not eligible for the newest release, resolution can fall through to the next compatible release.

Learn more: Targeted Rollout · Staged rollouts, targeting, and rollback

Yes. An operator-initiated rollback changes what future update checks select for that channel. On its next check, an eligible installation can move to the latest safe compatible release. It is a server-side release action, not a reverse patch that your team has to construct.

When no earlier OTA release is available, the installed app can return to the native bundle shipped inside its binary. On-device crash recovery is related, but it is a separate startup-safety mechanism.

Learn more: Rollback · Staged rollouts, targeting, and rollback

Bundle Drop's on-device startup protection can return to the last known-good OTA bundle, or the embedded native bundle, after repeated launches remain unconfirmed before the update is marked healthy. The failed bundle is then blocked on that installation instead of being retried immediately.

This protection can observe only launches that reach an early BundleDrop.init() call. Failures before JavaScript initialization still require native crash reporting and normal release investigation.

Learn more: Automatic crash protection · Staged rollouts, targeting, and rollback

Bundle Drop can use patch delivery when a smaller update can be produced and applied safely. Patch delivery is an optimization, not a requirement: every release also has a complete verified bundle available as a fallback.

If a patch cannot be used for an installation's current state, the client can fall back to the full bundle. If neither download path succeeds and verifies, the update is not staged and the current bundle remains active.

Learn more: Patch delivery with full-bundle reliability · Uploading

Bundles are delivered over HTTPS through signed, time-limited URLs, and the SDK verifies downloaded content before activation. An incomplete download or failed verification is not applied, so the app continues using its existing bundle.

Transport and artifact verification are only part of release safety. Runtime compatibility, controlled eligibility, and rollback provide separate boundaries for deciding what can run and how to recover from a bad release.

Learn more: Patch delivery with full-bundle reliability · Rollback

Yes. The Bundle Drop CLI supports non-interactive publishing with a Personal Access Token supplied by the pipeline's secret store. This works with GitHub Actions, GitLab CI, Bitrise, and other systems that can run the upload command securely.

Keep the token out of source control and scope the pipeline to the intended project and release workflow. Local development can continue to use interactive login.

Learn more: CI/CD · CLI

Yes, Bundle Drop has a free plan. Bundle Drop does not price plans by monthly active users; its limits are based on resources that more closely reflect operating the OTA service instead.

Plan limits can change, so the pricing page is the source of truth for current details. The pricing decision article explains the engineering and product reasoning without acting as a plan comparison.

Learn more: Pricing · Why we don't price by monthly active users