Types of automations
Some automations may be limited to certain plans. Please visit our pricing page to learn more.
Visit our Automations overview page for helpful information about how automations work in Runway, and how to set them up.
Categories
Release cycle
App store tasks
Beta testing
Translations
Release hygiene
General
Build Distro bucket automations
Create release-specific channel(s)
Required integration capabilities: Notifications
Runway will automatically create new Slack or Teams channel(s) for each release. To create a release-specific channel, one of the following must be true:
The Primary channel setting for your Slack or Teams integration contains a tokenized channel name (e.g.
release-{version})At least one notification has a tokenized channel name (e.g.
release-{version}) configured as a channel override
If multiple unique tokenized channel names are configured for different types of notifications, Runway will create channels matching each unique tokenized channel name if they don't exist already
Visit the Notification settings article for additional information on configuring release-specific channels.
If your app is configured with a Microsoft Teams integration, you must specify a Team that Runway should create release-specific channels in. This can be configured from the automation's settings modal.
Bump version in code
Required integration capabilities: Version control
Runway detects where the app version is referenced in your code and bumps it according to your team's bump version strategy (configurable from settings for this automation):
Pre-kickoff, to current release version, on working branch: Runway will bump the version on your working branch to the current release version prior to kicking off your release.
⚠️ Requires the Kick off release on target date automation to be enabled.
Post-kickoff, to current release version, on release branch: Runway will bump the version on your release branch to the current release version once your current release has been kicked off.
Post-kickoff, to next version, on working branch: Runway will bump the version on your working branch to the next-up release version once your current release has been kicked off.
Post-submission, to next version, on working branch: Runway will bump the version on your working branch to the next-up release version as soon as your current release has been submitted for review.
Post-release, to next version, on working branch: Runway will bump the version on your working branch to the next-up release version as soon as your current version has been released to the app store.
By default, Runway will open a pull request against the target branch with the bump version commit. The copy for both the bump version commit message, the PR title and PR body are customizable from the Custom strings section in App Settings. If you have the Merge pull requests opened by Runway automation enabled, Runway will attempt to automatically merge the bump version PR as soon as all checks have passed.
Runway cannot automatically merge pull requests if all required checks on the PR have not passed. For example, if you require approvals to merge PRs into your target branch, approval requirements must be met before Runway can automatically merge.
Bypass pull requests option
If you'd prefer that Runway directly commit and push bump version commits to your target branch, you can enable the "Bypass pull requests" option on the automation. With this option enabled, Runway will create the bump version commit directly on your target branch and attempt to push up the new commit immediately.
If your repository has branch protection enabled for the target branch, and those branch protections include requiring pull requests to merge or restricting push access to your target branch, you'll need to update your branch protection rules to allow Runway to bypass requirements. Detailed instructions on how to set this up for each type of VCS integration are available here.
How Runway detects versions in code
By default, Runway will detect the app version from your codebase by inspecting a handful of platform-specific files where versions are commonly found, but you can always configure an override list of version files in from App Settings > General > Version files, which are not limited to any of the default file types and extensions.
Kick off release on target date
Required integration capabilities: Version control
Runway will kick off your release on the configured date by performing one of the following actions:
Creating a release branch
Promoting code from your working branch to your static release branch
This automation requires at least one configured release branch pattern which specifies your team's convention for release branches.
If your team follows a trunk based development branching strategy where releases are cut directly from the trunk without release branches, this automation will remain inactive.
Required integration capabilities: Version control
Static branching teams
Runway will promote code from your working branch to your release branch on the scheduled date.
By default, Runway will open a pull request against the release branch. You can customize the resulting PR title and body from the Custom strings section in App Settings. If you have the Merge pull requests opened by Runway automation enabled, Runway will attempt to automatically merge the code promotion PR as soon as all checks have passed.
Runway cannot automatically merge pull requests if all required checks on the PR have not passed. For example, if you require approvals to merge PRs into your release branch, approval requirements must be met before Runway can automatically merge.
Bypass pull requests option
Checking the "Bypass pull requests" option enables Runway to directly perform the code promotion by merging the working branch into the release branch without opening a pull request.
If your repository has the "Require a pull request before merging" branch protection setting enabled for the release branch, you'll need to add the Runway + GitHub app to the list of apps allowed to bypass the pull request requirement. Detailed instructions on how to enable this setting are available here.
This automation setting is only available for teams using GitHub as their VCS integration.
Release branching teams
Runway will create a release branch off of your working branch for the next release on the scheduled date, using your configured release branch pattern.
This automation will always be inactive for hotfix releases in Runway.
Trigger workflow after release kickoff
Required integration capabilities: Version control, CI/CD
Runway will trigger the configured Release Candidate build workflow after release is .
This automation is not supported for teams using TravisCI as their CI/CD integration.
Required integration capabilities: Version control, CI/CD
Unsupported integrations: TravisCI
Submit app for review
Required integration capabilities: App store
Runway will submit your selected build for review if all previous steps are ready (green).
There are three submission strategy options you can choose from for this automation:
On target date: Runway will submit for review on the specified target date if all previous steps are ready. If automated submission fails, you'll need to update to a future target submit date or submit your update manually.
As soon as all previous steps are ready: Runway will submit for review as soon as all previous steps are ready. If automated submission fails, you'll need submit your update manually.
As soon as all previous steps are ready, no earlier than target date: Runway will submit for review as soon as all previous steps are ready, no earlier than the specified target date. If automated submission fails, you'll need submit your update manually.
You can pause automatic submission by clicking "Pause schedule" from the Schedule drawer in a release.
If automated submission fails, Runway will retry every 5 minutes up to a maximum of 5 times.
This automation will always be skipped (inactive) for hotfix releases in Runway.
Option to release beta track release to 100%
Android apps that have Google Beta configured as their beta testing integration have the option to have Runway automatically release the beta track release to 100% prior to submission on the Production track.
Release app on target date
Required integration capabilities: App store
Supported platforms: iOS, tvOS.
Runway will release your app on the configured date as soon as all previous steps are ready (green).
There are three release strategy options you can choose from for this automation:
On the target date: Runway will release on the specified target date if all previous steps are ready. If automated release fails, you'll need to update to a future target release date or release your update manually.
As soon as all previous steps are ready: Runway will release as soon as all previous steps are ready. If automated release fails, you'll need release your update manually.
As soon as all previous steps are ready, no earlier than target date: Runway will release as soon as all previous steps are ready, no earlier than the specified target date. If automated release fails, you'll need release your update manually.
You can pause automatic release by clicking "Pause schedule" from the Schedule drawer in a release.
If automated release fails, Runway will retry every 5 minutes up to a maximum of 5 times.
This automation will always be skipped (inactive) for hotfix releases in Runway.
Release stable phased releases / staged rollouts to 100% of users
Required integration capabilities: App store
Optional integration capabilities: Stability monitoring, Observability & Analytics
Runway will release your update to all users early if the release is healthy and has met the predefined conditions.
Health metrics for your app can be configured by visiting App settings > Health metrics.
This automation is not available for OTA apps.
Configuration
This automation can be configured with:
At least one condition (such as minimum adoption threshold and minimum phased release day or staged rollout percentage). Only releases that have met the configured conditions will trigger an early release to all users.
Health metrics. Only releases whose health metrics are all healthy will trigger an early release to all users.
Checklist items. Only releases where the specified Rollout checklist item(s) have been completed will trigger an early release to all users.
You must configure at least one condition for this automation. Health metrics and Checklist items are both optional.
You can use this automation to consistently roll out phased releases to 100% early by choosing "Phased release progress" as the only condition (and omitting any health metrics or checklist item conditions). This is particularly useful for iOS, because Apple's 7-day phased release sequence is not customizable.
For Android releases, you can set up a custom staged rollout to achieve the same effect.
Only releases that have met the configured conditions, and whose associated health metrics are healthy will trigger the automation to release to all users early.
When multiple AABs or APKs are associated with a given Android release version, Runway will look at health metrics for all builds — all must be within a ‘healthy’ threshold and must have met the configured conditions for the automation to trigger.
Halt unstable phased releases
Required integration capabilities: App store, Stability monitoring or Observability & Analytics
Runway will halt your phased release / staged rollout if if any associated health metrics fall outside of their defined thresholds.
Health metrics for your app can be configured by visiting App settings > Health metrics.
This automation is not available for OTA apps.
Configuration
This automation can be configured with:
One or more health metrics. Any health metrics that fall outside of their defined thresholds will trigger the automation.
At least one condition (such as minimum adoption threshold and minimum phased release day or staged rollout percentage). Only releases that have met the configured conditions will trigger a halt to the release.
You must configure at least one condition and one associated health metric for this automation.
Only releases that have met the configured conditions, and whose associated health metrics are healthy will trigger the automation to release to all users early.
When multiple AABs or APKs are associated with a given Android release version, Runway will look at health metrics for all builds — any builds with "unhealthy" health metrics will trigger the halt automation as long as all required conditions have been met.
Backmerge changes from the release branch
Required integration capabilities: Version control
Runway can automatically backmerge changes from the release branch to your working branch and any upcoming release branches. There are two backmerge strategy options to choose from.
Backmerge changes at the end of the release cycle
At the end of the release cycle, Runway will create a backmerge branch and open a pull request to merge the release branch back into the working branch and any upcoming release branches.
A backmerge branch will only be created if commits are found on the release branch that are not on the base branch.
If the app also has the merge pull requests opened by Runway automation enabled, Runway will attempt to automatically merge the backmerge branch if all required checks have passed.
Backmerge changes continuously as they're merged in
Any PRs merged into the release branch will be backmerged into the working branch and any upcoming release branches. This process will repeat anytime a new PR is merged into the release branch, so the working branch and upcoming release branches are always kept up to date as new work comes in.
Runway will always open a backmerge PR containing the new changes. You will be responsible for resolving any conflicts that might exist between the backmerge branch and the target branch.
Handling conflicts during a backmerge
If conflicts exist between the release branch and the target base branch, they must be manually resolved on the backmerge branch before merging. Runway will be unable to automatically merge backmerge PRs if unresolved conflicts exist in the open pull request.
Delete version-specific release branches at the end of the release cycle
Required integration capabilities: Version control
Runway will delete version-specific release branches when the release is complete and tagged.
For iOS platform apps, Runway will delete version-specific release branches when the release is completed and tagged. For Android platform apps, Runway will delete the branches when the rollout is completed.
Only teams that are set up with version-specific release branches may enable this automation.
Pull (cherry-pick) fixes into the release
Required integration capabilities: Version control
Runway will automatically pull fixes into the release branch by cherry-picking its commits from the working branch to the relevant release branch. Fixes flagged for cherry-pick will appear in the Feature Readiness work items list with the Fix header, and the code item will reflect the status of the cherry-pick automation.
Runway will always open a pull request with the cherry picked commits against the target release branch.
Configuration options
Cherry-pick pull request strategy:
Choose an option for how Runway should create cherry-pick PRs against the release branch.
Pull over fixes one at a time in the order in which they were merged: Runway will perform cherry-picks and open a PR for each fix one at a time in the order in which they were merged into the working branch. Pull requests containing fixes against the release branch must be merged or closed before the next fix can be pulled in. This option is best for teams looking to avoid cherry-pick merge conflicts.
Pull over fixes in the order in which they were merged, as soon as they're detected: Runway will perform cherry-picks and open PRs for fixes in the order in which they were merged into the working branch, as soon they're detected. Multiple pull requests containing fixes against the release branch can be open at the same time. This option is best for teams looking to get fixes pulled into the release branch as quickly as possible.
Pull over fixes by grouping all fixes into a single PR, in the order in which they were merged, as soon as they're detected: Runway will cherry-pick all fixes into a single PR open against the release branch. Any subsequent fixes will be cherry-picked into the same open PR branch. You must manually merge this PR once all fixes are in.
Allow PRs to be flagged as fixes using a token:
Enable pull requests to be flagged as a fix by adding a customizable text token in the PR title (e.g. runway-pick-{version}). If the text pattern contains the tokens {version} or {versionConcise}, work will be pulled in as a fix and cherry picked onto the release branch for the version specified. If the text pattern does not contain a version-specific token, tagged work will be cherry picked into the next active release version. Note that the target release version must be kicked off in order for tagged work to be pulled in.
If the merge pull requests opened by Runway automation is enabled, Runway will attempt to automatically merge the PR once possible (e.g. when all blocking checks have passed).
If the Require fix approvals setting is enabled, Runway will only merge cherry-pick PRs once the fix has been approved by a user with sufficient permissions.
Notify the original author when a PR has been cherry-picked:
Runway will mention the original author of the fix in a notification once the cherry-pick has been performed.
Squashed PRs vs. merge-commit PRs
Runway's cherry picking behavior differs slightly depending on whether the tagged PR was squashed into the working branch, or merged with a merge commit.
If the tagged pull request was squashed, Runway will cherry-pick the squashed commit from the working branch, and squash the resulting pull request against the target release branch when merging automatically.
If the tagged pull request was merged with a merge commit, Runway will cherry-pick individual commits that were part of the tagged PR and open a pull request against the target release branch with the cherry-picked commits. Note that Runway will not cherry-pick the merge commit on the working branch. If Runway is able to automatically merge the resulting pull request against the target release branch, it will merge with a merge commit by default to match the merge style of the original tagged PR.
Conflicts and cherry pick errors
Runway scans the working branch for tagged PRs and runs the cherry picking sequence for tagged PRs in the order in which they were merged. If it encounters an error during the cherry-pick sequence (either due to a conflict or for any other reason), a notification is sent to Slack or Teams with details on the error, and the automation is blocked from proceeding with further cherry-picks until the error is manually resolved.
Upload build artifacts for distribution
Required integration capabilities: CI/CD, App store or Beta testing
Runway will upload build artifacts (.ipa, .apk, or .aab files) from your CI/CD workflow artifacts to App Store Connect or the Play Console for distribution.
This automation depends on the Enable artifact downloads automation being enabled.
To set up this automation, you’ll configure a set of rules that define which artifacts (and from which CI/CD workflows) should be uploaded to which destination. You can also configure specific filenames that Runway should select for the upload action. Each rule requires the following settings:
The kind of CI/CD workflow for the rule: this can be either the Release Candidate (RC) workflow or the Release workflow configured in your CI/CD integration settings
The file name to look for when selecting which artifact to upload: this can be a plain string or it can contain any of the supported tokens
The upload destination: this can be either the beta integration or app store integration for your app
You’ll also need to choose the Upload behavior which will define behavior when there are multiple successful CI/CD builds in a short period of time, and in case an artifact upload fails.
Upload artifacts for newest build only: If there are multiple successful CI/CD builds in a short period of time, Runway will upload artifacts for the newest available build only.
Upload artifacts for all builds – stop on failure: Artifact uploads will be attempted for all successful builds serially in order (based on the ordering of the CI/CD workflow build they’re part of). If an artifact upload fails after retry attempts, uploads for any newer builds that have finished will not be attempted.
Upload artifacts for all builds – continue on failure: Artifact uploads will be attempted for all successful builds serially in order (based on the ordering of the CI/CD workflow build they’re part of). If an artifact upload fails after retry attempts, newer builds will proceed with upload attempts in order.
If an artifact upload attempt fails, Runway will retry twice before updating the status of the artifact upload to Failed
You can see the status of artifact uploads in the Upload status module of the Artifacts section for each build.
Failed uploads can be manually retried by clicking Retry from the Upload status module of the failed build.
Upload dSYMs to your stability monitoring provider
Required integration capabilities: CI/CD, Stability monitoring
Supported platforms: iOS, tvOS
Runway will automatically upload dSYMs generated as part of your build process from your CI/CD workflow artifacts to your stability monitoring provider.
To set up this automation, you’ll configure a set of rules that define which CI/CD workflows the automation should apply to, and (optionally) the specific file name for your dSYM zip. By default, Runway will look for any file names matching the following pattern: {*}.dSYM.zip
Runway will always upload dSYM files to the project defined in your stability monitoring integration settings.
If your CI/CD workflow packages all artifacts into a single .zip file (the default for GitHub Actions and GitLab CI), Runway requires your dSYM artifacts to use a .dSYM.zip extension.
Customized Apple phased rollouts
Required integration capabilities: App store
Supported platforms: iOS, tvOS
Customize phased rollouts with blackout dates and times – Runway will pause and resume phased rollouts to avoid phased rollout percentage increments on the blackout dates and times you specify.
Customized Android staged rollouts
Required integration capabilities: App store
Supported platforms: Android, Wear OS, Android TV
Runway will automatically increase your staged rollout percentage over the course of multiple days based on your configured settings. You can optionally specify blackout dates and times on which your staged rollout will not increment.
Configuration
To configure your incremental rollout, choose the number of days (2 - 7 days) and the staged rollout percentage for each day.
Rollout start strategy
Depending on the specific Android app store you have integrated, you'll have a choice of different strategies for starting the staged rollout sequence.
Start manually. This option requires that you manually start the staged rollout sequence. If this option is enabled, you'll see a button the Staged rollout module in the Rollout page to manually start the staged rollout sequence. The action will also be available from the Staged rollout module on the Release step. If your team has managed publishing enabled in Play Console, we recommend starting the staged rollout sequence in Runway as soon as you've published your release in Play Console. Otherwise, we recommend starting the staged rollout sequence in Runway as soon as you've received an email from Google indicating that your release has gone live.
Start automatically. Runway will start the staged rollout sequence for you automatically, either immediately upon submission (Google Play Console) or upon release (other Android stores).
For Google Play Console, a Play Console API limitation prevents Runway from determining when a release has actually gone live. This means Runway has to start the rollout at the time of submission when the Automatic strategy is set. If your team has managed publishing enabled in Play Console or consistently gets pulled for long reviews by Google, this can result in automated rollouts starting prematurely. We strongly recommend that such teams avoid using the Automatic strategy.
Start automatically on release (with email forwarding) – Google Play Console only. If your team has set up Play Console email forwarding, you can get around the Play Console API limitations described above and use this strategy to achieve automatic rollouts that start upon release, not submission. If for some reason there is a gap in email forwarding and a go-live transition is missed, you will still have the ability to manually start the rollout sequence as with the Start Manually strategy.
Blackout dates
You can also specify blackout days and times during which your staged rollout percentage will not be incremented. Runway will resume the rollout once the blackout period has ended if at least 24 hours have passed since the last time the rollout was incremented.
If you halt a staged rollout during the course of an automated rollout, you must manually resume the staged rollout and update the staged rollout percentage going forward
Prepare rollback releases
Required integration capabilities: App store
Runway will automatically prepare a rollback release alongside each regular release, which will re-sign, upload and (optionally) submit the previous stable build to have ready in case your latest release needs to be pulled back.
To enable automatic rollback submission on iOS, check the Submit automatically when all release steps are ready option. Runway will automatically submit prepared rollbacks for review as soon as the target release has gone live.
Runway can also automatically discard unused rollbacks based on conditions that you specify – for example, you could choose to discard prepared rollbacks if the target release has at least 20% adoption and retained a 95.95% crash free rate.
If a rollback has been submitted for review, discarding the rollback will developer reject the submitted rollback.
Create regression test runs
Required integration capabilities: Regression testing
Supported integration types: TestRail
Runway will create test runs (and if needed, test plans) for each new release as soon as it's kicked off. The test runs and test plans from the previous release will be used as a template for test run and test plan creation.
This automation is only available for teams using TestRail as their regression testing integration.
Configuration
To configure this automation, first specify whether your team uses test plans. If you use test plans, you'll be prompted to add at least one test plan pattern that Runway will use to match test plans from the previous release to copy over. You'll also have the option to either copy all unique test runs found under the test plan, or to match specific test runs using patterns.
If your team does not use test plans, you must simply specify one or more test run patterns that Runway should match when copying over test runs from the previous release.
When copying test runs, all test cases found in the test run will be copied for new test runs.
Distribute release summary at the end of each release cycle
Runway will distribute a release summary via email to additional recipients at the end of each release cycle. The default release summary includes stats on your release like the number of work items completed, the number of contributors to the release, the release duration, and more. You can configure the release summary template from App settings > Custom strings, and you can make changes to the release summary for a specific release from the Release step up until the release has gone live.
By default, the release summary email will be sent to all app users upon release completion. But by enabling the "Distribute release summary at the end of each release cycle" automation, you can optionally choose up to five additional email recipients for the email. This is a great option if you wish to distribute a summary of each release with people or teams in your organization that might not be users in Runway.
Configuration
Add one or more email recipients for your release summary. The release summary email will be sent automatically to recipients for each release as soon as the release goes live.
Post build info to project management tickets
Required integration capabilities: Version control, CI/CD, Project management
Runway will post comments on your project management tickets with build info for Release Candidate builds that contain associated code.
Every time a new release candidate build is generated for a release, Runway will compute a code diff for code that's being included in that build for the first time. If any code items (commits or merged PRs) are associated to a project management ticket, Runway will post a comment on the project management ticket with the details of the build.
Create and sync App Store Connect/Play Console versions to match current Runway release
Required integration capabilities: App store
Supported integration types: Google Play Store, Apple App Store, Amazon Appstore
Apple platforms (iOS, tvOS)
Runway will create a new version of your app in App Store Connect once the next release is being prepared in Runway.
Google platforms (Android, Wear OS, Android TV)
Runway will create a draft production release in the Play Console for the current release in Runway if needed, and keep the version name in sync if the version changes in Runway.
Apply default Export Compliance Information to new builds in App Store Connect
Required integration capabilities: App store
Supported platforms: iOS, tvOS
Runway will apply your default Export Compliance Information answers (as defined in App Settings) to new builds as they are uploaded to App Store Connect.
Select the latest build in App Store Connect
Required integration capabilities: App store
Supported platforms: iOS, tvOS
Runway will select the latest available build for release in App Store Connect. Note that there may be a processing delay of a few minutes.
Runway will stop automatically selecting the latest build when:
a different build is manually selected in App Store Connect
a different build is manually selected in Runway's submission step
an RC build is manually selected as Active RC in Runway's Release candidate step, and that RC build has an associated app store build
Add the latest available APK/AAB to the draft release on the Production track in the Play Console
Required integration capabilities: App store
Supported platforms: Google Play Store
Runway will take the latest available APK/AAB in the Play Console, and apply it to the draft release on the production track.
You can optionally choose to limit automatic selection to APKs/AABs that are already available on a testing track that you specify.
Runway will stop automatically selecting the latest build when:
a different build is manually applied to the Production track in the Play Console
a different build is manually selected in Runway's submission step
an RC build is locked as the active RC in Runway's Release Candidate step, and that RC build has an associated app store build
Apply release notes to new releases in App Store Connect or Play Console
Required integration capabilities: App store
Runway will automatically apply 'What's new' text or release notes from your chosen source to new release versions. There are two sources for release notes that you can choose from:
Default release notes: You can define default 'What's new' text or release notes for each locale from App settings > App store defaults > Default notes. Runway will apply these default notes to each new release version.
Previous release: Runway will use the 'What's new' text or release notes from the previous release version to populate notes for the current release.
iOS
Runway will apply 'What's New' text from your chosen source to new versions created in App Store Connect. You can continue to modify the text before you submit your update for review.
Android
Runway will apply release notes from your chosen source to new versions created in the Play Console. You can continue to modify the text before you submit your update for review.
Apply default review attachment to new app versions in App Store Connect
Required integration capabilities: App store
Supported platforms: iOS, tvOS
When submitting a new release for review, Runway will apply your default file attachment provided for reviewers to new versions created in App Store Connect.
You can configure a default review attachment in the automation's settings.
Sync release metadata from version control
Required integration capabilities: App store, Version control
Runway will read release metadata from files in your version control repo and automatically sync metadata to your release in App Store Connect or Play Console.
Runway will perform the metadata sync once, as soon as the release has kicked off. If you need to make changes to your release's metadata after kickoff, you can do so from the Metadata step on the release in Runway.
Automation settings
Metadata file path: the file path to the folder where Runway should look for localized metadata. (e.g.
MyProject/metadata)
Runway will look in your specified file path for metadata found in localized subfolders organized by locale (e.g. metadata_path/en-US/metadata_key.txt).
The special language code default can be used to specify metadata key defaults to use (e.g. metadata_path/default/metadata_key.txt) if a folder for a specific locale isn't found in your main metadata file path folder, or, if within a localized metadata folder, a specific metadata key is not found.
If the Apply default release notes automation is enabled on the app, Runway will use the default release notes configured in App settings > App store defaults > Default release notes and the default language code if present in your version control repo will be ignored.
Supported metadata keys (iOS):
namesubtitledescriptionkeywordsrelease_notespromotional_text
Supported metadata keys (Android):
release_notesdescriptionshort_descriptionnamevideo_url
Translate App Store reviews
Required integration capabilities: App store
Supported integration types: Apple App Store, Google Play Store
Runway will automatically translate any non-English App Store reviews into English. All reviews surfaced in Runway, plus any review notifications will surface translated reviews if needed.
Promote new builds to testing track
Required integration capabilities: App store
Runway will promote any newly uploaded APKs/AABs to your testing track and start the rollout.
Assign beta testing builds to default testing groups
Required integration capabilities: Beta testing
Supported integration types: TestFlight, App Center, Firebase App Distribution
Runway will assign any newly uploaded beta builds to your default beta testing groups for testing.
For TestFlight integrations, if default beta testing groups include external testing groups, external testers will have access once the build has been reviewed. Consider enabling the Submit new builds for beta review automation to expedite this process.
Submit new builds for beta review
Required integration capabilities: Beta testing
Supported integration types: TestFlight
Runway will submit any new builds uploaded to TestFlight for beta review as soon as they finish processing.
Apply beta testing notes to new beta builds
Required integration capabilities: Beta testing
Supported integration types: TestFlight, Google Beta, App Center, Firebase App Distribution
Runway will apply beta testing notes to new beta builds as they become available. The source of the beta testing notes is configurable as follows:
Carry over from previous beta build: Runway will apply the beta tester notes from the previous beta build to the most recent build.
Generate changelog from diff since previous beta build: Runway will automatically generate a changelog from new work in the diff since the previous beta build.
Generate changelog from diff since last completed release: Runway will automatically generate the complete changelog since the previous release's tag.
Sync metadata translations
Required integration capabilities: App store, Translations
Supported integration types: Apple App Store, Google Play Store, Huawei AppGallery, Amazon Appstore, Samsung Galaxy Store
Runway will upload release metadata for translation if needed and export translated metadata to the app stores when ready.
Any changes made to metadata on your source locale in Runway will automatically be uploaded to your translation provider for translation.
Additionally, Runway will automatically trigger an export of translated metadata as needed – exported metadata will be automatically saved to Play Console or App Store Connect.
Metadata export will only be triggered if all metadata fields in a given locale have been translated in your provider. If you wish to prematurely trigger an export of incomplete metadata translations, you can do so manually with the "Export translations" button, or, enable the Export translated metadata ahead of release submission option described below.
Export translated metadata ahead of release submission option
Enable this setting if you'd like to force a metadata translations export leading up to release submission. This option allows your to sync the latest translated metadata to the app stores ahead of your release submission without necessarily waiting for all translations to be ready.
Note that this option will force an export of metadata – an export will be triggered for any locales with one or more metadata fields in an Export needed state. You can choose the number of days prior to target release submission on which an export will be triggered automatically by Runway.
Some metadata fields may still have a status of Waiting for translation in the exported locale when the export is triggered.
Sync localizable string translations
Required integration capabilities: Version control, Translations
Runway will upload new or updated strings for translation as needed, and export strings from the provider and open a pull request when ready.
How it works
Runway will watch the status of localizable strings on your release branch, and perform uploads and exports to and from your translations provider as needed:
Upload localizable string files to the translations provider: If Runway detects one or more source keys with an Upload needed status, it will automatically upload the necessary files to the translations provider. Only localizable string files containing one or more keys with an Upload needed status will be uploaded.
Export translations to the target branch: If Runway detects one or more source keys with an Export needed status, it will automatically export the necessary files from the translations provider and open a pull request against your configured target branch. Only files containing one or more keys with an Export needed status will be exported.
For a detailed overview of localizable string key statuses, please see the Translations step documentation.
If you export updated translations to the working branch, consider enabling the Update translations on the release branch from the working branch automation to let Runway automatically manage updating your release branch with the latest translations.
Set up
Choose a target branch for your exported translations.
If you'd like Runway to automatically trigger an upload leading up to a release's target kickoff, check the Upload localizable strings for translation ahead of release kickoff option. You'll be prompted to choose when the upload action should be triggered, as the number of days before kickoff.
If you'd like Runway to automatically trigger an export leading up to a release's target submission, check the Export translations from translations provider ahead of release submission option. You'll be prompted to choose when the export action should be triggered, as the number of days before target submission.
The Export translations from translations provider ahead of release submission will always trigger an export on the configured day for any localizable string files that contain at least one key in the Export needed state. This may result it the export of additional incomplete translations included in that file. We always recommend reviewing and approving the overall state of the Translations step prior to app submission.
Update translations on the release branch from the working branch
Runway will update translations on the release branch by pulling over new translations from the working branch as needed.
How it works
Runway will watch your working branch for changes to any localizable string files that are merged after the release has been kicked off. If it detects new translations to existing source keys, it will automatically open a PR against the release branch with all localizable string files that that contain updated translations.
If you'd like Runway to push updated translations to your release branch without a pull request, you can enable the Bypass pull requests option. Note that this requires additional configuration on your branch protection rules – detailed instructions on how to set this up for each type of VCS integration are available here.
If the Merge pull requests open by Runway automation is enabled, the PR will be automatically merged once all checks have passed. Otherwise, you will need to merge in the update PR manually.
Tag releases at the end of the release cycle
Required integration capabilities: Version control, App store
Runway will tag your production release commit at the end of each release cycle, and generate a summary of all work going out with the release. The summary will be added to a "Release" in your VCS integration, and will include a list of commits and their associated project management tickets.
Your previous release must be tagged in order for Runway to accurately compute the summary of work for a release.
Runway may fail to tag your releases automatically in certain cases:
Your previous release was not tagged
The build that was released could not be associated with a Release Candidate (CI) build, and therefore could not be linked to a specific commit in your VCS
Commit info is missing from your build in CI
In these cases, you can manually tag your release in Runway by going to the Release step, choosing a commit to tag, and clicking Create Tag.
Attach build artifacts to VCS release record when tagging
When tagging your production release commit, Runway will attach all artifacts generated from your active production build workflow as assets on your release record.
This automation requires the Enable artifact downloads automation to be enabled.
Add missing labels or fix versions to tickets
Required integration capabilities: Version control, Project management
Runway will add appropriate labels and/or fix versions when they are missing from tickets that are associated with the release. These label and fix version patterns are defined in Integration settings > Feature affiliations for the app.
Missing labels or fix versions will be applied to a ticket if a piece of code work is in a given release (exists in that release’s diff) and that piece of code work references that ticket (in commit message, PR title, or former branch name)
The missing labels or fix versions are applied once code work enters the final release diff (i.e. exists on the release branch and is in the diff for the release).
Mark releases complete in project management tool
Required integration capabilities: Project management
Supported integration types: JIRA, Monday.com
Runway will mark releases as completed in your project management tool at the end of each release cycle.
This automation is currently only supported for Jira project management integrations.
Update status of issue tracking tickets upon release completion
Runway will update all issue tracking tickets associated with the release to the configured status upon release completion.
Enable artifact downloads
Required integration capabilities: CI/CD
Supported integration types: GitHub, Bitrise, BuildKite, Xcode Cloud, Azure Pipelines
Runway will automatically handle downloading build artifacts from relevant CI/CD workflows for use in the dashboard and other automations.
Downloaded build artifacts will be surfaced on the Release Candidate step. Additionally, Runway will include artifact information in Slack or Teams build success notifications, including a link to find those downloads in Runway.
Enabling this automation is required in order to enable the Upload build artifacts automation.
For some CI/CD integration providers, making build artifacts available for download is the default behavior, so no further configuration may be needed. For other providers, you may have to add an export step to your CI/CD workflow to make build artifacts available for download by Runway. See the table below for more details:
| Supported Provider | Artifacts available by default? | Additional Info |
|---|---|---|
Bitrise | Yes | |
GitHub Actions | No | Add an "upload artifact" step to your build job in your GitHub Actions |
GitLab CI | No | Use the |
CircleCI | No | Add a |
Merge pull requests opened by Runway
Runway may create pull requests to fulfill various tasks on demand (for example, bumping your version in code on a development branch). If this automation is enabled, Runway will attempt to merge these PRs without manual approval.
Prepare next version in Runway when current release is kicked off
Runway will create a new Runway release record for your next upcoming version as soon as your current release is kicked off.
Runway will use your app's default release type to predict the correct version for your next release.
Sync users and roles from Runway to App Store Connect / Play Console
Required integration capabilities: App store
Supported integration types: Apple App Store, Google Play Store
If someone on your team finds themselves constantly needing to invite new team members to App Store Connect or the Play Console (and ensure they have the right roles and permissions set), Runway can do away with this manual work by automatically managing adding and removing users from App Store Connect and Play Console. This automation can be enabled at the Runway user group level to invite users that belong to specific groups to the appropriate store, and grant them the appropriate roles and permissions.
When users are removed from your app in Runway, they will also be removed from the corresponding store. This option is configurable, and can be disabled from the automation's settings.
The roles and permissions granted to users are based on the mapping of Runway default user groups to App Store Connect roles or Play Console permissions. See below for the default values of this mapping for each platform.
You can also configure your own custom mapping rules for each app using the table in the automation's settings for each app.
iOS
Users in Runway will automatically be invited to your app in App Store Connect, and assigned the appropriate roles based on the groups they belong to in Runway.
The App Store Connect API key in use by Runway must have the "Admin" role in order to enable user sync.
You can choose to configure the mapping of default user groups to App Store Connect Roles from the automation's settings. See below for the default mapping of user groups in Runway to roles in App Store Connect.
Default mapping of Runway group to ASC role
| Runway Group | Default role on App Store Connect |
|---|---|
Admin | Admin |
EM | App Manager |
PM | App Manager |
Engineer | Developer |
Design | Marketing |
Ops | Customer Support |
Marketing | Marketing |
CX | Customer Support |
QA | Customer Support |
Approver | Customer Support |
For additional details on Apple Developer Program roles and associated permissions, see Apple’s documentation.
Removing users
If a user is removed from your app in Runway, and the option to remove users from App Store Connect is enabled, Runway will revoke access to the corresponding app in App Store Connect.
Android
Users in Runway will automatically be invited to your app in Google Play Console, and be granted the appropriate permissions based on the Runway user groups they belong to.
You must update the permissions on the service account associated with your Runway Play integration to “Admin” in order to enable user sync. You can do this by visiting API Access > View Play Console permissions > Account permissions and selecting "Admin"
Default mapping of Runway user groups to permissions on the Play Console
| Runway Role | Play Console Permissions |
|---|---|
Admin | Admin (all permissions) |
EM |
|
PM |
|
Engineer |
|
Design |
|
Ops |
|
Marketing |
|
CX |
|
QA |
|
Approver |
|
For additional details on the Google Play Console’ developer account users and managing permissions, visit their documentation.
Removing users
If a user is removed from your app in Runway, and the option to remove users from the Play Console is enabled, Runway will revoke access to the corresponding app in Play Console.
Sync Slack groups
Required integration capabilities: Notifications
Supported integration types: Slack
Runway will add and remove users from Slack groups based on their user roles in Runway. You can configure the mapping of user roles to Slack groups from App settings > Team > Runway user roles to Slack groups.
The Slack groups sync automation runs on a regular interval – updates may take up to 10 minutes to be applied.
Sync provisioning profile devices
Required integration capabilities: App store
Supported platforms: iOS, tvOS
Runway will sync valid provisioning profiles in the Apple Developer Portal to add and remove user devices when needed.
To configure this automation, choose which types of provisioning profiles Runway should sync.
Only iOS Ad Hoc and iOS Development provisioning profiles can specify devices – In House and App Store provisioning profiles cannot include associated devices.
Additionally, you can choose specific roles that users must have in order for their devices to be automatically synced with provisioning profiles.
To enable Runway to remove the devices of users that are removed from apps in Runway from valid provisioning profiles, keep the Remove devices for users that are removed from apps in Runway option checked.
In order to use this automation, the App Store Connect API key associated with your app in Runway must have an Admin or Account Holder role.
Sync devices in the Apple Developer Portal
Required integration capabilities: App store
Supported platforms: iOS, tvOS
Runway will register and enable new devices with the Apple Developer Portal, and disable them when the associated app users are removed from the app in Runway.
To configure this automation, choose specific roles that users must have in order for their devices to be automatically registered and enabled in the Apple Developer Portal. Test devices added to apps in Runway can also be optionally synced automatically in the Apple Developer Portal.
To enable Runway to disable the devices of users that are removed from apps in Runway, keep the Disable devices for users that are removed from apps in Runway option checked.
In order to use this automation, the App Store Connect API key associated with your app in Runway must have an Admin or Account Holder role.
Post installation QR codes on open PRs
Required integration capabilities: Version control, CI/CD
Supported integration types: GitHub
Runway will post an installation QR code on open PRs any time a new Build Distro bucket build is available for installation.
The bucket must be configured with a PR rule to pull in builds from open PRs against a base branch.
Generate tester notes from the work items diff
Runway will generate and apply build tester notes for new Build Distro bucket builds using the work items diff for the build.
Trigger build workflow
Required integration capabilities: CI/CD
Unsupported integration types: TravisCI
Runway will trigger a build workflow run automatically as needed based on your bucket configuration.
For buckets configured with a Branch rule, workflow runs are triggered anytime a commit is pushed to a matching branch, using the specified workflow. If the rule includes a user filter, only commits pushed to a matching branch by one of the specified users will trigger a new workflow run.
For example, the following bucket configuration would trigger a new tab-ios/build workflow run anytime a commit is pushed to the development branch.
For buckets configured with a PR rule, workflow runs are triggered anytime a commit is pushed to a branch that's associated with an open PR against a matching base branch. If the rule includes a user filter, only commits pushed to branches that are assocaited with an open PR created by one of the specified users will trigger a new workflow run.
For example, the following bucket configuration would trigger a new tab-ios/adhoc workflow run anytime a commit is pushed to a branch associated with an open PR against the main branch.
Upload build artifacts for further distribution
Required integration capabilities: CI/CD, App store or Beta testing
Runway will upload bucket build artifacts for distribution to additional destinations according to the configured rules.
You can use this automation to configure builds from different buckets to be distributed to additional destinations, for example, to distribute builds generated from a Feature A bucket and workflow to testers on Firebase App Distribution.
Post bucket build info to project management tickets
Required integration capabilities: Version control, CI/CD, Project management
For any new builds pulled into a bucket, Runway computes a work items diff between the most recent build and the build before it. This work items diff is a list of all new commits that are included in the newest build, and if your app has a project management integration connected, any tickets that are associated to those commits.
Runway will post a comment on any project management tickets included in the work items diff containing the details of the build, and a link back to Runway to install the build.
How to enable pull request bypass for Runway
By default, any time a Runway automation modifies code in your repository, it will open a pull request with the changes. If you have the Merge pull requests opened by Runway automation enabled, it will attempt to merge the pull request as soon as all checks have passed. However, in many cases teams choose to protect certain branches with required pull requests and lengthy integration checks, and Runway cannot merge open PRs until all of the requirements for the pull request have been met.
Certain Runway automations surface an option to Bypass pull requests and allow Runway to commit and push changes to the target branch directly. Teams may choose to enable this option if code changes are relatively trivial and harmless (e.g. version bumps) and they would prefer not to need to meet strict pull request criteria for these kinds of changes.
If a target branch has branch protections enabled, and the branch protections require pull requests for merging or restrict pushes to the target branch, you must first update the branch protection settings in your VCS in order for the Bypass pull requests automation setting to function properly.
How to update branch protection settings in GitHub
GitHub now offers two different ways to protect your repository's branches: "classic" branch protection rules, and Rulesets. Of the two options, Rulesets provide much more flexibility in how rules and bypasses are defined, and are much easier to get working with Runway. If your team is already using Rulesets, click here for instructions on how to configure repository rulesets to allow Runway to bypass pull requests. If your team is still using branch protection rules, we highly recommend considering migrating to Rulesets, which provide much better granularity and scoping for different types of repository rules.
To allow Runway to bypass required pull requests for your target branch, follow these steps:
Navigate to your repository settings in GitHub
Select Code and automation -> Branches and find the branch protection rule for the target branch you'd like to allow Runway to bypass pull requests for
Under the Require a pull request before merging option, make sure that the setting Allow specified actors to bypass required pull requests is enabled
Under the Allow specified actors to bypass required pull requests setting, add the "Runway + GitHub" app to the list of apps allowed to bypass pull requests for the branch
Under the Restrict who can push to matching branches setting, add the "Runway + GitHub" app to the list of apps allowed to push to the protected branch
Ensure Runway can run status checks if needed
If your branch protection rule additionally has the Require checks to pass before merging option enabled, Runway will need to first push changes to a branch so status checks can be run before automatically merging. In order to support this, your status checks must be configured to run on push for branches matching the pattern runway-check-*. This will let status checks run on Runway-created branches, which will enable Runway to automatically merge changes into protected branches.
How to configure GitHub branch Rulesets to enable pull request bypass
Enabling pull request bypass for Runway if your team is using GitHub Rulesets is suprisingly simple thanks to the flexible and layered nature of how rulesets work. At a high level, simply adding the GitHub + Runway app to the bypass list of your repository's ruleset that contains the "Require a pull request before merging" branch rule will grant the Runway GitHub app permission to merge to directly to the target branch.
The Runway + GitHub app should be added to the bypass list of any enabled Rulesets that target the branches you'd like Runway to commit directly into and that enable any of the following rules:
Require a pull request before merging - required for enabling committing version bumps directly onto your team's target branch.
Require status checks to pass - required to enable committing and pushing version bumps to your team's target branch without requiring status checks to first pass in a different branch.
Consider also adding Runway to the bypass list of any Rulesets that contain the following rules:
Block force pushes - Runway needs to be able to force push to newly created hotfix branches if your team uses the "Create hotfix and cherry-pick fixes" flow to create hotfix releases and choose specific fix commits to be included in the hotfix branch
Restrict deletions - required to enable the Delete version-specific release branches at the end of the release cycle automation
Restrict creations - required to enable the Kick off release on target date automation or functionality in the Runway dashboard if your team uses version-specific release branches
How to update branch protection settings in GitLab
To enable Runway to bypass merge requests in GitLab and push directly to a target branch, follow these steps:
In GitLab, select Main menu > Projects and find your project
On the left sidebar, select Settings > Repository
Expand Protected branches
From the Branch dropdown list, select the target branch
From the Allowed to push list, select the user that originally installed the GitLab integration in Runway
GitLab's integration with Runway is OAuth-based, which means that the integration's scopes and permission are tied to those of the GitLab user that ran through the OAuth flow in Runway. To avoid unintentionally granting push access to a specific user (and to avoid integration issues if that user leaves the company), we strongly suggest setting up a service account user to use for authentication between GitLab and Runway.
How to update branch protection settings in Bitbucket
To enable Runway to bypass pull request restrictions on Bitbucket and push directly to a target branch, follow these steps:
Go to a repository in a project
Choose Settings > Branch permissions and select the target branch
Under the Prevent changes without a pull request except by: restriction, select the user that originally installed the Bitbucket integration in Runway
Bitbucket's integration with Runway is OAuth-based, which means that the integration's scopes and permission are tied to those of the Bitbucket user that ran through the OAuth flow in Runway. To avoid unintentionally granting push access to a specific user (and to avoid integration issues if that user leaves the company), we strongly suggest setting up a service account user to use for authentication between Bitbucket and Runway.
Last updated
