Skip to main content

Rollbacks

A rollback reverts a device from a bad release to a known-good one. Swiftpatch rolls back in three ways:

  1. Device-local — the SDK detects a crash loop and reverts on its own. No server involved.
  2. Server-initiated — you mark a release rolled back in the dashboard, and every device picks that up on the next check.
  3. User-initiated — your app calls rollback() explicitly.

1. Device-local rollback (automatic)​

The mechanism: the boot counter + mount marker. See Brick protection for the full details.

Triggers:

  • The freshly applied bundle crashes maxCrashesBeforeRollback times (default 2) in a row.
  • The JS layer calls Swiftpatch.onError with a crash-class error during the crash-detection window.
  • The native signal handler catches a segfault / abort.

Result: on the next cold start, the SDK reverts the active slot to the previous stable slot (or the binary slot if no stable is available), fires the ROLLBACK_PROD telemetry event, and the user is back to a working app.

Typical time to recovery: one cold-start cycle (a few seconds).

2. Server-initiated rollback​

You noticed a bad release in the dashboard and want every device off it, fast:

swiftpatch releases rollback r_abc123

This marks the release rolled back in the server's state. The next checkForUpdate from any device currently on that release will receive a appliedReleaseRolledBack: true signal and immediately revert locally.

Devices that had this release in the NEW slot but haven't applied yet will have the slot cleared. Devices already running it will revert on the next check (next cold start or resume).

3. User-initiated rollback (from your app)​

The low-level hook:

import { useSwiftPatch } from '@swiftpatch/react-native';

function SettingsScreen() {
  const { rollback } = useSwiftPatch();

  return (
    <Button
      title="Revert to previous version"
      onPress={async () => {
        await rollback();
        // App will boot on the previous stable slot on next launch.
      }}
    />
  );
}

rollback() reverts the active slot and fires the rollback event on the bus. You can drive your own UI off that event.

Rollback telemetry​

Every rollback — regardless of trigger — fires a ROLLBACK_PROD telemetry event with the following payload:

  • releaseId — the bundle being reverted from.
  • reason — boot_loop_limit | server_rollback | signature_invalid | user_initiated.
  • deviceId — for server-side correlation.
  • crashTrace — when the rollback was crash-triggered.

The dashboard clusters these events and surfaces a per-release rollback rate. When the rollback rate exceeds the channel's auto-pause-crash-rate threshold, the rollout auto-pauses.

Preventing rollback loops​

If the bundle you roll back to is also broken, the SDK falls one layer deeper:

New slot crashes → revert to Stable slot
Stable slot also crashes → revert to Binary slot
Binary slot always works (shipped with the store build)

The binary slot is the floor. Your app always boots.

Auto-pause on elevated rollback rate​

In the dashboard, each channel has an auto-pause-crash-rate policy. When the rollback rate for a live rollout exceeds this threshold, Swiftpatch:

  1. Pauses the rollout at its current percent (no new devices download the release).
  2. Fires an incident in the dashboard.
  3. Notifies release owners via email.

You can then either:

  • Rollback the release globally: swiftpatch releases rollback r_abc.
  • Investigate the crash cluster (AI-powered — see crash detection) and fix forward.

Next steps​

On this page