Why Bundle Drop Combines Patch Delivery with Full-Bundle Reliability

Most React Native OTA releases do not replace an entire application. A production fix may change one conditional, adjust a request handler, or update a small set of bundled assets. Yet a full-bundle delivery model asks every eligible device to download the complete JavaScript and asset payload again.

That is a simple and dependable model, but it can transfer much more data than the change itself requires. The difference matters on mobile networks, where bandwidth, latency, interruptions, and background-execution limits are ordinary operating conditions rather than edge cases.

Patch delivery addresses the efficiency problem by transferring a representation of what changed instead of sending the whole release. It does not remove the reliability problem. In fact, a patch introduces another precondition: the device must be in a state from which that patch can safely produce the intended result.

A production OTA system therefore has two objectives that must be considered together:

1. avoid transferring bytes that a device does not need;
2. never make the smaller transfer a prerequisite for reaching a valid release.

Bundle Drop combines patch delivery with a verified full-bundle fallback for this reason. A patch is an optimization of the delivery path. It is not the release's only usable form, and it is not allowed to weaken safe activation.

Why patch delivery exists

An OTA bundle contains the JavaScript and bundled assets that a compatible native application can load. In a large application, that payload can be substantial even when a particular release changes very little.

Suppose a team publishes a correction to a date formatter. The source change may be a few lines, while the generated bundle still contains the application module graph, framework code, dependencies, and other unchanged content. If the delivery system only serves complete bundles, the size of the download is tied to the size of the application rather than the size of the release.

Bandwidth is a device constraint

Mobile users do not all update over stable Wi-Fi. Some use metered connections, experience high latency, move between network types, or lose connectivity while the app is in the background. A smaller transfer spends less time exposed to those conditions and consumes less of the user's data allowance.

Download time affects update readiness

An available release cannot be staged until its content has arrived and passed the checks required by the client. Larger transfers generally take longer and have a wider window in which the operating system, application lifecycle, or connection can interrupt the work.

That does not mean a smaller download should be applied immediately. Download timing and activation timing are separate policy decisions. Bundle Drop exposes manual, on-next-launch, and immediate update policies so an application can choose when an eligible release is downloaded and when it becomes active.

Repeated releases amplify the difference

OTA systems are most useful when teams can publish focused fixes and incremental changes. If each small release requires every device to redownload the entire bundle, the delivery overhead repeats even though most bytes remain unchanged between adjacent releases.

When a device has a suitable starting point, patches align transfer work more closely with release work: reduce unnecessary transport while preserving the same destination release.

Why patch delivery alone is not enough

A full bundle is self-contained from the client's perspective. Given the correct platform and runtime version, the device can validate and stage that release without reconstructing it from a previously installed OTA version.

A patch has a dependency. It describes a transition from an expected source state to a target state. If the device does not have that expected source state, the patch is not a safe way to reach the target.

In production, there are many legitimate reasons for installations to have different starting points:

• a user may have skipped one or more releases;
• a new installation may only have the bundle embedded in the store binary;
• a device may have remained offline during an earlier rollout;
• a release may have been rolled back before every installation adopted it;
• staged or targeted rollout rules may have led devices to different eligible releases;
• local recovery may have returned a device to an earlier bundle.

Networks and local state are fallible

A transfer can be interrupted. Locally stored data can be incomplete or fail validation. An older client may not support a particular optimized delivery path. A device can run out of storage between checking for an update and staging it. The application can be terminated while work is in progress.

None of these conditions justify activating a partially reconstructed release. The client needs a clear success boundary: the intended complete bundle is present, verified, and safe to stage, or the current working bundle remains active.

The public Bundle Drop runtime reflects that boundary. downloadUpdate() reports an update as staged only after the complete bundle intended for local use has been produced and validated. Application code does not need to decide whether transport used a patch or a full bundle.

Fallback is not the same as ignoring errors

