React Native Over-the-Air Updates in 2026: Skip the App Store Wait with Codemagic CodePush

This article is written by Karl Suhajda

If you’ve shipped a React Native app to production, you already know the feeling. A bug surfaces. Users are reporting it. Your fix is written, tested, and ready to go. And then you wait.

Two days. Sometimes three. Occasionally five. App Store review doesn’t care that your ratings are dropping or that your support queue is filling up. It moves at its own pace, and your users experience every hour of the delay.

CodePush over-the-air (OTA) updates change that equation entirely. They let React Native teams push JavaScript changes, bug fixes, UI updates, and asset changes directly to users’ devices, no App Store submission, no Google Play review, no action required from the user. The next time they open the app, they have the latest version.

This guide covers everything your team needs to know about over-the-Air updates in 2026: how they work, when to use them, what the boundaries are, and how to set up a production-ready deployment workflow that lets you ship with confidence.

Watch First: The 6-Minute Overview

If you’d prefer to watch before you read, the video below covers the full picture, what Over-the-Air updates are, the three core use cases, infrastructure, pricing, and who this is built for.

What Are Over-the-Air Updates?

React Native apps have a two-layer architecture. The first layer is the native shell, the compiled iOS or Android binary that lives in the App Store or Google Play. This layer handles device hardware access, native APIs, and the core application container. Changing it requires a new binary build and a full store submission.

The second layer is the JavaScript bundle, the logic, UI components, styling, and assets that make up most of what your users actually see and interact with. This layer runs on top of the native shell, and critically, it can be updated independently.

Over-the-air updates work by replacing the JavaScript bundle on a user’s device with a newer version, delivered directly from a hosted update server. When a user opens the app, it checks for an available update, downloads it in the background if one exists, and applies it, either immediately or on the next app launch, depending on your configuration.

The result: your users get the updated version of your app without visiting the App Store, without downloading a new binary, and usually without even knowing an update happened.

The Three Core Use Cases

Understanding when to reach for OTA updates is just as important as understanding how they work. There are three scenarios where teams consistently find them most valuable.

1. Production Hotfixes

This is the use case that convinces most teams to adopt OTA updates. A critical bug appears in production, a broken API call, a payment flow error, a crash on a specific device. The fix is straightforward, it touches only JavaScript, and it needs to reach users as fast as possible.

Without OTA updates, your options are limited and slow. With them, you can push the fix to a staging channel, validate it, and begin a staged rollout to production users within hours. The bug gets patched the same day it surfaces.

2. Continuous Iteration

For product teams shipping fast, the traditional mobile release cycle is a bottleneck. You want to run an A/B test on a checkout flow. You want to change button copy based on what’s performing in analytics. You want to push a UI refinement without the overhead of a full store release.

OTA updates decouple your JavaScript iteration speed from your native release cycle. You can push changes as often as your testing and release processes support, daily if needed, without touching the App Store or Google Play.

3. Controlled Rollouts

Not every update should go to 100% of users at once. Controlled rollouts let you push an update to a percentage of your user base first, say, 5% to a beta channel, monitor installs, error rates, and performance, and only expand the rollout when you’re confident the update is stable.

This dramatically reduces the blast radius of a bad push. If something goes wrong, you catch it at 5% rather than 100%, and you roll back before most users are affected.

What OTA Updates Cannot Do

OTA updates are powerful, but they operate within clear boundaries and understanding those boundaries prevents both wasted effort and app store policy violations.

OTA updates cannot change:

• Native modules or native dependencies. If an update requires adding or modifying native code, a new SDK that has a native layer, a change to how the app interfaces with device hardware, it requires a full binary rebuild and store submission.

• App permissions. If you need to request a new device permission (camera access, location, push notifications), that’s a native change and requires a store release.

• The fundamental nature of the app. Both Apple and Google’s policies are clear on this point: OTA updates must not be used to ship functionality that would materially change what the app does. The update mechanism is for improvements and fixes, not for circumventing the review process for significant new features.

• Payment flow infrastructure. Specifically on iOS, changes to in-app purchase flows are subject to scrutiny and should go through the standard review process.

A practical decision rule: if the change you want to ship lives entirely in your JavaScript files and assets, it is almost certainly eligible for an OTA update. If it touches anything in your ios/ or android/ directories, it is not.

How Codemagic CodePush Works

Codemagic’s CodePush is a fully hosted, managed OTA update service built specifically for React Native teams. Here is what that means in practice.

Hosted and Managed - No Infrastructure Required

Running your own OTA update infrastructure means managing servers, CDN configuration, storage, uptime, and security. For most teams, that overhead isn’t justified, it’s engineering time spent on infrastructure that isn’t your product.

Codemagic CodePush handles all of that. You push an update, it gets distributed. The infrastructure scales with your user base, maintains uptime, and handles security at the server level. Your team focuses on the app.

New Architecture Support

React Native’s New Architecture - with its JSI-based communication model, TurboModules, and Fabric Renderer - is now the mandatory standard from React Native 0.82 onwards. Codemagic CodePush is compatible with React Native 0.76 and above, meaning teams on the New Architecture have full OTA capability without any migration complexity.

The Analytics Dashboard

One of the most practical advantages of Codemagic CodePush is the built-in analytics. You get per-project metrics covering the number of downloads, installs, and failed installs.

