DEV Community: George Fean

OTA Pricing Is Part of Your Release Architecture

George Fean — Mon, 14 Sep 2026 21:32:20 +0000

Pricing is usually treated as something engineering looks at after the architecture decision.

Pick a service.

Make sure it solves the technical problem.

Then compare plans.

For infrastructure that participates directly in production releases, I think that order misses something important.

The thing a platform charges for becomes one of the things your team starts paying attention to.

If an OTA system charges by monthly active users, engineers notice audience growth.

If it charges by bandwidth, they notice transferred bytes.

If it charges by storage, they notice retained artifacts.

If it charges by seats, they notice how many people have operational access.

If it charges by requests or compute, they notice check frequency and processing volume.

None of those models is inherently wrong.

But each one creates a different operational interface between the product and the engineering team.

For React Native OTA updates, that matters because release safety depends on behavior the pricing model can indirectly encourage or discourage.

OTA workload is not one-dimensional

An OTA service does much more than store a JavaScript file.

A production system may have to retain release artifacts, evaluate compatibility, process update checks, deliver bundles and assets, prepare patch artifacts, maintain release history, track rollout state, preserve rollback targets, and provide enough metadata to understand which JavaScript release was running during an incident.

Those workloads scale differently.

Storage grows with things such as artifact size, release frequency, runtime lines, projects, and retention policy.

Bandwidth grows with the size of what is delivered and how many devices actually download it.

Patch preparation follows publishing activity and artifact characteristics.

Update-resolution traffic follows fleet behavior and client policy.

Operational support may depend more on integration complexity and incident frequency than raw user count.

Trying to compress all of that into one billing unit is necessarily an approximation.

The interesting question is not:

Which pricing unit is objectively correct?

It is:

Which approximation produces incentives we are comfortable building our release process around?

MAU pricing measures product reach well

Monthly Active Users is a familiar metric for a reason.

It is easy to understand.

Product teams already track it.

For many SaaS products, it is a reasonable proxy for both value and workload.

If more people use an analytics product, for example, more events are usually generated, retained, and queried.

For OTA systems the relationship is looser.

Two applications can have the same MAU count and produce very different release workloads.

One might ship a compact JavaScript fix once a month.

Another might maintain several native runtime lines, release several times a week, retain a long rollback history, and ship asset-heavy updates.

Their audience measure is identical.

Their OTA operational profiles are not.

The reverse can happen too.

An application can gain a large audience during a month in which the engineering team publishes no OTA release at all.

The value of reliable release infrastructure becomes greater because the blast radius of a future mistake is larger.

But artifact preparation did not suddenly multiply just because more users opened the application.

That does not make MAU pricing unreasonable.

It means MAU primarily measures audience scale, not the complete shape of OTA workload.

Bandwidth pricing creates a different incentive

Charging for transferred bytes is much closer to one real infrastructure cost.

Large updates cost more to distribute than small ones.

A million devices downloading a 5 MB payload obviously creates a different delivery profile from the same fleet receiving a tiny patch.

That makes bandwidth a technically understandable meter.

It can also influence release behavior.

If every full-bundle fallback has an obvious financial cost, teams may feel pressure to optimize transfer size aggressively.

Usually that is healthy.

Sometimes it can conflict with reliability.

A patch is useful when the device has the correct baseline and reconstruction succeeds.

A complete bundle is useful when the device does not.

If the safest recovery path is financially treated as an expensive exception, the pricing model has entered the release-design discussion.

Again, that does not make bandwidth pricing bad.

It means the team should ask whether the meter aligns with the failure behavior it actually wants.

Storage pricing encourages explicit retention decisions

Storage is another understandable unit.

OTA artifacts occupy real space.

Previous releases are useful for rollback.

Source maps and release metadata are useful during incident analysis.

Multiple runtime lines can remain active while users slowly adopt a new store binary.

A storage-oriented model makes that history visible.

When storage approaches a limit, the engineering team can inspect what it is retaining.

Perhaps old development releases can be removed.

Perhaps production history should be kept longer.

Perhaps an obsolete runtime line can finally be retired.

Those are actions engineers can connect directly to release management.

Storage is not a perfect meter either.

A small set of heavily downloaded bundles can occupy very little disk while generating substantial traffic.

A platform still has databases, request processing, monitoring, support, and other operational costs.

The benefit is not perfect cost correspondence.

It is that the unit maps to something the release team can inspect and control.

Seat pricing changes who participates in releases

Seat-based pricing is common because it is predictable.

The company knows roughly how many people need access.

The provider can tie plans to organization size.

But it also creates an incentive.

If every additional QA engineer, support engineer, or incident responder increases the bill, organizations may restrict access to the release system.

That may be completely acceptable.

It may also work against a release process that benefits from wider operational visibility.

An OTA dashboard is not only used by the person who presses Publish.

During an incident, support may need to identify which release is active.

QA may need to verify a rollback.

Another engineer may need to inspect targeting or runtime compatibility.

Pricing access is therefore also pricing participation in release operations.

Combined usage models can be technically accurate and cognitively expensive

A provider could meter everything:

storage
+ bandwidth
+ requests
+ build or patch compute
+ seats
+ support tier

That may produce a more accurate representation of infrastructure cost.

It can also produce a worse engineering experience.

Before publishing a production fix, nobody wants to calculate a miniature cloud-capacity model to understand whether the release changes the monthly bill materially.

There is always a tradeoff between technical precision and predictability.

A pricing model can model provider cost extremely well while giving customers a difficult system to reason about.

Or it can intentionally absorb variation behind a simpler capacity boundary.

Both approaches are business choices.

What matters to engineering is the behavior they create.

Pricing can influence release granularity

This is where the discussion becomes more than finance.

Suppose a team finds a small JavaScript bug in production.

The technically clean response might be:

fix the narrow issue;
validate the exact artifact;
release it to a small cohort;
observe the result;
expand it when healthy.

Now imagine the team has started thinking of every release primarily through a usage threshold.

A conversation can subtly change from:

Is this fix compatible and safe?

to:

Is this change important enough to justify another OTA event this month?

That can encourage teams to combine unrelated changes.

Or wait for a larger release.

Or avoid a conservative staged rollout because additional delivery feels expensive.

No pricing model mechanically forces those decisions.

Engineering culture matters much more.

But incentives do matter.

Release infrastructure works best when the easiest economic behavior and the safest technical behavior point in roughly the same direction.

Pricing can influence rollback history too

Rollback safety depends on keeping something worth returning to.

If previous artifacts are immediately discarded, the release system has fewer known-good options.

If everything is retained forever, storage and operational history grow indefinitely.

There is a real tradeoff.

A useful pricing model makes the tradeoff visible enough that teams manage it deliberately rather than accidentally.

For OTA, that means questions such as:

How many production releases should remain recoverable?
How long do older runtime lines stay active?
Which source maps need to remain available for crash investigation?
Which development artifacts are genuinely disposable?

Those are release-engineering decisions.

They are easier to reason about when the resource being limited has a visible relationship to them.

User growth is different from release growth

One of the reasons I think OTA pricing deserves architectural attention is that application success and release-system complexity are not the same thing.

A team can double its user base without doubling:

the number of projects;
the number of runtime lines;
the number of retained artifacts;
the number of engineers publishing releases;
or the number of releases shipped that month.

Traffic can certainly increase with audience size.

More devices may check for updates.

A popular release may transfer much more data.

Support expectations can rise.

The relationship is real.

It simply is not one-to-one.

That distinction matters when forecasting operational cost.

If the meter is audience-based, growth forecasting becomes part of OTA budgeting.

If the meter is storage-based, artifact and retention planning becomes more important.

If the meter is bandwidth-based, bundle size and adoption dominate.

The pricing model tells the engineering organization which variable it will spend time predicting.

A useful evaluation question for any OTA provider

When comparing OTA systems, I would add one question beside compatibility, rollback, and delivery:

What behavior does this pricing model cause our team to optimize?

For an MAU model, ask how active users are defined.

Are they accounts?

Devices?

Anonymous installations?

Only users who actually request an update?

For bandwidth, ask whether full-bundle fallback, retries, and assets are included.

For storage, ask what artifacts count and how retention works.