Full-bundle fallback should not be read as “all failures disappear.” If the device has no usable connection, lacks storage, or cannot validate the full artifact either, the update cannot be staged. The application should keep running its current verified bundle and try again under the app's chosen policy.

Fallback solves a narrower and important problem: a device should not be stranded merely because the optimized patch path is unavailable or unsuitable. It provides an independent route to the same release rather than asking application developers to handle patch-specific recovery.

The engineering tradeoff

There are two obvious designs at opposite ends of the delivery spectrum.

Option A: always download the complete bundle

This is the simplest model to reason about. Every eligible device receives a self-contained artifact for the target release.

Its advantages are substantial:

• the download does not depend on a particular previously installed OTA bundle;
• there is one transport path to test and operate;
• support and incident diagnosis have fewer delivery states;
• the device's starting version does not determine whether it can fetch the target.

The disadvantage is systematic over-transfer. A one-line fix and a large application change can require similarly sized downloads because both are delivered as complete bundles. For teams that publish regularly or serve users on constrained networks, that simplicity can impose a meaningful recurring cost.

Option B: always depend on patches

A patch-only design prioritizes minimum transfer size. When the expected source state exists and the change is compact, the result can be much smaller than a full bundle.

But making patches mandatory turns every patch precondition into a release precondition. Devices on unexpected source versions need additional patch paths, must traverse multiple transitions, or cannot update. A failed reconstruction becomes a deployment failure rather than an optimization miss. Operational complexity moves from bandwidth into state management and recovery.

Neither extreme is a complete answer

Always-full delivery gives reliability a straightforward shape but leaves efficiency on the table. Always-patch delivery pursues efficiency by increasing the number of conditions that must hold before a device can reach a release.

A more balanced design keeps the complete artifact as the release's dependable form and treats a patch as an optional, verified route to it. Devices use the optimized route when its prerequisites are satisfied. Otherwise, they fall back to the complete bundle.

The provider must validate and operate both transport paths, but that complexity can remain below the application-facing API. Product code asks to download an eligible update and receives the same complete staged result.

Bundle Drop's design philosophy

Bundle Drop treats patch delivery as an optimization, not a requirement that devices must satisfy.

When only a small part of an application changes and a device has a suitable starting version, the update may be delivered as a much smaller patch. The release also remains available as a complete verified bundle. If the patch cannot safely be used, the client can fall back to that complete bundle instead.

The intended control flow is simple at the product boundary:

Compatible release selected
          |
          v
Is a safe patch path available for this device?
          |
       +--+--+
       |     |
      yes    no
       |     |
       v     v
   Try patch  Download complete bundle
       |
       v
Patch cannot produce a verified target?
       |
       v
Fall back to complete bundle
          |
          v
Verify complete local result
          |
          v
Stage for activation according to update policy

Release selection and delivery are separate

Channels, runtime compatibility, managed publishing, targeting, and rollout percentage determine which release a device is eligible to receive. Patch availability does not define that release decision. It determines how the selected release may be transferred.

The eligibility pipeline itself is covered in How staged rollouts, targeting, and rollback fit together; patch or full-bundle transport begins only after that pipeline selects a release.

This separation matters during staged rollouts. Two eligible devices may have different current bundles because they joined a rollout at different times. One may have an efficient patch path while the other needs the complete bundle. Both should still converge on the same selected release when their rollout and update policies allow it.

It also means patch preparation does not have to block release availability. Bundle Drop's uploading documentation explains that eligible installations can use the full bundle while optimized delivery is being prepared, and that a full bundle is deliberately used when patching would not be efficient.

Verification applies to the result, not the promise of efficiency

The safety requirement is not “a patch downloaded successfully.” It is “the complete target bundle is present and validated before it can be staged.” A short transfer that cannot establish that result has no value.

This is why safe activation is downstream of verification. Whether content arrived through an optimized patch path or a full-bundle path, the update should cross the same conceptual trust boundary before application code can activate it.