All of this is available in a web-based UI. No CLI tools required to understand what’s happening in production. Your engineering manager can check update activity without touching the terminal.

At a higher level, you also get a usage overview across all your projects, grouped by month, this is useful for teams managing multiple apps.

CI/CD Integration

Codemagic CodePush works as a standalone OTA service or as part of a wider Codemagic CI/CD pipeline. If your team is already running automated builds and deployments with another vendor, CodePush slots into that workflow. If you want to move your full pipeline to Codemagic, that migration path is available with onboarding support included.

Enterprise-Grade Infrastructure

The numbers behind the platform are worth stating plainly: 99.9% successful update delivery rate, over one billion API requests handled monthly, 300 million unique visitors served monthly, and three petabytes of data delivered each month.

Security and Compliance

For teams in regulated industries or enterprise environments, compliance requirements are often the first question. Codemagic CodePush is SOC 2 Type II audited, operates with ISO 27001-certified data centre partners, and is fully GDPR and CCPA compliant. Audit reports are available on request. For enterprise customers with specific data residency requirements, dedicated CodePush servers with country-specific storage options are available.

Pricing

There are two pricing models available for Codemagic CodePush.

The first is a Pay-as-you-go option at $1 per 2,500 installs, which suits teams of any size apps who push updates infrequently or unpredictably.

For teams with more than 1 Million Monthly Active Users (MAU) there is a fixed price option pricing that starts at $99 per month per 100,000 monthly active users.

With both options there are no additional charges for bandwidth or storage.

A free trial is available so teams can validate their integration before committing to a paid plan.

OTA Update Best Practices

Shipping OTA updates safely at scale requires more than the technical setup. These practices apply regardless of which OTA tool you use.

Never Deploy to 100% at Once

The single most important rule in OTA deployment: always start with a staged rollout. Push to a small percentage of your production user base first, say 5% or 10% is a reasonable starting point. Monitor for installs, crashes, and error rates before expanding. Production environments surface issues that staging doesn’t, and catching a problem at 5% is dramatically less costly than catching it at 100%.

Keep Staging and Production Channels Separate

Your staging channel should mirror production as closely as possible, but be accessible only to your internal team. Validate every update in staging before it touches a single production user. This isn’t optional, it’s the practice that separates teams who trust their OTA workflow from teams who treat every push as a gamble.

Have Your Rollback Plan Ready Before You Need It

A rollback reverts your production user base to the previous stable bundle. You should know exactly how to trigger one before you ever need it, and you should have tested the rollback process in staging. Teams that haven’t pre-tested rollback tend to scramble when something goes wrong which is the worst possible time to be figuring it out.

Monitor Post-Deploy, Not Just Pre-Deploy

After pushing an update, watch your analytics dashboard. You want to see installs progressing steadily, error rates staying flat or improving, and version distribution shifting toward the new bundle. Any unexpected deviation from normal metrics is a signal to pause and investigate before expanding the rollout.

Document Your Process

Who has permission to push to production? What does a staged rollout look like step by step? What triggers a rollback? These should be written down and accessible to your team, not stored only in someone’s head.

Frequently Asked Questions

Are OTA updates allowed by Apple and Google?

Yes, with conditions. Both Apple’s App Store guidelines and Google Play’s policies permit OTA updates for JavaScript and asset changes, provided the updates do not materially change the app’s core functionality or purpose. The mechanism is well-established and widely used across the React Native ecosystem. The key restriction is that OTA updates should not be used to circumvent the review process for significant new features or changes that would otherwise require store approval.

What happens if an OTA update breaks the app?

A properly configured OTA setup includes automatic rollback functionality. If the app fails to launch after applying an update, CodePush detects the failure and reverts to the previously stable bundle on the next launch. Additionally, your staged rollout process means that a bad update should be caught and manually rolled back before it reaches a significant portion of your user base.

Can I use OTA updates with the React Native New Architecture?

Yes. Codemagic CodePush supports React Native 0.76 and above, covering the full New Architecture. Teams mid-migration should test their OTA delivery in a staging environment after completing the migration to confirm everything is operating as expected before pushing to production.

Do my users need to do anything to receive an update?

No. OTA updates are delivered silently in the background. The next time a user opens the app after an update has been applied, they are running the new version. No App Store visit, no manual download, no notification required.

How does Codemagic CodePush handle users on older versions of the app?

You can target OTA updates at specific binary versions of your app. This means you can push a fix that applies only to users running a particular native build, without affecting users on a different version. This level of targeting is particularly useful when managing multiple active app versions simultaneously.

Getting Started

The fastest path to your first OTA update with Codemagic CodePush:

1. Start a free trial at codemagic.io/codepush no commitment required.
2. Add the CodePush SDK to your React Native project.
3. Set up your deployment channels, staging and production at minimum.
4. Push your first update to staging and validate the delivery.
5. Talk to our team if you need onboarding assistance, it’s included.

Full documentation is available at https://docs.codemagic.io/rn-codepush/setup/

Summary

Over-the-air updates are not a shortcut or a workaround. They are the standard deployment model for any React Native team that ships frequently, cares about incident response time, and wants meaningful control over how updates reach their users.

The combination of same-day hotfix capability, continuous iteration speed, controlled rollout tooling, and production-grade infrastructure makes OTA updates one of the highest-leverage investments a React Native team can make in their release process.

The question in 2026 is no longer whether to use OTA updates. It is which platform to entrust them to.