Rollbacks

Rollbacks are one of the main reasons to use CodePushGo. If a JavaScript bundle creates a production issue, move the channel back to a known-good release instead of waiting for a new native binary review.

What rollback changes

A rollback changes the release attached to a channel. It does not change native code, native modules, entitlements, permissions, or app-store binaries.

Caution

If the bad release depends on native changes that are already shipped, roll back only to a bundle compatible with that native binary.

Console rollback flow

1. Open console.codepushgo.com.

2. Select the app by its native bundle ID.

3. Open the channel that is serving the bad release.

4. Select the previous known-good release.

5. Save the channel target and monitor update stats.

Devices on that channel receive the rollback target on their next update check according to the normal update behavior.

Safer rollback process

Use this operating pattern for production incidents:

1. Pause further promotion to production.
2. Identify the last known-good JavaScript release.
3. Move the affected channel back to that release.
4. Watch download, install, and failure metrics.
5. Ship a corrected release through beta before promoting again.

CLI context

Use the CLI to inspect available releases before changing the channel in the console:

npx @codepushgo/cli@latest bundle list com.example.app --channel production

Then use the console to point production to the target release.

Native rollback still needs the stores

If the problem is caused by native code, a native module, permissions, signing, entitlements, or platform config, CodePushGo cannot fix it with a JavaScript rollback. Ship a new binary through Apple App Store or Google Play.