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.

Explaining rollbacks through an example

The example below assumes the following:

• 9.0.0 is the latest stable version on the app store that you're submitting to

• 10.0.0 is the version that you are preparing to ship

Runway will perform the following steps to prepare a rollback release:

• Runway will generate 10.0.1 , which is a copy of 9.0.0

• Since app stores only allow one app "in review" at a time, Runway will wait until 10.0.0 is approved, and then will submit 10.0.1 for review

• If 10.0.0 is submitted for review, approved, distributed to production, and there's a bug that requires a rollback, 10.0.1 will already be reviewed and ready to publish to production

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)

Re-signing strategies

When creating a rollback, you'll be prompted to choose a re-signing strategy from one of the following:

• Re-sign by Runway: Runway will edit your source version's binary to bump the version and then re-sign it using the signing key you've provided

• Rebuild by your CI: Runway will create a new branch for your rollback from the same commit as the source version's binary, edit your version files to bump the version, and then trigger your CI workflow to build the rollback binary.

Re-sign by Runway ensures that your rollback version is the same binary as the source version, just with a modified version and then re-signed. However, code signing is an intricate process and it may take some troubleshooting to ensure your binary is able to be re-signed by Runway.

Alternatively, the rebuild by your CI option lets you leverage the existing code signing that you've already set up on your CI/CD. We'll create your rollback from the same commit that was used to build the source version.

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. Depending on your re-signing strategy:

   1. Re-sign by Runway: Updates the build number & version string (version code and version name on Android) on the source version binary.

   2. Rebuild by your CI: Creates a branch for the rollback and edits your version files on that branch to bump the version

2. Once updated:

   1. Re-sign by Runway: re-signs the binary using your app's signing key.

   2. Rebuild by your CI: triggers your release candidate CI pipeline on the rollback branch to build a new binary.

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.