For seats, ask which operational roles need access.

For combined usage, model one realistic release month rather than comparing headline plan prices.

The best meter is not necessarily the smallest number.

It is the one whose surprises your team knows how to manage.

Pricing should not override release safety

Regardless of billing model, some release rules should remain non-negotiable.

If a change crosses the native compatibility boundary, it needs a new binary.

If a candidate has not been validated, it should not become safer because delaying it saves money.

If risk calls for staged rollout, use staged rollout.

If a bad release needs a full known-good fallback, reliability should win over optimizing transferred bytes.

If production history is necessary for rollback and incident review, retain enough of it.

The pricing model belongs around those decisions.

It should not silently rewrite them.

Where Bundle Drop fits

Disclosure: I build Bundle Drop.

Bundle Drop currently does not meter plans by monthly active users.

The public plans all include unlimited MAU, while visible capacity is expressed through things such as projects, organization members, channels, and shared OTA storage. The pricing page remains the source of truth because those plan details can change.

That is not a claim that MAU pricing is universally wrong.

It is a product decision about which behavior I want Bundle Drop users to think about.

I would rather a team ask:

Is this release runtime-compatible?
Was this exact artifact validated?
Should we roll it out gradually?
Do we have enough known-good history to recover?

than ask whether another successful month of user growth changes whether a small production fix is worth shipping.

Resource-oriented capacity is an approximation too.

Two applications with the same retained storage can generate very different traffic and support workloads.

Bundle Drop accepts more of that variation behind the same visible capacity because the resulting engineering incentive is the one I prefer for the product.

Other providers can reasonably make a different tradeoff.

Pricing is part of the engineering interface

OTA pricing is not just the invoice attached to the release platform.

It tells engineering which variable is scarce.

Audience.

Bytes.

Storage.

Access.

Requests.

Compute.

Every choice creates a different optimization target.

When evaluating an OTA system, the useful question is therefore not only:

How much will this cost us?

It is also:

What will this pricing model make our team think about every time we ship?

That answer becomes part of the release architecture whether we intend it to or not.

Originally published on Bundle Drop Resources.

React Native OTA After CodePush: How to Choose a Tool in 2026

George Fean — Wed, 09 Sep 2026 13:15:05 +0000

Microsoft’s hosted App Center CodePush service is gone.

App Center’s main services, including CodePush, were retired on March 31, 2025. Microsoft also published a standalone CodePush server for teams that wanted to preserve the old protocol, but that repository was archived and made read-only in May 2025. (Microsoft Learn)

So React Native teams evaluating OTA in 2026 are no longer choosing between “CodePush or nothing.”

They are choosing between several different operating models.

Some tools preserve a CodePush-shaped workflow.

Some are built around Expo’s update protocol.

Some use their own SDK, runtime, and rollout model.

Others move the whole service into infrastructure your team operates.

That makes “Which CodePush alternative is best?” a fairly weak question.

A better question is:

Which system matches the compatibility model, release controls, migration distance, recovery behavior, and ownership boundary our team actually needs?

This is not a ranking. Product behavior and plans change, and similarly named features often have different semantics. The first-party documentation referenced here was rechecked in September 2026. (Bundle Drop)

Start with the operating model

The first split is not really about features.

It is about who owns the OTA platform.

A managed service gives the mobile team a hosted control plane, artifact infrastructure, and supported release workflow.

A self-hosted system gives the organization more infrastructure control, but also makes it responsible for availability, upgrades, security patching, backups, compatibility with old mobile clients, and incident response.

Neither model is automatically better.

The important part is deciding whether infrastructure ownership is a real requirement or simply something that sounds attractive during evaluation.

The current shortlist looks roughly like this

Option	Model	Why a team might shortlist it
Expo EAS Update	Managed Expo service	A natural starting point when EAS already owns builds and releases. It uses `expo-updates`, runtime versions, channels and branches, supports gradual rollouts, and can roll back to a previous or embedded update. Hosted usage currently meters MAU and global edge bandwidth. (Expo Documentation)
Codemagic CodePush	Managed CodePush service	Keeps familiar CodePush concepts such as iOS/Android apps, Staging/Production deployments, target binary versions, promotion, percentage rollout, and rollback. Codemagic currently offers both successful-install and fixed-MAU pricing models. (Codemagic Documentation)
AppsOnAir CodePush	Managed CodePush-style service	Preserves a CodePush-shaped CLI and release model with target binary versions, percentage rollout, rollback, release metrics, immutable releases, and code signing. (AppsOnAir)
React Native Stallion	Managed service, with self-hosted enterprise option	Uses its own SDK, CLI, console, promotion workflow, phased rollout, pause/rollback and adoption tooling. Hosted plans currently use MAU and bandwidth allowances, while enterprise options include self-hosted deployment. (React Native Stallion)
Revopush	Managed CodePush-shaped service	A candidate for teams that want a CodePush-style migration but need modern React Native/New Architecture and Expo paths. Current docs use Revopush’s own newer SDK line for modern React Native, with rollout, client/server rollback, signing, and CI/CD integrations. Hosted pricing currently combines MAU and egress allowances. (Revopush)
Hot Updater	Self-hostable, plugin-based	Designed for teams that want to choose their own storage, database, build and hosting providers. Its current model includes channels, rollback, compatibility/fingerprint controls, and a pluggable infrastructure architecture. (Hot Updater)
Standalone CodePush server	Archived self-hosted CodePush	Keeps the classic CodePush protocol available for teams prepared to maintain it themselves. The Microsoft repository is archived, read-only, and unsupported, so the team owns ongoing infrastructure and maintenance. (GitHub)
Bundle Drop	Managed OTA service	Uses explicit runtime compatibility, channels, staged/property-targeted rollout, local recovery, and patch/full-bundle delivery. Current pricing does not meter MAU; plans are capacity-oriented instead. (npm)

The table is useful for building a shortlist.

It is not enough to make the decision.

Two platforms can both say “percentage rollout” while using different device identities, fallback rules, and constraints.

Two platforms can both say “rollback” while one means server-side release history and another also has device-local recovery.

Two platforms can both say “patch updates” while using very different baselines and fallback behavior.

The semantics matter more than the checkmark.

1. Test native compatibility before anything else

OTA only works safely inside a native compatibility boundary.

The installed binary must already contain every native capability the JavaScript update needs.

Different systems express this differently.

Expo uses runtime versions, and its update policy requires platform and runtime to match. (Expo Documentation)

CodePush-style systems historically use target binary version ranges.

Bundle Drop uses explicit per-platform runtime versions.

Hot Updater documents a fingerprint-based compatibility strategy.

The terminology matters less than the invariant:

an update must not reach a binary that cannot execute it.

During evaluation, deliberately change a native dependency or permission and prove that the old binary cannot accidentally receive JavaScript that depends on the new native state.

2. Measure migration distance

A team already running Microsoft CodePush has different priorities from a team starting fresh.

If preserving deployment keys, Staging/Production deployments, CLI commands, and the CodePush mental model matters, CodePush-compatible services deserve early attention.

Codemagic and AppsOnAir deliberately preserve much of that model. Revopush also offers a CodePush-shaped migration, although its current documentation uses Revopush’s newer SDK for newer React Native/New Architecture combinations. (Codemagic Documentation)

EAS Update is a different migration.

You adopt expo-updates, Expo runtime semantics, and the EAS channel/branch model. (Expo Documentation)

Bundle Drop, Stallion, and Hot Updater likewise introduce their own client and release models.

None of those is inherently worse.

But migration distance is a real engineering cost and should be treated as one.

3. Test release-selection semantics

Do not stop after proving that a 10% rollout “works.”

Test what happens to a device that is not in the 10%.

Does it stay on its current release?

Does it receive the previous eligible release?

Can another partially rolled-out release also be active?

Can the rollout percentage decrease?

How is cohort membership kept stable?

Stallion, for example, explicitly documents that the resolver checks the latest candidate and then at most the previous eligible release; if that previous release is itself partial, the user can receive no release. (React Native Stallion)

Codemagic’s CodePush model permits one active partial rollout per deployment and requires that rollout to be completed or stopped before another release proceeds. (Codemagic Documentation)

