Creating rollbacks
Requirements
App binary file
The re-signing process used for rollbacks requires Runway to have access to the app binary file from the source version; so 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.
Android: Rollbacks are currently supported for AABs. APKs or multi-build/multi-APK are not supported.
App signing key
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. It is required that the iOS signing key is the exact same as the one used to sign the IPA.
App store integration
You must have an App store integration capability connected so Runway can upload rollback builds to the relevant app store.
Getting started
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.
For both methods, there are two initial steps:
For your rollbackโs source version, Runway will need to have access to a CI build thatโs matched to the published app store build. You will also need the Enable artifact downloads automation to be enabled. This will ensure that the CI build matched to the source version's app store build shows the artifact that will be resigned.

Add a valid signing key in App settings.
For iOS, please ensure that the signing key is the exact one that was used to originally sign the build, or App Store Connect will return an error on upload.
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.
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.
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. You'll need to 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.

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.

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.

Last updated
Was this helpful?