Bundle Drop keeps this transport choice out of the normal integration. Apps using useBundleDrop() or the lower-level runtime APIs receive the same staged state. Teams can build update prompts, background flows, or manual apply controls without maintaining separate patch and full-bundle branches.

Reliability takes priority over bandwidth savings

An efficient patch is useful only when the client can safely use it. When that condition is not met, spending more bandwidth on the verified full bundle is the correct trade.

This priority accepts that some requests will transfer more data than the theoretical minimum. The full bundle is not an exceptional artifact; it is a routine, tested part of the delivery contract.

Why this matters in production

Production mobile fleets are heterogeneous. Devices run different OS versions, enter and leave connectivity, retain different amounts of free storage, and check for updates on their own schedules. Store releases and OTA releases overlap. Rollouts pause, resume, and sometimes reverse.

An update design that assumes all devices are on the immediately previous release will eventually meet a device that is not.

Unstable networks reward small transfers, but require safe failure

Patch delivery reduces the amount of data at risk during a download. That is valuable on slow or unstable networks. But the more important invariant is what happens when the transfer does not complete: the current bundle remains the running bundle, and no partial target is activated.

If the optimized route proves unusable while connectivity remains sufficient, full-bundle fallback gives the device another route. If neither route completes safely, the update stays unstaged. Predictable refusal is better than ambiguous partial success.

Large fleets contain long tails of state

At scale, even uncommon installation histories represent real users. Full-bundle fallback avoids designing only for the modal device state or requiring every installation to advance through an identical patch sequence.

For operations, observe the release identity that is running rather than assuming delivery method implies adoption. Bundle Drop's observability guide describes how to associate runtime and error context with the installed OTA bundle.

Progressive rollout is about risk control, not transport purity

A staged rollout intentionally creates a mixed fleet while a release is evaluated. Targeted rules can create additional legitimate branches in eligibility. A server-side rollback changes future selection, while on-device recovery may move an affected installation to an earlier verified bundle.

Patch optimization can be used where it fits, while full-bundle fallback preserves reachability for installations whose histories differ. Operations can focus on release health instead of enforcing one transfer form.

If a release itself is faulty, delivery fallback is not the recovery mechanism. Teams should use the documented rollback controls to move devices away from that release. Transport reliability and release correctness are separate concerns, and a robust OTA program needs both.

Predictable behavior is more valuable than a perfect efficiency ratio

The smallest update a patch system can produce says little about devices that cannot use it, interruption behavior, or safe activation.

Useful production questions are less dramatic:

• Can every compatible, eligible installation reach the selected release?
• Does an optimization failure have a documented fallback?
• Is the existing working bundle preserved when no candidate can be verified?
• Do patch and full-bundle paths converge on the same staged release state?
• Are fallback behavior and older installation states exercised before a broad rollout?

Those questions encourage teams to monitor availability, download, staging, activation, and release health separately instead of treating a small patch as evidence that deployment succeeded.

Optimize both, force neither

Patch delivery is valuable because most releases do not change most of an application. Sending less data can reduce bandwidth use, shorten download windows, and improve update readiness on mobile networks.

Reliability is essential because devices do not share one clean, linear history. Patches can have source-state requirements, networks fail, clients vary, and local data must be treated as untrusted until the intended result is verified.

Bundle Drop combines the two concerns by keeping patch delivery optional and full-bundle reliability continuously available. A suitable device can take the smaller path. A device that cannot use that path can fall back to the complete verified bundle. In both cases, safe activation depends on validating the complete local result, not on how few bytes crossed the network.

That design does not promise that every update will be tiny or that mobile delivery will never fail. It makes a narrower and more useful commitment: bandwidth optimization should not become a new condition for deployment correctness.

A production OTA system should optimize for efficiency and reliability together. Teams should not have to choose between downloading every byte every time and trusting a patch path with no dependable alternative.