Expo’s current rollout model includes both per-update and branch-based rollouts. (Expo Documentation)

These are all legitimate designs.

They are not interchangeable.

4. Separate server rollback from device recovery

A dashboard rollback protects future release selection.

It does not automatically rescue a device that already activated a broken update and cannot get far enough to perform another successful update check.

This distinction is worth testing explicitly.

Revopush’s documentation, for example, describes both client-side automatic rollback and server-side rollback. (Revopush)

Codemagic’s CodePush documentation similarly separates automatic client rollback from manual server rollback. (Codemagic Documentation)

Bundle Drop’s current SDK records startup attempts natively, can quarantine a repeatedly failing candidate locally, and falls back to a known-good OTA or embedded bundle without requiring the network during startup. (npm)

Whatever product you evaluate, test both failure windows.

5. Treat patches as transport, not release identity

Differential delivery is useful because many OTA updates change only a small part of the final artifact.

But production fleets do not all have the same history.

Some users skip releases.

Some reinstall.

Some roll back.

Some remain outside a staged cohort.

So ask what happens when a patch baseline is unavailable.

Can the client obtain a complete artifact instead?

How is the reconstructed result verified?

What happens after an interrupted patch?

The safe release identity should not depend on one optimization path succeeding.

This is one area where product implementations differ substantially, so it deserves a device test rather than a feature-matrix check.

6. Check observability before the first incident

Once OTA exists, app version alone no longer identifies the running JavaScript.

Two users may both report native version 4.3.0 while running different OTA releases.

A useful system should let you connect:

release identity,

runtime compatibility,

download/install state,

crash reports,

rollout state,

and rollback outcomes.

If an error tracker says “4.3.0 crashed,” you should be able to determine which JavaScript artifact was actually executing.

7. Compare total operating cost, not the cheapest headline price

OTA pricing currently uses several models.

Expo meters MAU and global edge bandwidth. (Expo Documentation)

Codemagic offers successful-install and fixed-MAU models. (Codemagic Documentation)

Revopush currently combines MAU and egress allowances. (Revopush)

Stallion’s hosted tiers combine MAU and bandwidth allowances. (React Native Stallion)

Bundle Drop currently does not price plans by MAU and instead uses capacity-oriented limits such as storage, projects, and organization size. (Bundle Drop)

Self-hosted software moves part of the bill elsewhere: infrastructure, engineering time, monitoring, backups, security maintenance, and on-call.

The useful cost model therefore uses your actual release pattern:

bundle sizes,

release frequency,

number of active installations,

expected adoption,

storage retention,

and operational ownership.

A better evaluation than a feature matrix

If I were comparing OTA platforms for a production React Native app, I would put two or three candidates through the same acceptance test:

Integrate each into an actual iOS and Android release build, not only a development client.
Publish a harmless JavaScript + asset update and prove exact native/runtime compatibility.
Start a partial rollout and verify cohort stability and fallback behavior for an installation that is not selected.
Interrupt or invalidate delivery and confirm the currently working bundle stays active.
Activate a deliberately failing candidate, test local recovery, then perform a separate server rollback.
Verify that crash reports and release telemetry identify the exact active JavaScript artifact.
Model one year of cost using the application’s expected update cadence and operating requirements.

The winner should be the system whose behavior your team can explain and operate.

Not the product with the longest feature table.

Where Bundle Drop fits

Disclosure: I build Bundle Drop, so it is one of the products in this comparison.

Bundle Drop is currently a managed option for Expo and bare React Native, with explicit native/runtime compatibility, named channels, staged and property-targeted release selection, native startup recovery, and hybrid patch/full-bundle delivery. Its public npm package is currently 0.7.0. (npm)

It is not the natural choice for every team.

If EAS already owns your release workflow and you want to stay inside the Expo update protocol, EAS Update should be near the top of the shortlist.

If preserving the existing CodePush mental model minimizes your migration cost, CodePush-compatible managed services deserve serious evaluation.

If self-hosting is a hard infrastructure requirement, evaluate systems designed around that ownership model.

The useful goal is not finding a universal CodePush successor.

There isn’t one.

The useful goal is choosing an OTA system whose compatibility, release-selection, recovery, delivery, observability, and ownership semantics match the way your team actually ships React Native applications.

The first-party pages I used for the verification pass are available here: Microsoft App Center retirement notice, Expo EAS Update documentation, Codemagic CodePush production controls, AppsOnAir CodePush FAQ, React Native Stallion documentation, Revopush documentation, Hot Updater documentation, and Bundle Drop npm package.

How to Compare React Native Bundles Between Releases

George Fean — Thu, 03 Sep 2026 01:36:52 +0000

A React Native bundle-size regression usually starts with a disappointingly vague observation:

The bundle got bigger.

Maybe yesterday’s Android production bundle was smaller.

Maybe a pull request added a dependency.

Maybe a framework upgrade changed Metro output.

Maybe one feature imported far more code than expected.

The total size tells you that something changed.

It does not tell you what changed.

That distinction is why I think bundle analysis becomes much more useful when it is treated as a comparison problem, not just a visualization problem.

A treemap can answer:

What is inside this build?

A proper comparison should answer:

What changed between these two builds?

Those are different questions.

Bundle Drop Sight supports both workflows, but the approach itself is useful regardless of which analyzer you use: generate comparable production artifacts, attribute the output through matching source maps, and compare source identities rather than eyeballing two unrelated screenshots. (Bundle Drop)

Start with two complete build pairs

A React Native comparison is not:

old.bundle
vs
new.bundle

Each bundle needs its own matching source map.

Conceptually:

Baseline build
├── production JS bundle
└── matching source map

Current build
├── production JS bundle
└── matching source map

The source map matters because the generated JavaScript bundle no longer maps cleanly to the original TypeScript or JavaScript files by inspection alone.

Metro transforms modules, wraps code, resolves dependencies, and emits generated JavaScript.

The source map connects generated positions back to source identities.

That lets an analyzer ask a narrower and much more useful question:

How many bytes in this generated bundle are associated with each mapped source? (Bundle Drop)

Those numbers describe generated JavaScript ownership.

They are not the file sizes of your original .tsx files, and they are not the size of the final .ipa, .apk, or .aab.

That distinction is important when interpreting the result.

The source map has to match the bundle

Source maps are positional.

A map from one build can still be perfectly valid JSON while being the wrong map for another build.

A tiny code change can shift generated positions throughout a minified bundle.

So the baseline bundle needs the baseline source map.

The candidate bundle needs the candidate source map.

For useful comparisons, also keep the build conditions equivalent:

same platform
same entry point
same Metro configuration
same development flag
same minification setup

If you compare an Android production bundle against an iOS bundle, or a minified build against a differently configured build, the delta may be dominated by the build process instead of the code change you are investigating. (Bundle Drop)

There is one obvious exception: if the Metro or build configuration change is exactly what you are trying to measure, then changing that variable is intentional.

Otherwise, keep the environment boring.

Analyze both builds before comparing them

A useful comparison begins by treating each build as a complete analysis.

For each bundle, generated bytes can be grouped into areas such as:

Application code
Dependencies
Metro / runtime
Unmapped output

This matters because a total delta alone can still hide the interesting part.

Suppose the bundle increased by 150 KB.

That might actually mean:

Application code     +90 KB
Dependencies        +180 KB
Metro/runtime          0 KB
Unmapped             -20 KB
Removed dependency  -100 KB

Now there is something to investigate.

The total change is only the final sum.

The category changes tell you which direction to look first. Sight’s current attribution model keeps application code, dependencies, runtime output, and unmapped bytes explicit instead of silently discarding unattributed output. (Bundle Drop)

Match source identities, not treemap positions

One mistake I would avoid is opening two treemaps side by side and trying to visually spot the difference.

Treemap layouts are relative.

If one package grows, several unrelated rectangles may move or change shape even though their own size barely changed.

Rankings can also move.

So:

baseline screenshot
+
current screenshot

is a weak diff.

A better comparison matches stable identities.

Sight Compare currently analyzes the baseline and current build independently, then matches normalized package and file identities.

For each matched entry it can record:

before bytes
after bytes
signed delta
percentage change
state

where state can be:

added
removed
increased
decreased
unchanged

