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.

Requirements

The re-signing process used for rollbacks requires Runway to have access to the app binary file from the source version – the Enable artifact downloads automation must be enabled and properly configured in order for Runway to access source version binary files that can be used for rollbacks.

Multi-build / multi-APK on releases on Android are currently not supported for rollbacks.

For the re-signing process to work, you must upload your app signing key to Runway. You can do this from App settings > Profiles and devices > Signing keys on iOS and App settings > Signing keys on Android. Signing keys are exclusively used for re-signing binaries – to read more about how we securely store signing keys, visit the Signing keys documentation.

And lastly, you must have an App store integration capability connected so Runway can upload rollback builds to the relevant app store.

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 six 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 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.

Creating rollbacks

There are two ways to prepare rollback releases: manually via the Prepare new > Hotfix flow, or via the Prepare rollbacks automation, which creates a rollback automatically for each standard release as soon as it's submitted for review.

Prepare a rollback manually

You can prepare a rollback manually by clicking Prepare new > Hotfix and choosing the Create a hotfix release by rolling back to a previous stable build option. You can optionally choose a source version that should be used for the rollback

When preparing a rollback manually, the last completed release is always assumed to be the target of the rollback (target version).

Once the rollback release has been created, you must start the re-signing sequence (Rollback build > Start re-signing sequence) to initiate the process of re-signing the source version build for the rollback and uploading it to the relevant app store. The re-signing sequence will take care of updating the version string and build number (version name and version code on Android) and uploading the re-signed build to the relevant app store.

Once the re-signing sequence is complete, you must manually submit the rollback version for review when needed.

Unlike normal releases in Runway, rollback releases wait until just before submission to create an edit version in App Store Connect and a production track release on the Play Console.

Automatically prepare rollbacks for each release

Give your team extra confidence when shipping regular releases by enabling automatic rollback preparation alongside each and every standard release. Runway can automatically start preparing a rollback release in the background alongside your regular releases, so rollbacks are ready to go at the click of a button should you need them.

To enable automatic rollback preparation, enable the Prepare rollback releases automation. Runway will automatically create a rollback release and start the re-signing sequence as soon as each standard release has been submitted for review.

When preparing rollbacks automatically, Runway will use the latest live release version as the source version. Hotfixes and releases that required a rollback will never be used as source versions for a rollback.

On iOS, you can choose to turn on the Submit automatically when all release steps are ready option, which will enable Runway to automatically submit rollbacks for review as soon as possible; when the target release has gone live. Once approved by Apple, your rollback will be ready to release in a single click if needed.

Runway can automatically clean up unused rollbacks by discarding them based on the stability of your target version. Configure rollout and stability conditions for the target version to meet in order for the rollback to be automatically discarded. For example, you might configure rollbacks to be automatically discarded if your target version reaches at least the third day of a phased rollout while maintaining a greater than 95.95% crash-free sessions rate.

Discard rollbacks conditions

Notifications

When preparing rollbacks automatically, notifications are suppressed for rollback releases throughout while the rollback is being prepared. A notification will be sent only once the rollback is ready to release (approved by Apple on iOS, and ready to submit on Android).

Discarding rollbacks

You can discard a rollback release at any time by clicking on the Convert to roll-forward hotfix action menu (...) and clicking Discard rollback.

Discard rollback button

On iOS, if a rollback has already been submitted for review, discarding the rollback will developer reject the submitted rollback.

On iOS, once a rollback release has been submitted for review, any upcoming releases will be blocked from being submitted until the active rollback is discarded.

Converting rollbacks to roll-forward hotfixes

In certain cases, you may prefer to issue a roll-forward hotfix which includes one or more fixes rather than rolling back a problematic release. To convert a rollback release into a roll-forward hotfix, click the Convert to roll-forward hotfix button on the Rollback build step.

You will be prompted with options for your roll-forward hotfix, which include the ability to immediately create a hotfix release branch off the target version’s tag, bump the version on the hotfix branch, and cherry-pick specific commits.

Convert to roll-forward hotfix options