What Rollback Is
Dashboard rollback stops a problematic OTA bundle from being offered on a channel. Devices discover the change on their next update check and can receive another eligible bundle compatible with their native runtime.
You do not need to build and publish a special reverse update. The replacement is selected from the channel's eligible releases; it is not necessarily the immediately preceding version.
This read-only walkthrough rolls back a sample release in production, then shows three apps following their configured update policies. The example has a compatible v41 replacement available; its timing is illustrative.
Roll back a release, then follow each app’s policy
Dashboard walkthrough- Review release
- Confirm rollback
- Devices check
- Follow app policy
Bundle DropChannel bundlesABundles for production
production- Runningv41
immediateDownloaded → applied immediately - Runningv41
on-next-launchNext cold launch → v41 active - Runningv41
manualApp calls applyUpdate() → v41 active
Native safety is separate: cold-launch recovery can use a verified healthy cached OTA or embedded bundle. Confirmed revocation with no safe compatible target can recover to embedded, even with manual or check-only.
Each sample app reaches v41 at its own activation boundary. These checks and app actions use condensed, illustrative timing.
Where to Do It in the Dashboard
- Open your project.
- Open the channel you want to manage.
- Go to that channel's Bundles page.
- Choose the bundle you want to roll back and confirm the action.
Rollback is channel-scoped. Rolling back a bundle on one channel does not revoke it on every other channel in the project.
How Rollback Works
After a device checks for updates, an eligible compatible replacement follows your app's selected update policy:
| Policy | When the replacement becomes active |
|---|---|
manual | Your app controls the download and calls applyUpdate() when it is ready. |
on-next-launch | Bundle Drop downloads and stages the replacement for the next app launch. |
immediate | Bundle Drop downloads and applies the replacement as soon as possible. |
A dashboard action does not push an immediate restart to every device. A device that is offline or has not checked yet may still be running the rolled-back release.
If the current bundle is revoked and no safe compatible OTA replacement is available, Bundle Drop can recover to the embedded bundle that shipped with the app. This safety recovery is separate from normal replacement updates and can occur even with manual or a check-only startup flow. Update policy does not disable native integrity or compatibility protection.
When Teams Use It
- Stop distributing a release with crashes or broken behavior.
- Move affected devices toward an eligible stable release.
- Contain an issue while preparing a fix-forward update.
Use your monitoring tools to check the impact, and test the replacement against the affected native runtime. Rollback cannot add native capabilities that were absent from the installed app binary.
Automatic Crash Protection
Bundle Drop also protects startup on the device. If an OTA bundle repeatedly fails to become healthy, native recovery restores a verified, previously healthy compatible OTA bundle, or the embedded bundle when no eligible previous OTA is available. This happens on a later cold launch and works offline.
This is separate from dashboard rollback and does not wait for your normal update policy. See Automatic Recovery for defaults, limits, and health configuration.
Manual Health Reporting
Manual health reporting lets your app mark startup healthy with BundleDrop.reportHealthy(). It is independent of the manual update policy. See the manual health reporting example.
Related Docs
- For on-device startup protection, see Automatic Recovery.
- For activation timing, see Update Policies.
- For release tracks, see Channels.
- For gradual release control, see Staged Rollouts.
- For publishing a fix, see Uploading.