That makes the investigation much closer to a source diff than a visual guessing exercise. (Bundle Drop)

Sort by absolute change first

When investigating a regression, I would not immediately sort by “largest file.”

The largest package in the application may have existed for years and have nothing to do with the current change.

Instead, start with the largest absolute deltas.

A package moving from:

600 KB → 603 KB

is probably less interesting than a package moving from:

20 KB → 170 KB

even though the first package remains much larger overall.

Likewise, inspect decreases.

Suppose a dependency upgrade adds 200 KB but removes another 180 KB library.

Looking only at additions can make the release look much worse than the actual net change.

A comparison should help you understand the complete movement of bytes rather than produce a blacklist of whatever currently occupies the most space.

Trace the regression down one level at a time

A useful workflow is:

Total bundle delta
        ↓
Category delta
        ↓
Package delta
        ↓
File delta
        ↓
Source / feature being reviewed

Imagine a pull request increases the bundle by 240 KB.

The category view says nearly all of it came from dependencies.

One newly added package accounts for 210 KB.

Inside that package, two modules contribute most of the generated output.

Now the review can ask concrete questions:

Did we intentionally add this dependency?

Are we importing the broad package entry point?

Is a smaller subpath available?

Did the package replace code elsewhere?

Is the cost justified by the feature?

That is a much better discussion than:

“Can we somehow reduce bundle size?”

Bundle analysis should produce investigation paths, not automatic architectural verdicts.

A large dependency may be entirely justified. The useful part is knowing that the cost exists and where it came from. (Bundle Drop)

A practical pull-request workflow

The workflow I would use for a meaningful change is straightforward.

Generate a production baseline from the target branch or last accepted release.

Generate the candidate using equivalent build settings.

Keep each bundle beside its matching source map.

Open both build pairs in Compare mode.

Review the total and category changes first.

Then filter to changed, added, or removed entries.

Inspect the largest absolute package and file deltas.

Search for the feature, package, or source path involved in the pull request.

Finally, export the result if the explanation belongs in the PR or release record. (Bundle Drop)

The goal is to turn:

Bundle increased by 312 KB.

into something closer to:

The feature added application code, introduced package X, removed package Y, and most of the net increase comes from two specific source groups.

That explanation is reviewable.

The raw total is not.

Keep the baseline meaningful

A comparison is only as useful as the baseline.

For pull requests, main or the target branch is often the obvious baseline.

For release engineering, the previous accepted production release may be more useful.

For a large dependency migration, you might intentionally preserve the pre-migration build as a long-lived reference.

What matters is that the baseline represents a state the team understands.

If the baseline itself contains several unrelated pending changes, the comparison becomes harder to interpret.

Bundle-size analysis works best when the question is narrow:

What did this release change relative to the state we intended to compare against?

Export the explanation, not the source map

Source maps can be sensitive engineering artifacts.

They may contain source paths and may include sourcesContent, which can contain original source text.

That is one reason Sight performs its analysis locally in the browser: the selected production bundle and source map are not uploaded to Bundle Drop. The same local-only boundary applies to the analysis and report generation. (Bundle Drop)

The normalized result can then be exported as evidence.

Sight currently supports local reporting formats including PDF, standalone HTML, Markdown, normalized JSON, and relevant image exports. (Bundle Drop)

That can be useful for attaching an explanation to:

a pull request
a release review
a dependency migration
an architecture discussion

But exported reports can still reveal package names, source paths, and size information.

Local analysis reduces the source-code exposure boundary.

It does not make every resulting report safe to publish publicly.

Do not turn bundle bytes into a performance score

Bundle size is useful evidence.

It is not a complete performance model.

A smaller module can execute much more expensive work than a larger one.

Generated-byte attribution does not directly measure:

startup CPU time
memory pressure
rendering cost
runtime network behavior
native binary size
compressed transfer size
Hermes bytecode size

Metro configuration, Babel transforms, platform resolution, and tree-shaking behavior can also change generated output. (Bundle Drop)

So if the application starts slowly, use runtime and native profiling tools.

If the question is dependency graph structure or transformed modules, Expo Atlas may be the more appropriate tool.

If the question is:

Where did these generated JavaScript bytes come from, and what changed since the previous build?

then source-map-based comparison is a good fit. (Bundle Drop)

Analyze and Compare solve different problems

This is the distinction I find most useful.

Analyze asks:

What is inside this build?

That is good for understanding composition, large packages, large application files, and unattributed output.

Compare asks:

What changed?

That is better when a pull request, dependency upgrade, or release unexpectedly moves the total.

Bundle Drop Sight exposes both workflows, but they are intentionally separate because a current-state inspection and a regression investigation are different engineering tasks. (Bundle Drop)

Sight is available here: Open Bundle Drop Sight

It is free, requires no account, and analyzes the selected bundle and source map locally in the browser. (Bundle Drop)

I originally built Sight while working on Bundle Drop’s React Native and Expo release tooling, but the analyzer does not require Bundle Drop OTA and is useful independently of it.

The technical source explaining attribution, matching, comparison, exports, privacy, and limitations is: How to Analyze a React Native Bundle with Source Maps

The useful goal is not automatically making every bundle smaller.

It is being able to explain why it changed before that change becomes a release surprise.

Managed vs Self-Hosted React Native OTA: Compare the Ownership Boundary

George Fean — Wed, 26 Aug 2026 23:19:55 +0000

“Managed or self-hosted?” sounds like an infrastructure question.

For React Native OTA updates, it is really an ownership question.

Both approaches can deliver compatible JavaScript and bundled assets to installed applications.

Both can support channels.

Both can support rollouts.

Both can support rollback.

Both can use object storage and CDNs.

The important difference is not where the JavaScript file physically lives.

It is:

Who is responsible when the release path stops behaving correctly?

A managed service puts much of the OTA platform operation behind a provider boundary.

A self-hosted system moves that responsibility into your organization.

The safety requirements do not disappear.

The ownership boundary moves. (Bundle Drop)

The mobile team still owns compatibility either way

One responsibility cannot really be outsourced:

deciding whether a release is compatible with the native binary already installed on the device.

React Native OTA can replace JavaScript and bundled assets.

It cannot add a native module, permission, entitlement, engine, or compiled capability to an application that users already installed.

So whether the OTA infrastructure is managed or self-hosted, somebody on the application side still needs to decide:

Can this binary safely execute this update?

Bundle Drop expresses this with runtime gating, but the principle is provider-independent.

The current SDK only delivers updates that match the installed app’s native/runtime identity, and native changes still require another App Store or Play Store build. (npm)

Self-hosting gives you more control over how that compatibility rule is implemented.

It does not remove the need to define the rule correctly.

Compare responsibilities, not labels

“Self-hosted” covers a wide range of systems.

One company may run an existing open-source OTA server on infrastructure it already knows well.

Another may build a custom control plane around S3, a database, CDN infrastructure, signing keys, and an internal deployment platform.

Likewise, “managed” can mean different service boundaries depending on the provider.

The more useful comparison is the responsibility map.

Area	Managed OTA	Self-hosted OTA
Native integration	App team	App team
Compatibility policy	App team	App team
Control-plane availability	Provider	Your organization
Artifact infrastructure	Provider operates it	Your organization operates it
Server upgrades	Provider	Your organization
Backups and restores	Provider contract	Your organization
Service security patching	Provider	Your organization
Custom topology	Limited to supported model	Potentially very flexible
Incident response	Shared boundary	Internal ownership

This is not a scorecard.

A small mobile team can benefit enormously from standardized managed behavior.

A regulated organization with an established platform team may legitimately need infrastructure inside a particular region, network boundary, or internal identity system.

The question is which responsibility boundary fits the organization you actually have. (Bundle Drop)

Mobile clients make self-hosting different from running a normal web API

There is a complication with OTA infrastructure that is easy to underestimate.

Your clients cannot all be upgraded when the server changes.

A backend team can often deploy a coordinated frontend/backend change within a controlled window.

A mobile fleet is different.

Users keep old store binaries.

Some update immediately.

Some wait weeks.

Some managed devices wait much longer.

That means a self-hosted OTA server may need to preserve protocol behavior for several generations of installed clients at the same time.

A server migration therefore needs questions such as:

