Comment on page
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.
- 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.
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.
The re-signing process used for rollbacks requires Runway to have access to the app binary file from the source version – the Provide build 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 onAndroid 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.
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)
The re-signing sequence is part of the Rollback build release step on rollbacks, and perfoms 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 TestFlight.
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 TestFlight 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 may 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 TestFlight 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.
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:
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.
- 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.
- 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.
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.
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.
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 excluding hotfixes, and excluding releases that required 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
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.
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