# 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](https://docs.runway.team/automations/types-of-automations#enable-artifact-downloads) must be enabled and properly configured in order for Runway to access source version binary files that can be used for rollbacks. {% hint style="warning" %} Android: Rollbacks are currently supported for AABs. APKs or multi-build/multi-APK are not supported. {% endhint %} ### 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. {% hint style="info" %} Signing keys are exclusively used for re-signing binaries. To read more about how we securely store signing keys, see the [Signing keys documentation](https://docs.runway.team/using-runway/app-settings/signing-keys). {% endhint %} ### App store integration You must have an [App store integration capability](https://docs.runway.team/integrations/app-stores) 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: 1. 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](https://docs.runway.team/automations/types-of-automations#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.

Runway will need to have access to a CI build that's matched to the published app store build

1. [Add a valid signing key](https://docs.runway.team/using-runway/build-distro/signing-and-provisioning-cheat-sheet) in **App settings.** {% hint style="warning" %} 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. {% endhint %} {% hint style="info" %} If you have enabled the [Upload build artifacts for distribution](https://docs.runway.team/automations/types-of-automations#upload-build-artifacts-for-distribution) automation, Runway will pick the uploaded artifact for resigning. If you haven’t enabled artifact uploads via Runway and there might be ambiguity in identifying the correct `.ipa` or `.aab` files to upload, please let us know in advance in order to set a file filter that will ensure the correct artifact is chosen for resigning. {% endhint %} ### 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. {% hint style="info" %} When preparing a rollback manually, the last completed release is always assumed to be the target of the rollback (target version). {% endhint %} 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. {% hint style="warning" %} 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. {% endhint %} ### 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**](https://docs.runway.team/automations/types-of-automations#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. {% hint style="info" %} 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. {% endhint %} 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. {% hint style="warning" %} 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. {% endhint %} ### 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.