Which old binaries still exist?

Which manifest or download contracts do they understand?

How long must those contracts stay available?

What happens if the database schema changes?

Can a new server version still support rollback for an older client?

The canonical Bundle Drop comparison explicitly calls this out: in a self-hosted model, the team may be responsible for coordinating client and server protocol compatibility while old store binaries remain active. (Bundle Drop)

This is one of the biggest differences between:

“I can run this server.”

and:

“We can operate this release system for the next three years.”

Object storage is not an OTA platform

The easiest part of an OTA system is often putting an artifact somewhere downloadable.

A bucket plus CDN can solve storage and transfer.

That is not the complete release path.

A production OTA system also needs deterministic release selection, compatibility enforcement, artifact integrity, lifecycle management, rollback behavior, retries, safe activation, telemetry, access control, and incident recovery. (Bundle Drop)

Consider what happens when:

the database is healthy but object storage is degraded;

the artifact exists but the signing credential expired;

a device downloads only part of a bundle;

the control plane chooses the wrong runtime line;

a CDN still serves a release that was revoked;

or the service restores metadata from backup without restoring the matching artifacts.

Those failures are not theoretical implementation details.

They are part of the service you are choosing to own.

A self-hosted design gives you direct control over how they are handled.

It also makes your team responsible for testing them.

Release controls need an operator behind them

Channels, staged rollout, targeting, and rollback look like product features.

Operationally, each one is a state machine.

Take staged rollout.

A percentage value by itself is not enough.

The system needs deterministic eligibility.

It needs to know what happens when a device falls outside the newest release’s percentage.

It needs to handle paused releases, targeting rules, revoked artifacts, and several runtime versions on one channel.

Rollback also has more than one time horizon.

Changing server-side release selection helps devices when they next successfully check for an update.

It does not automatically rescue a device that already installed broken JavaScript and now fails before it can make another successful server request.

That requires local recovery behavior and a known-good fallback.

Bundle Drop’s current public model separates those two concerns: server-side release control and local rollback safety both exist, while the complete embedded/native bundle remains part of the recovery model. (Bundle Drop)

In a managed system, the provider implements and operates the release-selection machinery.

In a self-hosted system, your organization owns the correctness of that machinery.

That is often where the real cost of customization appears.

Patch delivery adds another operational path

Patch-sized downloads are attractive because many OTA releases change only a small fraction of the bundle.

But patches introduce another condition:

the device needs a suitable starting state.

A production fleet will contain installations with different histories.

Some users missed a release.

Some installed a fresh binary.

Some rolled back.

Some were outside an earlier rollout cohort.

So an optimized patch route needs a defined fallback.

Bundle Drop’s current public SDK treats patch transport as an optimization: it reconstructs and verifies the complete target bundle, and if patch transport is unavailable or fails, it can fall back to the signed full ZIP. (npm)

A self-hosted implementation can use any transport design it wants.

But somebody must own the failure semantics.

What if the patch artifact was cleaned up?

What if the source state does not match?

What if reconstruction fails?

What if the patch generator and client support different algorithms?

The bandwidth optimization becomes another production subsystem.

Observability is part of the OTA platform

OTA creates a debugging problem that normal store releases do not have.

Two devices can report the same native application version while running different JavaScript releases.

So:

App version: 4.2.0

is no longer enough to identify the running code.

You need the active OTA release identity as well.

Bundle Drop currently exposes the active bundle identity and observability context specifically so error trackers can associate a crash with the correct source map and JavaScript release. Its docs recommend using the OTA bundle hash to connect runtime reports with the corresponding source map. (Bundle Drop)

A self-hosted platform needs an equivalent model.

You should know:

Which release is running?

Which runtime line does it belong to?

Which channel selected it?

Did the download succeed?

Did verification succeed?

Was the candidate staged but not yet active?

Did a rollback happen?

Without that information, operating your own infrastructure may give you more server visibility while making application incidents harder to understand.

Access control and audit belong in the design too

Once OTA becomes a production release mechanism, publishing is a privileged operation.

So is rollback.

So is revocation.

So is deleting artifacts.

So is changing a rollout from 5% to 100%.

A self-hosted platform therefore needs more than authentication.

It needs a clear authorization model.

Read access and release-changing access should not automatically be equivalent.

Operator actions should be attributable.

Audit history needs retention.

Credentials need rotation.

CI credentials need narrower permissions than human administrators where possible.

These concerns may not matter during the first internal proof of concept.

They matter a lot after OTA becomes part of the normal production-release path. (Bundle Drop)

Open source does not mean zero operating cost

One of the weakest comparisons between managed and self-hosted infrastructure is:

Managed service: $X / month
Self-hosted software: $0

That measures software licensing.

It does not measure operating cost.

Self-hosting may still be the cheaper choice for a team that already has mature infrastructure for:

deployment;

identity;

object storage;

databases;

monitoring;

backups;

on-call;

incident response;

security patching.

For that organization, the marginal cost of another service may be small.

For a mobile team without that platform foundation, the engineering time required to create and maintain the same safety envelope can be much larger than the infrastructure bill.

The inverse is also true.

A managed service should not automatically be assumed to be cheaper.

Provider pricing, supported regions, limits, migration options, and organizational constraints all matter.

The useful comparison is total operating cost over the lifetime of the system, not subscription price versus server price. (Bundle Drop)

Time-to-integrate is not time-to-operate

A proof of concept answers:

Can this app download and launch an update?

Production readiness asks much more.

Can you upgrade the server without breaking old store binaries?

Can you restore both metadata and artifacts?

Can you rotate credentials?

Can you detect a release-selection incident?

Can you recover from object-storage failure?

Can you identify which JavaScript release caused a crash?

Can you roll back while part of the fleet is offline?

Can the embedded bundle still start if the OTA service is unavailable?

A managed service does not remove all of those questions.

It changes who owns large parts of the answer.

The app team still needs native integration, runtime policy, rollout practice, source-map handling, incident procedures, and SDK upgrades.

Self-hosting adds platform operation on top of those responsibilities. (Bundle Drop)

When self-hosting is the stronger fit

Self-hosting starts to make sense when control is an architectural requirement rather than a preference.

For example, an organization may have hard data-locality requirements.

It may need a particular isolated network topology.

It may already have an internal identity and release-control platform that every production service must use.

It may need custom protocol or rollout behavior that available managed services cannot provide.

And—critically—it may already have a named platform team willing to own the service.

That last part matters.

“I want control” is not the same requirement as:

“This team accepts availability, security, backups, upgrades, protocol compatibility, and on-call ownership.”

When managed OTA is the stronger fit

A managed service is often the better fit when the mobile team wants to own release policy without owning another production platform.

The team still decides:

which native changes require a new binary;

which runtime is compatible;

which release should go to production;

which audience should receive it;

when to pause or roll back.

But the team does not also need to operate the underlying OTA service.

That trade can be especially valuable when the mobile team is small and the release controls offered by the provider already fit the application’s requirements.

Six questions that usually make the decision clearer

Before choosing, assign an explicit owner to these questions:

Who gets paged when update checks or artifact downloads fail?
Who upgrades the OTA service and proves old store binaries still work afterward?
Who restores release metadata and artifacts after a failure?
Who rotates delivery or signing credentials without breaking installed apps?
Who validates rollout, rollback, and fallback behavior after React Native, Expo, iOS, or Android changes?
Which requirements truly need custom infrastructure rather than simply feeling nicer to control?

If the answers are obvious, the deployment choice usually becomes easier.

If nobody owns them, “self-hosted” is currently describing a topology rather than an operating model. (Bundle Drop)

Where Bundle Drop fits today

Disclosure: I built Bundle Drop.

Today, Bundle Drop should be evaluated as a managed OTA service.

Its public SDK currently documents Expo and bare React Native support, runtime gating, channel-based distribution, targeted rollouts, rollback safety, hybrid patch/full-bundle delivery, observability metadata, and CI/CD publishing. (npm)

Self-hosting is part of the project’s longer-term direction.

There is no announced availability date and no currently supported self-hosted Bundle Drop deployment.

So a team with a hard self-hosting requirement today should evaluate systems that satisfy that requirement today rather than planning around an unannounced future capability. (Bundle Drop)

