Staged rollouts and instant rollback for React Native releases

Over-the-air updates are fast — which means a mistake is fast too. The two features that make OTA safe at scale are staged rollouts and instant rollback. Here's how to use them well.

Staged rollouts: don't ship to everyone at once

A staged rollout serves a new release to a deterministic percentage of devices. The key word is deterministic: the same device is bucketed the same way each check, so a user doesn't flip between the old and new bundle on successive launches.

A sensible pattern:

1. Publish at 5%. Watch adoption and crash signals.
2. If it's healthy after a few hours, widen to 25%, then 50%.
3. Go to 100% once you're confident.

With Pulsar that's a flag on publish, and a single command to widen:

pulsar release MyApp Production --platform ios --target 1.4.0 --rollout 5
pulsar patch MyApp Production v7 --rollout 50

Instant rollback: pulling a bad release

If something's wrong, you need to stop the bleeding immediately — not wait for a new build. Rollback disables the bad release so devices stop receiving it and fall back to the last good bundle:

pulsar rollback MyApp Production

Devices that already applied the bad bundle get the previous one on their next check; devices that hadn't applied it yet never do.

The missing piece: adoption metrics

Here's the trap most teams fall into: they assume "served" means "applied." It doesn't. A device can be served an update, start the download, and never actually run it — the app was closed before restart, the download stalled, or the bundle crashed and rolled back silently.

If your OTA service only counts what it served, a rollout can look successful while most users are still on the old code. That's why Pulsar reconciles what devices actually report running against what was served, so a stuck rollout is visible instead of silent.

A safe release checklist

• Target the binary versions your users are actually on.
• Start at a low rollout percentage.
• Watch adoption, not just the served count.
• Keep rollback one command away.
• Only widen once the new release is confirmed healthy.

Do that and OTA becomes what it should be: the fastest safe way to fix your app.

[See how Pulsar handles rollouts and rollback →](/codepush-alternative)