Rollbacks

This feature is limited to certain plans. Please visit our pricing page to learn more.

Rollbacks in Runway are special releases that use the build from a previous stable release, and, through an automated re-signing process, re-submit it as a new release version to quickly roll back problematic releases if needed.

Terminology

• Source version: the stable release version whose binary is reused for a rollback.

• Target version: the release version being rolled back.

• Rollback version: the release version of the rollback release.

How it works

Rollback releases in Runway are prepared by taking a previously released stable build (the source version) and running it though Runway’s re-signing process. This process updates the version string and build number (version name and version code on Android), re-signs the build with your signing key, and uploads it to the relevant store for re-submission as a new release version.

About rollback releases

Rollback releases in Runway are a streamlined version of a typical Runway release – out of the box, they’re made up of only seven release steps:

• Rollback build: details on the progress of the re-signing sequence and the source version upon which the rollback is based.

• Screenshots & Metadata: a read-only view of the screenshots and metadata from the source version that will be used for the rollback.

• Approvals: approval items that are relevant for rollbacks.

• App store steps (submission, review, release)

About the re-signing sequence

The re-signing sequence is part of the Rollback build release step on rollbacks, and performs the following automations in this order:

1. Updates the build number & version string (version code and version name on Android) on the source version binary.

2. Once updated, re-signs the binary using your app's signing key.

3. Uploads the re-signed rollback build to the Play Console or App Store Connect.

4. [iOS only] If the Apply beta testing notes automation is enabled, Runway will apply a special set of rollback tester notes to the build in TestFlight.

5. [iOS only] If the Upload dSYMs to stability monitoring automation is enabled, Runway will upload the dSYMs generated during the re-signing process to your stability monitoring integration.

The re-signing sequence will increment the build number / version code of the re-signed build as follows:

• iOS: the latest build for the rollback version will be fetch from App Store Connect and incremented by one

• Android: the highest version code on the production track will be fetched from the Play Console and incremented by one

On Android, rollback builds that display version name and version code anywhere in the app's UI will display the version name and version code of the source version.

On Android, uploaded rollback builds are not placed on a testing track once uploaded. Rollback builds uploaded to App Store Connect are by default distributed to the App Store Connect Users testing group.

Rollback releases by default use the screenshots and metadata from the source version. On Android, screenshots will only be updated on your app listing after the rollback has been submitted for review.

Rollback releases do not automatically get cadence target dates applied. Runway will also override your default app store release settings – rollbacks will always start out with phased release disabled so they can be rolled out to everyone immediately. You can always change this setting on any given rollback release from Release settings > Edit release settings in the App Submission step prior to submission.

Rollbacks and automations

Many of the automations that Runway performs on during a normal release cycle aren’t relevant for rollback releases, or have special behavior that’s unique to rollbacks. The following automations will appear inactive for rollback releases:

• Create release-specific channel(s)

• Kick off release on target date

• Trigger workflow after release kickoff

• Release app on target date

• Release stable phased releases to 100% of users

• Halt unstable phased releases

• Backmerge changes on release branches at the end of the release cycle

• Delete version-specific release branches at the end of the release cycle

• Cherry pick work from the working branch to the release branch

• Customized iOS phased rollouts

• Customized Android staged rollouts

• Promote new builds to testing track (Android)

• Assign beta testing builds to default testing groups (iOS)

• Apply beta testing notes to new beta builds

• Add missing labels or fix versions to tickets

• Mark releases complete in project management tool

• Prepare next version in Runway when current release is kicked off

• Add the latest available APK/AAB to the draft release on the Production track in the Play Console

Additionally, certain automations have special behavior for rollback releases. The following automations behave differently for rollback releases:

• Create and sync App Store Connect/Play Console versions as needed to match current Runway release: Runway will automatically create an edit version (iOS) or track release (Android) immediately prior to rollback submission.

• Select the latest build in App Store Connect: Runway will select the latest successfully re-signed build in App Store Connect as part of the submission process.

• Add the latest available APK/AAB to the draft release on the Production track in the Play Console: Runway will add the latest successfully re-signed build to the rollback production track release as part of the submission process.

• Apply 'What's New' text or release notes to new releases in App Store Connect or Play Console: Runway will apply the source version's "What's new" or release notes to the rollback release as part of the submission process.

• Submit app for review:

  • Android: the Submit app for review automation will appear inactive

  • iOS: the Submit app for review automation will only be active if the Submit automatically when all release steps are ready option on the Prepare rollbacks automation is enabled. Rollbacks will be submitted for review if all previous steps are green as soon as the target release has gone live. See Automatically prepare rollbacks for each release for more details.