That limitation is important.

Infrastructure ownership is an architectural constraint.

It should not depend on roadmap assumptions.

Choose the boundary your team can sustain

Managed and self-hosted OTA can both be reliable.

They move responsibility to different places.

Managed delivery trades some infrastructure control for an operated service boundary.

Self-hosting trades provider dependence for greater operational responsibility and customization.

The right choice is not the architecture that is easiest to demo.

It is the one your organization can still understand, maintain, secure, and recover during an incident years after the first successful OTA update.

Originally published on Bundle Drop Resources:

https://bundledrop.app/resources/managed-vs-self-hosted-ota

Runtime Versions: The Compatibility Boundary for React Native OTA Updates

George Fean — Wed, 19 Aug 2026 23:50:20 +0000

A React Native application is not one artifact.

The binary users install from the App Store or Play Store contains native code, native dependencies, platform configuration, a JavaScript engine, and an embedded JavaScript bundle.

An OTA release replaces only part of that system: the JavaScript bundle and compatible bundled assets.

That creates the most important safety question in any React Native OTA system:

Can this new JavaScript safely execute inside the native binary already installed on the device?

A runtime version exists to answer that question.

In Bundle Drop, runtimeVersion names the native compatibility boundary. An OTA bundle is only eligible when its platform and runtime version match the installed binary. It is not a “newer than” comparison and it is not simply another app version.

App version and runtime version solve different problems

It is tempting to reuse the application version for everything.

For example:

App version: 4.2.0
Runtime version: 4.2.0

That may be convenient for a particular release strategy, but the two concepts are different.

The application version answers something like:

Which product release is this?

The runtime version answers:

Which native interface can this JavaScript safely run against?

Multiple JavaScript releases can therefore exist inside the same native runtime.

And two native app releases can sometimes share a runtime if their native compatibility surface is unchanged.

Bundle Drop records both kinds of identity separately; its CI result metadata, for example, includes the application version and runtimeVersion as distinct fields.

That separation matters because otherwise the OTA compatibility model becomes coupled to product-versioning decisions that may have nothing to do with native safety.

Keep the runtime when the native boundary did not change

Suppose your current configuration looks like this:

module.exports = {
  runtimeVersion: {
    ios: "4.2-native-1",
    android: "4.2-native-1",
  },
};

You fix some TypeScript logic.

Or change copy.

Or adjust styling.

Or add a screen built entirely from native capabilities that already exist in the installed binary.

Those changes do not necessarily create a new compatibility boundary.

The existing binaries already contain what the new JavaScript needs.

So the runtime can remain unchanged.

Bundle Drop’s current public model explicitly recommends keeping a platform’s runtime literal stable for OTA-compatible JavaScript and asset changes.

Bump the runtime when JavaScript can depend on new native state

Now imagine adding a new iOS native module.

The next JavaScript release imports that module.

Older iOS binaries cannot safely run the new bundle because the native module simply does not exist inside them.

Changing the OTA runtime label does not magically install the module.

The correct sequence is:

change the native code;
create a new iOS runtime line;
build and distribute a new iOS binary;
publish OTA updates that depend on the new native capability only to that runtime.

The old binary continues on its previous compatibility line.

This same logic applies to changes such as native dependencies, permissions, generated native configuration, JavaScript-engine changes, architecture changes, or Expo config-plugin output that materially changes the native projects.

A runtime version is a gate, not an upgrade mechanism.

iOS and Android do not have to move together

This is one of the most useful properties of a per-platform runtime model.

Suppose you add a native dependency only on iOS.

You might change:

runtimeVersion: {
  ios: "4.2-native-1",
  android: "4.2-native-1",
}

to:

runtimeVersion: {
  ios: "4.2-native-2",
  android: "4.2-native-1",
}

Android has not gained or lost any native capability.

There is no compatibility reason to force it onto a new runtime line.

Bundle Drop’s canonical runtime article explicitly models these as independent lanes: an iOS native change can advance iOS while Android continues resolving the previous Android runtime.

This is more than a configuration detail.

React Native teams frequently ship platform-specific native changes.

Forcing both platforms to advance every time one platform changes creates unnecessary runtime fragmentation and release bookkeeping.

Old and new binaries normally coexist

Publishing a new store binary does not mean every user installs it immediately.

Some users update quickly.

Some wait days or weeks.

Managed devices can lag even longer.

During that period, production can legitimately contain:

Older iOS binary
runtimeVersion = ios:4.2-native-1

Newer iOS binary
runtimeVersion = ios:4.2-native-2

Both binaries may continue checking the same production channel.

The important part is that each installation resolves only updates that belong to its own runtime line.

Bundle Drop’s public resource explicitly describes channels containing several runtime lines while installed binaries receive only the exact compatible platform/runtime combination.

This lets teams continue maintaining a safe OTA path for users who have not yet adopted the newest store release.

Runtime version and channel are different axes

Another common mistake is treating channels as compatibility boundaries.

They are not.

A channel answers:

Which release track should this app follow?

Examples might be:

develop
beta
production

The runtime answers:

Which native binaries can execute this update?

A production channel can therefore contain releases for multiple runtime lines.

Likewise, two binaries on the same runtime could follow different channels.

Bundle Drop documents these concepts separately because collapsing them creates awkward release models such as:

production-ios-v4-native2

where release track, platform and compatibility are all encoded into one string.

Keeping the axes independent produces a cleaner model:

Channel: production
Platform: ios
Runtime: 4.2-native-2

Each value answers one question.

A runtime bump should follow a native change, not compensate for uncertainty

It can be tempting to bump the runtime frequently “just to be safe.”

That is safe in one narrow sense: fewer binaries will be considered compatible.

But unnecessary runtime churn creates operational cost.

Every new runtime line creates another compatibility branch that may coexist in production.

Too coarse a boundary risks sending JavaScript to an incompatible binary.

Too fine a boundary creates unnecessary fragmentation.

The useful rule is:

Change the runtime when the native compatibility surface changed.

Do not use it merely as a release counter.

Expo introduces an authority question

Expo projects have another concept called runtimeVersion.

That means an OTA integration needs to be explicit about which value is authoritative rather than silently mixing two independent runtime calculations.

Bundle Drop’s default Expo setup uses the literal per-platform runtime values from bundle.drop.config.js, with those values embedded into the native build and used by uploads.

For advanced Expo workflows, the current public SDK also supports opting into Expo runtime authority. In that mode, Bundle Drop requires the runtime identity from the corresponding native build rather than guessing it during OTA publication; CI documentation describes using a matching local or EAS build receipt for that path.

The broader principle is useful even outside Bundle Drop:

one component should be authoritative for native compatibility.

If the build system and OTA publisher derive that boundary differently, you have created exactly the ambiguity the runtime version was meant to remove.

Runtime compatibility should be decided at release time

You do not want to discover a compatibility mistake because a production device crashed.

A useful release review asks:

Did native code change?
Did a native dependency change?
Did permissions or generated native configuration change?
Did the JavaScript engine or architecture change?
Did an Expo config-plugin change alter native output?
Did either platform change independently?

If the answer is yes, review that platform’s runtime before publishing the JavaScript release.

Bundle Drop’s setup and troubleshooting docs also surface runtime mismatches as a first-class delivery condition: an installation does not receive a bundle from a different runtime line.

That fail-closed behavior is important.

“No update available” is much safer than “run JavaScript against a native interface it was never built for.”

Runtime version is not enough by itself

Compatibility only answers whether a bundle can run.

It does not answer:

whether this is the correct release channel;
whether the installation belongs in a targeting cohort;
whether the staged-rollout percentage includes it;
whether the bundle passed integrity verification;
whether a previously installed update is healthy.

Those concerns need their own controls.

This is why production OTA systems usually have several independent dimensions:

Platform
Runtime compatibility
Channel
Targeting
Rollout state
Release identity
Health / recovery state

Runtime version is one of them, but it is arguably the first one.

If the native compatibility decision is wrong, the rest of the release controls cannot make the JavaScript safe.

A useful mental model

Think of a runtime version as a native contract identifier.

The installed binary says:

I provide native contract ios:4.2-native-1.

An OTA bundle says:

I require native contract ios:4.2-native-1.

If the contracts match, the release can continue through the rest of the eligibility process.

If they do not, the OTA bundle is not a candidate for that binary.

That model remains understandable whether the app has one store version or five active versions, whether iOS and Android move together or separately, and whether the release arrives through a development, beta, or production channel.

That is exactly what a good compatibility boundary should do.

The release rule to keep

OTA lets React Native teams move compatible JavaScript and assets independently from store binaries.

That independence only remains safe when the OTA system respects the native application underneath it.

Keep the runtime when the installed binaries already provide everything the update needs.

Create a new runtime line when the native interface changes.

Move only the platforms that actually changed.

And allow old and new runtime lines to coexist while users adopt the new store binary at their own pace.

Bundle Drop implements that model with literal per-platform runtime versions by default, plus an explicit Expo-authority option for teams that need it. The principle itself is provider-independent:

OTA compatibility should be explicit, stable and easy to explain during an incident.

Originally published on Bundle Drop Resources

Patch Delivery and Full-Bundle Reliability in React Native OTA

George Fean — Wed, 12 Aug 2026 08:21:05 +0000

Most OTA releases do not replace most of an application.

A production update might fix one conditional, adjust a request handler, or change a small group of bundled assets.

Yet with a full-bundle-only delivery model, every eligible device still downloads the complete JavaScript and asset payload.

That model is easy to reason about. It is also often wasteful.

Patch delivery solves that efficiency problem by transferring a representation of what changed instead of sending the entire release again.

But patches introduce another question:

What happens when the device cannot safely use the patch?

That is where OTA delivery becomes more interesting than simply calculating the smallest possible download.

A production system needs to optimize network transfer without making that optimization a requirement for reaching a valid release. That is the principle behind Bundle Drop’s hybrid approach: a patch can be the smaller route to a release, while the complete verified bundle remains available as the dependable route. (Bundle Drop)

Why patch delivery is useful

Imagine a large React Native application where a release changes only a few lines of JavaScript.

The generated production bundle still contains the rest of the application module graph, dependencies, framework code, and other unchanged content.

If the update system always sends complete bundles, the amount of data transferred is tied more closely to the size of the application than to the size of the change.

That matters because mobile networks are not uniform.

Users can be on metered connections, high-latency networks, unstable Wi-Fi, or background execution windows that disappear before a large download completes.

A smaller transfer generally spends less time exposed to those conditions and consumes less user bandwidth. (Bundle Drop)

The advantage compounds when a team ships frequently.

A sequence of small fixes does not need to mean repeatedly transferring the majority of the same JavaScript bundle to every device.

When a client has the correct starting state, a patch can make the transfer cost look much more like the release itself.

The patch has a dependency that a full bundle does not

A complete release bundle is self-contained from the client’s perspective.

If the platform and runtime compatibility rules match, the device can validate the artifact without reconstructing it from a previously installed OTA state.

A patch is different.

It describes a transition from an expected source state to a target state.

That means the source matters.

This sounds simple until you think about a real production fleet.

Some users skipped an earlier update.

Some installed the application recently and only have the bundle embedded in the App Store or Play Store binary.

Some were offline during a rollout.

Some received an earlier release and then recovered from it.

Others may have been in different rollout or targeting cohorts.

Production devices rarely form one perfect linear chain of versions. (Bundle Drop)

If a patch only works from version B to version C, a device currently running version A needs another route.

That should not automatically become an application error.

It can simply mean the optimized route is not appropriate for that device.

Treat patching as an optimization, not a release prerequisite

There are two obvious extremes.

The first is to always send complete bundles.

That gives every eligible device a self-contained artifact and keeps the delivery model simple.

The downside is repeated over-transfer.

The second extreme is to make patches mandatory.

That minimizes transfer size when the expected source state exists, but every patch prerequisite becomes part of deployment correctness.

Now you have to think about missing source versions, multiple patch paths, reconstruction failures, and devices whose local state does not match the expected chain.

A better model is to separate the destination from the transport.

The release is the complete verified result.

The patch is one possible way of getting there.

If the patch can safely produce that result, use it.

If it cannot, fetch the complete release instead. (Bundle Drop)

That gives the system an important invariant:

Every successful delivery path converges on the same verified release.

Release selection and transport are separate problems

Another useful distinction is between deciding which release a device should receive and deciding how that release should be transferred.

A device might first be evaluated against:

channel, platform, runtime compatibility, rollout percentage, targeting rules, and release state.

Only after the system selects an eligible release does patch availability matter.

Two devices can therefore be eligible for the same release but receive it differently.

One may already have a suitable source bundle and use an optimized patch.

Another may need the complete bundle.

Both should converge on the same target release.

Bundle Drop’s current upload documentation reflects that separation: uploads become versioned OTA bundles, patch optimization is prepared afterward, and eligible installations can use the full bundle while patch work is still being prepared. If patching is not efficient, the system deliberately uses the full bundle instead. (Bundle Drop)

Verification matters more than transfer size

A patch being small does not make it safe.

A successful HTTP response does not make it safe either.

The useful boundary is whether the intended complete target exists locally and has passed the validation required before staging.

A patch can download correctly and still fail to reconstruct the expected result.

A transfer can be interrupted.

Local data can be incomplete.

The device can run out of storage.

The application can be terminated midway through work.

Those are ordinary failure modes in mobile software.

The system should have a binary outcome:

the complete intended release is present and verified, or the current working bundle remains active.

There should not be a halfway state where partially reconstructed content becomes executable. (Bundle Drop)

This is also why transport logic should ideally stay below the application-facing API.

Product code should be able to ask for an update and receive a staged release without branching into separate business logic for “patch mode” and “full bundle mode.”

The transport is an implementation decision.

The release state is the application concern.

Full-bundle fallback does not mean ignoring errors

Fallback is not magic recovery.

If the device has no usable connection, lacks storage, or cannot validate the complete artifact either, the update still cannot be staged.

The correct behavior is to keep running the existing verified bundle and try again later according to the application’s update policy.

The purpose of the full bundle is narrower:

a device should not be stranded just because the optimized patch route is unavailable.

That distinction matters.

Transport fallback handles a delivery-path problem.

It does not fix a bad release.

If the target JavaScript itself is faulty, that becomes a rollback or recovery problem instead. The canonical Bundle Drop resource explicitly treats transport reliability and release correctness as separate concerns. (Bundle Drop)

Progressive rollouts make mixed device states normal

Percentage rollouts intentionally create different device states.

During a staged rollout, some installations have the candidate release while others still run the previous one.

Targeted release rules can create additional valid branches.

Server-side rollbacks can change future release selection.

Device-side recovery can move an installation back to an earlier verified bundle.

In other words, the fleet becomes heterogeneous by design.

That makes a delivery model that assumes every device is always exactly one release behind increasingly fragile.

Patch optimization can still work well in that environment, but only when it is allowed to be conditional.

Devices that have the expected starting state use the smaller route.

Devices with different histories use the complete bundle.

The rollout system can then focus on release health instead of maintaining one perfectly uniform transport chain. (Bundle Drop)

Why this matters operationally

It is tempting to evaluate an OTA system by the smallest patch it can produce.

That is not a very useful production metric on its own.

A better set of questions is:

Can every compatible and eligible installation reach the release?

What happens when the optimized path cannot be used?

Does the current working bundle remain active after a failed delivery?

Do patch and full-bundle paths converge on the same staged result?

Are old and unusual device histories tested before broad rollout?

Those questions are less exciting than “our update was only 30 KB,” but they are much closer to the real job of release engineering. The source article makes the same point: predictable reachability and safe activation matter more than a perfect efficiency ratio. (Bundle Drop)

Optimize both, force neither

Patch delivery and full-bundle delivery are sometimes treated like opposing architectures.

They do not have to be.

A smaller transfer is useful because most releases change only part of an application.

A complete release artifact is useful because production devices do not share one clean history.

The two solve different problems.

Patches optimize transport.

Full bundles preserve an independent route to the release.

Verification decides whether the result can be staged.

That is the model Bundle Drop currently uses for React Native and Expo OTA delivery: the public SDK describes hybrid transport as maintaining full-bundle integrity while supported devices download patch-sized changes. (GitHub)

The important idea is broader than any one platform:

Bandwidth optimization should not become a new condition for deployment correctness.

The original technical resource for this article is:

https://bundledrop.app/resources/patch-delivery-full-bundle-reliability

Life After CodePush: Choosing an OTA Update Strategy for React Native in 2026

George Fean — Tue, 04 Aug 2026 22:55:03 +0000

Microsoft retired the hosted Visual Studio App Center service on March 31, 2025. That included the managed service many React Native teams knew through CodePush, although Microsoft also released a self-hostable CodePush server.

The service retirement did not remove the underlying need. Teams still want to fix JavaScript bugs, adjust UI, update copy, and ship compatible asset changes without waiting for a new App Store or Play Store release.

But choosing a replacement is not just a matter of finding a familiar sync() call. An OTA system becomes part of your production runtime and your release process. The important questions are about compatibility, failure handling, rollout control, and how much of the system your team wants to operate.

What an OTA system actually has to manage

An OTA update is not simply a file download. It is a decision about which code a particular installed binary can safely execute.

Native and runtime compatibility

React Native lets you change JavaScript without rebuilding the native application, but only while that JavaScript remains compatible with the native code already on the device.

Adding a native module, changing permissions, upgrading React Native, switching important native configuration, or changing a JavaScript engine can require a new binary. A production OTA system therefore needs a compatibility boundary—often called a runtime version—and must refuse to deliver an update across that boundary.

This is one of the easiest details to overlook in a proof of concept and one of the most important details in production.

Channels and release tracks

Most teams need more than one stream of updates. You may want production, beta, QA, internal, or customer-specific tracks.

A channel is useful only if its relationship to builds and updates is explicit. Teams should know which installed binaries read from which channel, how an update moves between channels, and whether promoting a tested release preserves its identity.

Safe rollout strategies

Sending an update to every eligible device at once is fast, but it gives you very little time to react.

Percentage-based rollouts let you expose a release gradually. Targeted rollouts go further by limiting eligibility using properties such as plan, region, or an internal beta flag. These controls solve different problems: targeting defines who is eligible, while staging controls how much of that group receives the update.

Rollback and recovery

A dashboard rollback is helpful, but device-side recovery matters too. Consider what happens when an update crashes before the app can check the server again.

A robust design should define:

when an update is considered healthy;
how repeated launch failures are detected;
whether the device can return to a last-known-good bundle;
whether the embedded bundle remains a final fallback; and
how a failed update is prevented from being retried on the same device.

The worst time to discover that rollback depends on a successful JavaScript launch is after shipping JavaScript that cannot launch.

Integrity verification

The client should verify that the downloaded artifact is exactly the artifact the service intended to deliver. That normally means secure transport plus cryptographic hashes or signatures, validation before activation, and an atomic transition so a partial install never becomes the active version.

Integrity and compatibility are separate checks. A perfectly downloaded bundle can still be wrong for a device if it targets a different native runtime.

Download size and bandwidth

Some systems deliver a complete JavaScript bundle and asset set for every update. Others support patches or asset-level deltas.

Patch delivery can reduce download size when a change is small, but it introduces another failure path. Ask whether the client reconstructs and verifies the complete target state and whether it can fall back to a full update when a patch is missing, unsupported, or invalid.

Operational visibility

At minimum, teams need to identify which release is running when an error occurs. Useful signals include bundle identifiers or hashes, adoption, download and install failures, rollout state, and source maps tied to the exact update.

OTA tooling should complement your crash reporter, not hide update identity from it.

The main approaches available

There is no universal winner. The right choice depends on your application model, operational appetite, existing tooling, and risk tolerance.

Expo Updates and EAS Update

The names are easy to blur together, so it helps to separate them:

expo-updates is the client library that loads compatible updates.
EAS Update is Expo's hosted cloud service for publishing and serving those updates.
EAS Build is a separate service that produces app binaries.

EAS Update supports Expo projects using Continuous Native Generation and existing React Native projects that install expo-updates. It uses runtime versions for native compatibility, supports staged rollouts, provides deployment insights, and lets teams republish a previous stable update.

For teams already standardized on Expo tooling, that integration can be a strong advantage. Evaluate the workflow conventions, update behavior, and pricing model against your needs rather than treating "uses React Native" as the only requirement.

Other managed OTA providers

A managed provider can reduce the amount of infrastructure your team owns. The tradeoff is that you are adopting the provider's runtime model, release controls, pricing dimensions, and migration path.

Compare providers on concrete behavior rather than broad feature labels. "Rollback," for example, might mean republishing an older release, switching a server-side pointer, or performing automatic recovery on the device. Those are not operationally identical.

Self-hosted or custom infrastructure

Microsoft's App Center retirement guidance points CodePush users to a self-hostable server. Expo also documents self-hosting for the updates protocol. A custom system can offer maximum control over data, cost, and release policy.

That control comes with ownership. Your team becomes responsible for artifact storage, signing, availability, client compatibility, rollout state, observability, abuse prevention, and incident response. Running an update server is not the same as safely operating an OTA lifecycle.

Self-hosting is a reasonable choice when the constraints justify it and the team is prepared to maintain it.

Store-only releases

Choosing not to use OTA is also valid.

Store-only releases keep the delivery model simple and ensure every code change passes through the normal binary pipeline. The cost is slower delivery for small fixes and less control over when users install them.

For apps with infrequent releases, strict review requirements, or a small operational team, that tradeoff may be appropriate.

Questions to ask before choosing

A useful evaluation should be specific enough that two engineers can reach the same answer from the documentation or a test.

Does it support our actual project shape: Expo, Expo Prebuild/CNG, EAS Build, or bare React Native?
How is native compatibility represented, and who is responsible for changing the runtime version?
Does every update download a full bundle, or can the client fetch a smaller patch when only part of the application changes?
If patching fails, is there a verified full-bundle fallback?
Are percentage rollouts available? Can targeting rules use application-defined user properties?
What happens if an update repeatedly crashes before startup completes?
Can the device recover without successfully running the new JavaScript?
Are channels, promotions, and rollback operations auditable?
Can source maps and release identifiers be connected to the existing error tracker?
Is pricing tied to monthly active users, bandwidth, storage, builds, seats, or some combination?
Can artifacts and release history be exported if the team later migrates away?
Which changes still require a store build?

A small failure drill is often more revealing than another feature checklist: publish a deliberately broken update to a test channel, then observe how rollout, detection, rollback, and device recovery actually behave.

Why I built Bundle Drop

Disclosure: I am the creator of Bundle Drop.

I built Bundle Drop because I wanted another managed option with an explicit compatibility boundary and a recovery model that remains useful when an update fails early.

Its delivery model prepares a complete verified bundle and, when possible, a smaller patch. A device can download the patch when only part of the application changed instead of downloading the full update every time. The client reconstructs and verifies the complete target state before activation. If patch transport is unavailable or fails, it falls back to the signed full bundle.

Bundle Drop also provides channels, staged rollouts, and targeting based on application-defined user properties. On-device health checks can return a failing update to the previous verified bundle, or to the binary's embedded bundle when there is no earlier OTA version.

For Expo, the integration is designed for Prebuild/CNG projects and normal EAS Build workflows. EAS Build still creates the application binary; Bundle Drop handles the OTA layer after that binary is deployed. The same runtime-version model also supports bare React Native.

The service's plans are not priced by monthly active users. That was an intentional choice because I wanted teams to evaluate rollout and storage needs without treating user growth itself as an OTA cost.

The documentation describes the runtime and release model, and the Expo integration guide covers config-plugin setup, CNG, EAS Build, and runtime authority. Bundle Drop is one option among several, and I would still recommend testing its failure behavior against your own release requirements before choosing it.

Choose for recovery, not just installation

Installation is the beginning of an OTA system, not the hard part.

Before committing to a provider or a self-hosted design, write down your native compatibility rule, rollout process, health signal, rollback path, observability requirements, and exit strategy. Then test those rules with real release builds.

The best choice is the one your team can understand and operate during an incident—not merely the one with the shortest setup guide.

If you are evaluating the post-CodePush landscape, I would be interested in hearing which operational requirements have mattered most to your team.