# About Runway [Runway](https://runway.team) makes it **easier to coordinate your team’s mobile releases.** It’s an integration layer that connects to your existing project management and development tools, making it possible to: * Understand at-a-glance the status and progress of releases * Communicate tasks and blockers * Automate away many of the big (and little) tasks that make up the release process Read more [**here about the state of mobile DevOps and why we built Runway**](https://runway.team/blog). Ultimately, we think your mobile team should be able to spend more time thinking about and building great features for your app, and less time thinking about and managing the release process. # Adding apps Whether you're working on a single app on one platform, releasing for multiple platforms, or maintaining several apps for your organization, you can set up Runway around your team's unique needs. ## Add an app The first time you sign into Runway, you'll be automatically prompted to add your first app. You can always enter the **Add** flow manually by hitting the :heavy\_plus\_sign: icon in the [App sidebar](broken://pages/-Mkg9IngdxVDbEnWSE3M#app-sidebar). ![](/files/amXRYSVfVCrLzqyzv7AJ) From here, you'll have a couple of choices: * **Enter a few keywords to search for your existing app** - Runway will search the App Store and Play Store for matching apps and pull in some historical release data from your public store listing. You can even select multiple results to create an [app group](/adding-apps#app-groups). * **Enter your app's information manually** - You'll specify a name and platform for your app. Optionally, you can mark an app as being delivered via an OTA framework such as Expo or Shorebird. Runway will create an app group optimized for OTA delivery. More details on how to use Runway to streamline OTA releases can be found [here](/using-runway/over-the-air-ota-releases). ## App groups If you have similar apps that you maintain for multiple platforms (*e.g.* Trucking Simulator for iOS and Trucking Simulator for Android), Runway can pull them together into a single app group for ease of navigation and management. When you have an app group, you'll see a single app icon in the [app sidebar](/using-runway/navigating-runway#apps-navigation) with multiple platform icons to select underneath. ![](/files/ZO6gFRsIBoysXM5DL0s9) {% hint style="warning" %} If an app group doesn't show up the way you're expecting it to, [get in touch](mailto:support@runway.team) and the Runway team will make sure you're set up correctly. {% endhint %} ## App settings and connecting integrations Runway works best when it's hooked up to [a few of your key integrations](/getting-started/setting-up-your-integrations), and we have some basic information about your release workflow. {% hint style="warning" %} We recommend connecting your key integrations as a first step before filling in additional settings for your app. {% endhint %} ### Navigate to app settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar {% content-ref url="/pages/-Mjj-kMjs64BOh\_ngWlF" %} [App settings](/using-runway/app-settings) {% endcontent-ref %} # Setting up your integrations Integrations are a key part of Runway's functionality – they're used to pull in information from the tools you already use as part of your release process to create a single source of truth for your entire workflow, and to automate manual steps along the way. Use the **Integrations** page to connect Runway to third-party tools that your team already uses as a part of your release workflow. Core integrations (essential to getting your team up and running in Runway) include: {% content-ref url="/pages/-MjGrv6nxDu1qvmby-cz" %} [Version control](/integrations/version-control) {% endcontent-ref %} {% content-ref url="/pages/-MjGw-WHr-cmunqtCoK3" %} [Project management](/integrations/project-management) {% endcontent-ref %} {% content-ref url="/pages/-MjGz6yJE-IGNzuyW0jq" %} [CI/CD](/integrations/ci-cd) {% endcontent-ref %} {% content-ref url="/pages/-MjGzKQXpQfGlhp4L8vk" %} [App stores](/integrations/app-stores) {% endcontent-ref %} {% content-ref url="/pages/-MjH-3CNL22wEmdEaNhP" %} [Notifications](/integrations/notifications) {% endcontent-ref %} {% hint style="warning" %} Some core integrations rely on Runway having an accurate understanding of your team's branching strategy to work properly. * Learn more about [supported branching strategies and setup tips](/getting-started/setting-up-your-integrations/branching-strategies). * Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} {% hint style="warning" %} Some integrations may be limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) to learn more. {% endhint %} We recommend setting up each of these core integrations to get the most value out of Runway! Additionally, we offer integration support for: {% content-ref url="/pages/-MjndnooufNkOcpTfAZU" %} [Regression testing](/using-runway/release-steps/regression-testing) {% endcontent-ref %} {% content-ref url="/pages/dHyXhTZuorZ6l54GHTcU" %} [Beta testing](/integrations/beta-testing) {% endcontent-ref %} {% content-ref url="/pages/-MjH-A8ouMQypLMZRmsc" %} [Stability monitoring](/integrations/stability-monitoring) {% endcontent-ref %} {% content-ref url="/pages/FOJh5iHH35N76RFBruDZ" %} [Observability & analytics](/integrations/observability-and-analytics) {% endcontent-ref %} {% content-ref url="/pages/l8VL3IYxNEEO2whTEWNR" %} [Feature flagging](/integrations/feature-flagging) {% endcontent-ref %} {% content-ref url="/pages/wecgzInaYq8QO4MUmIhX" %} [Incident management & scheduling](/integrations/incident-management-and-scheduling) {% endcontent-ref %} {% content-ref url="/pages/juoO4KxghtVwtLRWFAY9" %} [Translations](/integrations/translations) {% endcontent-ref %} {% content-ref url="/pages/MaIyteWSlxuyeT7uSP0v" %} [Calendar](/integrations/calendar) {% endcontent-ref %} {% hint style="warning" %} Some integration types may be limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) to learn more. {% endhint %} Please [get in touch](mailto:hello@runway.team) if your team relies on additional tools that would be handy to see in Runway! {% hint style="info" %} Generally, when a change occurs in an integration, you can expect it to be reflected in Runway within 10 minutes. For many integrations (in particular, version control systems and CI/CD) updates will happen more quickly due to their webhook support. {% endhint %} ## Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on the ✏️ **Edit Integrations** button {% hint style="warning" %} We recommend connecting your key integrations as a first step before filling in additional settings for your app. {% endhint %} # Branching strategies Release branching strategies supported by Runway Runway supports a variety of the most common release branching strategies, covering the majority of teams we've encountered to date. Below, you'll find helpful guides on how to configure Runway for each. {% hint style="warning" %} If your team uses a setup that's not described here, feel free to [reach out](mailto:support@runway.team) for guidance on configuring Runway to accommodate your team's branching strategy. {% endhint %} ### Version-specific release branches With the version-specific release branch strategy, day-to-day development happens on a single, long-lived **working branch.** When the time comes to prepare for a new release, a new **release branch** is created which includes the version in the branch name. {% hint style="info" %} Some examples of version-specific release branch names: `release-1.1.0`, `v1.1.0` and `release-major-2.0.0.` Read more about [allowed tokenized patterns for branch naming here](https://docs.runway.team/getting-started/pattern-strings-tokens). {% endhint %} {% hint style="warning" %} Runway expects version strings that adhere to [Semantic Versioning](https://semver.org/) principles — formatted as `x.y.z` (representing `major.minor.patch`). {% endhint %} A **release candidate** build is created from the code on this release branch (usually on every merge or push into the branch), and testing begins on the release candidate build. If issues are discovered, fixes are merged into both the working branch and into the release branch. Creating a version-specific release branch allows normal day-to-day development to continue on the working branch, while production-ready code is kept isolated on the release branch as it goes through regression testing. You can configure Runway for a version-specific release branching workflow from [Integrations settings](/using-runway/app-settings/integrations-settings). * Enter your release branch pattern as a tokenized string under `Release branch` * Define your main **working branch** under `Additional branches` {% hint style="info" %} Runway has available automations that will [merge the release branch back](/automations/types-of-automations#backmerge-changes-on-release-branches-at-the-end-of-the-release-cycle) into the working branch (and any existing open release branches), and [delete version-specific release branches](/automations/types-of-automations#delete-version-specific-release-branches-at-the-end-of-the-release-cycle) at the end of the release cycle. {% endhint %} ### Static release branches With the static release branch strategy, day-to-day development happens on a single, long-lived **working branch**, while a single, long-lived **release branch** exists in parallel with the main working branch. When preparing a new release, production-ready code is **promoted** from the working branch to the release branch, which triggers the creation of a **release candidate** build. {% hint style="info" %} An example of a static release branch strategy is having a persistent working branch named `main`, paired with a persistent release branch named `production`. {% endhint %} You can configure Runway for a static release branch workflow from [Integrations settings](/using-runway/app-settings/integrations-settings). * Enter your release branch name as a string under `Release branch` * Define your main working branch under `Additional branches` {% hint style="info" %} With this strategy, Runway considers a release as kicked off as soon as there is new code past the previous release tag. {% endhint %} ### Three-flow In the three-flow branching strategy, teams maintain three long-lived branches: the main **working branch**, a **staging branch**, and a **production branch**. When preparing for a release, code is promoted from the working branch to the staging branch, and finally to the production branch. The staging branch will trigger the creation of **release candidate** builds which are distributed for testing. The final build that is submitted to the app store is generated off the production branch. (In some cases, the staging branch builds will have a different bundle ID or package name than the final production build.) {% hint style="info" %} An example of a three-flow strategy is a working branch named `main`, a staging branch named `staging` and a release branch named `production`. {% endhint %} You can configure Runway for a three-flow branching strategy from [Integrations settings](/using-runway/app-settings/integrations-settings). * Enter your **staging branch** name under `Release branch` * Define your main **working branch** under `Additional branches` * Enter your final **deploy branch** name under the `Deploy branch` field found in `Additional branches` {% hint style="warning" %} Runway defines the `Release branch` as the branch that generates the release candidate builds which are used for regression testing. For this reason, when using the three-flow strategy, the staging branch should be considered the release branch when configuring branches in Runway. {% endhint %} ### Trunk-based, release from trunk A trunk-based branching strategy that also releases from trunk is defined by a single, long-lived branch that's used for both development and deployment. Rather than creating branches to kick off release candidate builds, CI/CD workflows are often triggered manually or by creating tags. {% hint style="info" %} An example of a trunk-based branching strategy that releases from trunk is having a single, persistent branch named `main`, with no release branches created. {% endhint %} You can configure Runway for a trunk-based, release from trunk strategy from [Integrations settings](/using-runway/app-settings/integrations-settings). * Enter your main branch name under `Release branch` * Enter the same branch name into the `Working branch` field found under the `Additional branches` {% hint style="info" %} With this strategy, Runway considers a release as kicked off as soon as there is new code past the previous release tag. {% endhint %} # Builds and branches Runway fetches up to two different kinds of builds: * **Release Candidate** (or RC, sometimes referred to as staging) * **production** (optional) {% hint style="info" %} Runway will *always* fetch RC/staging builds. Runway will *optionally* fetch production builds if app/CI settings are defined such that production builds are different than RC/staging. {% endhint %} A build is defined by two things: the **workflow** that produces it, and the **branch** it is built from: ` + = build` So, in addition to fetching RC/staging builds, Runway will fetch production builds if there’s a distinct workflow for production *or* if a distinct branch is used for production (distinct == different than the branch defined for RC/staging builds). #### Workflow Value set in [CI settings](/integrations/ci-cd). Runway supports up to two different CI workflows: * RC/staging workflow (required/primary) * Release workflow (optional) #### Branch Runway assumes all builds are built from the app’s release branch(es), unless optional values are set in [Integration settings](/using-runway/app-settings/integrations-settings): * RC/staging branch override * Deploy branch override {% hint style="info" %} * If an RC/staging branch override value is set, RC/staging builds are fetched using that branch instead of the release branch. * If a deploy branch override value is set, production builds will be fetched, and they will use that branch. {% endhint %} ### Examples Release branch: `release-branch` #### 1. > RC/staging workflow: deploy > > Release workflow: (none) > > Staging branch override: (none) > > Deploy branch override: (none) RC/staging build = `deploy + release-branch` Prod build = (none) #### 2. > RC/staging workflow: `deploy` > > Release workflow: `deploy-prod` > > Staging branch override: (none) > > Deploy branch override: (none) Staging build = `deploy + release-branch` Prod build = `deploy-prod + release-branch` #### 3. > RC/staging workflow: `deploy` > > Release workflow: (none) > > Staging branch override: `itunes-dist` > > Deploy branch override: (none) Staging build = `deploy + itunes-dist` Prod build = (none) #### 4. > RC/staging workflow: `deploy` > > Release workflow: (none) > > Staging branch override: (none) > > Deploy branch override: `itunes-dist` Staging build = `deploy + release-branch` Prod build = `deploy + itunes-dist` #### 5. > RC/staging workflow: `deploy` > > Release workflow: `deploy-prod` > > Staging branch override: (none) > > Deploy branch override: `itunes-dist` Staging build = `deploy + release-branch` Prod build = `deploy-prod + itunes-dist` #### 6. > RC/staging workflow: `deploy-rc` > > Release workflow: `deploy-prod` > > Staging branch override: `development` > > Deploy branch override: (none) Staging build = `deploy-rc + development` Prod build = `deploy-prod + release-branch` # Pattern strings / tokens Runway uses a system of ‘tokens’ to allow for dynamic values in things like: * [Branch names](/using-runway/app-settings/integrations-settings#release-branch-patterns) * [Tag names](/using-runway/app-settings/integrations-settings#release-tag-pattern) * [Release notes and summaries](/using-runway/release-steps/metadata#release-notes-whats-new-in-this-version) * [Release descriptions](/using-runway/release-steps/kickoff#release-description) * [Feature affiliations (e.g. Jira fix versions or labels)](/using-runway/app-settings/integrations-settings#feature-affiliations) * [CI workflow arguments](/integrations/ci-cd) Wherever you set these strings in Runway, including tokens will allow Runway to dynamically inject values and also understand the different strings it pulls in from the outside world. Certain tokens can have ‘modifiers’, which allow you to customize the format of the data associated with those tokens. ## **Available token types** * **{version}** — three-segment SemVer * Example: `1.2.3` * Modifier available — pre-padding * Example: `{version}[0,0,2]` : `1.2.3` -> 1.2.03 * **{nextVersion}** — three-segment SemVer for the next version that Runway detects * **{previousVersion}** — three-segment SemVer for the previous version that Runway detects * **{versionConcise}**— truncates trailing zeroes in SemVer versions * Example: `1.2.3` -> 1.2.3 * Example: `1.2.0` -> 1.2 * Example `1.0.0` -> 1 * Modifier available — minimum digits * Example: `{versionConcise}[2]` : `1.0.0` -> 1.0 * **{nextVersionConcise}** — truncates trailing zeroes in SemVer versions for the next version that Runway detects * **{previousVersionConcise}** — truncates trailing zeroes in SemVer versions for the previous version that Runway detects * **{versionMajorMinor}** — SemVer major and minor digits only * Example: `2.0.0` -> 2.0 * Example: `2.0.1` -> 2.0 * **{releaseName}** — human-readable release name * Example: `Cinnamon` * Example: `Big Feature` * **{releaseType}** * Example: `standard` * Example: `hotfix` * Example: `rollback` * **{releasePilot}** — email of the release pilot * Modifier available — mention current release pilot on Slack or Teams * Example: `{releasePilot}[ping]` -> @jane\_done * **{previousReleasePilot}** — email of the release pilot * Modifier available — mention previous release pilot on Slack or Teams * Example: `{previousReleasePilot}[ping]` -> @jane\_done * **{upcomingReleasePilot}** — email of the release pilot * Modifier available — mention upcoming release pilot on Slack or Teams * Example: `{upcomingReleasePilot}[ping]` -> @jane\_done * **{kickoffDate}** * Modifier available — day, hour, minute * Example: `{kickoffDate}[day: -1]` -> 1 day before the target kickoff date * Example: `{kickoffDate}[hour: 6]` -> 6 hours after the kickoff date * Example: `{kickoffDate}[minute: 45]` -> 45 minutes after the kickoff date * **{submitDate}** * Modifier available — day, hour, minute * Example: `{submitDate}[day: -1]` -> 1 day before the target submission date * Example: `{submitDate}[hour: 6]` -> 6 hours after the submission date * Example: `{submitDate}[minute: 45]` -> 45 minutes after the submission date * **{releaseDate}** * Modifier available — day, hour, minute * Example: `{releaseDate}[day: -1]` -> 1 day before the target release date * Example: `{releaseDate}[hour: 6]` -> 6 hours after the release date * Example: `{releaseDate}[minute: 45]` -> 45 minutes after the release date * **{appName}** * **{releaseBranchName}** * **{workingBranchName}** — the name of your trunk branch (e.g. `develop`) * **{targetBranchName}** — target branch for a backmerge PR * **{\*}** — any string * **{commitMessage}** — commit’s message * **{commitShortHash}** — commit’s short hash * **{prTitle}** — e.g. `from cherry-picked PR` * **{prBody}** — e.g. `from cherry-picked PR` * **{prTitleOrCommitMessage}** — PR title or commit message * **{prBodyOrCommitHash}** — PR body or commit hash * **{prNumberOrCommitHash}** — PR number or commit hash * **{releaseNotesTerm}** — a title or label for the release notes appropriate to their destination in the app store * Example: `What’s New` *in App Store Connect* * Example: `Release notes` *in Google Play Console, Amazon Appstore, and Huawei AppGallery* * **{releaseNotes}** — notes included in app store metadata on release * Modifier available to allow users to enter either single release notes for specific locales * `{releaseNotes}[en]` -> release notes for English only * `{releaseNotes}[en,fr]` -> release notes for English & French locales with a title header for each to separate them * **{aiGeneratedReleaseDescription}** — AI-generated release description based on the current state of the release * Modifier available to allow users to indicate if the generated notes are for an internal or external audience * `aiGeneratedReleaseDescription[internal]` -> release description generated by AI for an internal audience * `aiGeneratedReleaseDescription[external]` -> release description generated by AI for an external audience * **{aiGeneratedBetaTestingNotes}** — AI-generated beta testing notes based on the current state of the release * Modifier available to allow users to indicate if the generated notes are for an internal or external audience * `aiGeneratedBetaTestingNotes[internal]` -> beta testing notes generated by AI for an internal audience * `aiGeneratedBetaTestingNotes[external]` -> beta testing notes generated by AI for an external audience * **{aiGeneratedWhatsNew}** — AI-generated "What's new" notes based on the current state of the release * Modifier available to allow users to indicate if the generated notes are for an internal or external audience * `aiGeneratedWhatsNew[internal]` -> "What's new" notes generated by AI for an internal audience * `aiGeneratedWhatsNew[external]` -> "What's new" notes generated by AI for an external audience * **{releaseDuration}** — the duration of a given release cycle from kickoff to when the release went live * **{releasedAt}** — date the release went live * **{releaseWorkItemsLink}** — link to **Feature Readiness** step in Runway to view the work items for a given release * **{stabilityMonitoringReleaseLink}** — link to release in your stability monitoring tool * **{releaseAppStoreLink}** — link to release in App Store Connect or Play Console * **{releaseVCSReleaseLink}** — link to the release in your version control system * **{appStoreBuildNumber}** — build number as it appears in App Store Connect or Play Console * Modifier available — substrings and trimming * `{appStoreBuildNumber}[2]` : *App store build 12345* -> 12 * `{appStoreBuildNumber}[-2]` : *App store build 12345* -> 45 * `{appStoreBuildNumber}[2]` : *App store build 1.2.3.45* -> 1.2 * `{appStoreBuildNumber}[-2]` : *App store build 1.2.3.45* -> 45 * `{appStoreBuildNumber}[-3,true]` : *App store build 1.2.3.1602061* -> 61 * **{appPlatform}** — e.g. `iOS`, `Android,` `Wear OS` * **{ciBuildsCount}** — number of successful CI release candidate builds in the release * Modifier available — offset * Example: `{ciBuildsCount}[1]` -> 2 *if number of successful CI builds is 1* * **{ciBuildNumber}** — build number as it appears in CI * Modifier available — resolve token only after the version is released\ `{ciBuildNumber}[released]`: CI #123 -> 1.2.123 * **{workItems}** — changelog-like list of a release’s work items (commits in the diff with links to corresponding tickets where applicable) * Example: `{workItems}[bug]` returns all Feature Readiness work items with commits having commit message containing the string “bug” * Modifier available for prLabel * Example: `{workItems}[prLabel:new-feature]` -> all Feature Readiness work items that have PRs with the label new-feature * Example: `{workItems}[prLabel:!new-feature,!sync]` -> all Feature Readiness work items not having PRs with the label new-feature or sync * **{workItemsCount}** — number of work items for a given release * **{issuesCount}** — number of tickets that were completed in a given release * **{commitsCount}** — number of commits in release * **{contributorsCount}** — number of contributors in release * **{linesOfCodeCount}** — number of lines of code in release ## Usage {% tabs %} {% tab title="Tags" %} * Required: * Either **{version}**, **{versionConcise}**, or **{versionMajorMinor}** * Not allowed: * **{\*}**, **{commitMessage}**, **{targetBranchName}**, **{prTitle}**, **{prBody}, {prTitleOrCommitMessage}**, **{prBodyOrCommitHash}**, **{prNumberOrCommitHash}**, **{workItems}**, **{appName}**, **{appPlatform}**, **{workItemsCount}**, **{issuesCount}**,**{commitsCount}**, **{contributorsCount}**, **{linesOfCodeCount}**, **{releaseDuration}**, **{releasedAt}**, **{releaseWorkItemsLink}**, **{releaseAppStoreLink}**, **{releaseVCSReleaseLink}**, or **{releaseNotes}** {% endtab %} {% tab title="Feature affiliations" %} * Required: * At least one of **{version}**, **{versionConcise}**, and **{releaseName}** * Not allowed: * **{\*}**, **{commitMessage}**, **{targetBranchName}**, **{prTitle}**, **{prBody}**, **{prTitleOrCommitMessage}**, **{prBodyOrCommitHash}**, **{prNumberOrCommitHash}**, **{ciBuildNumber}**, **{ciBuildsCount}**, **{appStoreBuildNumber}**, **{workItems}**, **{appName}**, **{appPlatform}**, **{workItemsCount}**, **{issuesCount}**, **{commitsCount}**, **{contributorsCount}**, **{linesOfCodeCount}**, **{releasedAt}**, **{releaseWorkItemsLink}**, **{releaseAppStoreLink}**, **{releaseVCSReleaseLink}**, or **{releaseNotes}** {% endtab %} {% tab title="Branch" %} * **If branch is versioned (i.e. branches are created per release)** * Required: * Either **{version}**, **{versionConcise}**, or **{releaseName}** * Not allowed: * **{\*}**, **{commitMessage}**, **{targetBranchName}**, **{prTitle}**, **{prBody}**, **{prTitleOrCommitMessage}**, **{prBodyOrCommitHash}**, **{prNumberOrCommitHash}**, **{ciBuildNumber}**, **{ciBuildsCount}**, **{appStoreBuildNumber}**, **{workItems}**, **{appName}**, **{appPlatform}**, **{workItemsCount}**, **{issuesCount}**, **{commitsCount}**, **{contributorsCount}**, **{linesOfCodeCount}**, **{releasedAt}**, **{releaseWorkItemsLink}**, **{releaseAppStoreLink}**, **{releaseVCSReleaseLink}**, or **{releaseNotes}** * **If branch is static (same across all releases)** * *No token types are allowed*
{% endtab %} {% tab title="Release notes, summaries, and descriptions" %} * Required: * *No tokens are required* * Not allowed: * **{appStoreBuildNumber}**, **{ciBuildNumber}**, **{commitMessage}**, **{\*}, {commitMessage}**, **{targetBranchName}**, **{prTitle}, {prBody}**, **{prTitleOrCommitMessage}**, **{prBodyOrCommitHash}**, **{prNumberOrCommitHash}**, **{releasedAt}**,**{releaseWorkItemsLink}**, **{releaseAppStoreLink}**, **{releaseVCSReleaseLink}**, or **{releaseNotes}** {% endtab %} {% endtabs %} # Preparing your first release How to get started with your first release in Runway Once you have key integrations set up, preparing a new release in Runway is straightforward. There are a few ways that new releases are added to your app's [release timeline](/using-runway/app-home#release-list), described below. {% hint style="warning" %} By default, Runway enables [an automation](/automations/types-of-automations#create-upcoming-version-in-runway-when-current-release-is-kicked-off) to create upcoming releases in Runway once your current release is kicked off. {% endhint %} ## **New code detected on a static release branch, or a new release branch is detected** ### Version-specific release branch workflow When Runway detects a new release branch matching your release branch pattern, it will create a new release record with a version number matching the version defined in your release branch on your VCS. ### Static release branch workflow If your team has a static release branch or a single, trunk-style branch, a new release record will be created by Runway automatically as soon as new commits are detected past your previous release's tag. {% hint style="info" %} When creating new releases as a result of new code being detected on the release branch, Runway will, by default, assume the new release has a version equal to a minor version increment from your previous release. For example, if your previous release was `1.1.0`, and Runway detects new code on your release branch, it will automatically create a new release with the version `1.2.0`. {% endhint %} ### Versioning config Version strings are an important identifier in Runway, allowing us to match up release data across different contexts and integrated tools. #### Custom versioning configs Not all teams follow standard semantic versioning, so we offer the ability to set custom versioning configurations that allow Runway to interpret different version string formats and still map them to the correct release. You can set these mappings for different contexts if needed — for example, you could set one config for version strings as they appear in your app’s bundle and in the app stores, and a different one for version strings that appear to users in Runway. Below are common examples of custom versioning configs. If you’re not sure how Runway might support your team’s versioning convention, get in touch! * Concise: `3.15` * Version with build number for patch digit: `3.15.1234` (where `1234` is the store build number that was released) {% hint style="warning" %} Currently, custom versioning configs need to be set by the Runway team on our backend. {% endhint %} ## Preparing a release manually You can always choose to manually prepare a release in Runway using the "Prepare release" button on the releases timeline. You will be prompted to enter a version, choose a release pilot, and optionally set target dates for kickoff, submission, and release (depending on your platform). ![Prepare new release modal](/files/-MlSeZ5UMoo-cw_YUd7f) {% hint style="info" %} You can always edit a release's details, or delete the release record entirely if needed. Actions for editing and deleting a release can be found on the **Overview** page or the **Kickoff** step's **Summary** tab. {% endhint %} ### Prepare next release version automation One of Runway's handy [automations](/automations/overview) will automatically create the next-up release in your app's release timeline as soon as your current release is kicked off. By default, Runway will follow a minor-increment pattern for newly created releases, but you can change this by updating the `Version defaults setting` in [App settings > General > Version defaults](/using-runway/app-settings). # Setting up your team A lot of the little inefficiencies that can make releases a pain happen when members of a team are trying to communicate about progress or blockers related to a release. Runway is designed to provide everyone with a single source of truth, and leverages smart automations and integrations like Slack to proactively let team members know how the release is going and what tasks might need to happen next. All of which is to say, **Runway is even more valuable when your team is using it together!** ## Inviting team members You can add members to your team by sending them [**email invites**](/using-runway/organization-settings#inviting-your-team)**.** {% hint style="info" %} If your Runway organization was created by a user with a company email domain, any new users with the same company email domain will be automatically merged into your Runway organization. All they have to do is create an account at app.runway.team/signup and they'll automatically be placed in the correct Runway organization. {% endhint %} ## User groups Runway offers several different user groups with associated allowed actions out-of-the-box that can be assigned to your teammates. For example, membership to a particular group might restrict someone's ability to perform major release actions, or give someone special access as a regression tester or approver. You can also create custom groups that define specific allowed actions to a group of users that you specify. * The available default user groups are: **Release pilot**, **EM, PM, Engineer, QA, Design, Marketing, CX, Ops, Approver** * **Release pilots** also have additional privileges during their assigned releases To learn more about user groups and what actions group members can perform, visit the [Groups documentation](/using-runway/organization-settings/team#groups). # Navigating Runway

App overview page for an app in Runway

## Apps navigation The organization navigation sidebar is used to switch across apps that you've added to your organization in Runway. Related apps appear together in groups from which you can switch to apps of different platforms. {% hint style="info" %} Runway attempts to intelligently group related apps together when they're first added. Get in touch if you'd like to reorder the way apps are grouped together in Runway. {% endhint %} ## Organization and user settings
The bottom of the organization navigation sidebar contains links to: * Invite flow using email * Organization overview and settings * User settings ### Organization overview and settings Directly above the link to **User settings** you'll find a link to your organization's **Overview** and **Settings** pages.
To learn more about the types of metrics you can find in your organization's **Overview** page, visit the [**Organization Overview**](/using-runway/organization-overview) documentation. ### User settings The bottom-most icon in the organization navigation sidebar is a link to your user's settings page. Here you can view key properties of your user, like your user's email, permissions, and roles. You can optionally specify your user's preferred GitHub username to help link together your version control's user to your user in Runway. {% hint style="info" %} If you've registered iOS devices to your user via the [Device Registration](/using-runway/app-settings/profiles-and-devices#adding-your-device-to-runway) flow, they'll appear here. {% endhint %} ## Quick navigation with the Quick Action Menu You can quickly navigate across key areas of Runway using just your keyboard via the **Quick Action Menu**. To pull up the menu from any page in Runway, simply enter `command + K` / `ctrl + K` in your keyboard.

Command palette

The Quick Action Menu provides shortcuts to seamlessly navigate across key areas of Runway, including: * Switching across apps in your organization * Navigating to the next release for a given app * Navigating to the Rollout page of the live release in a given app * Navigating to any section in App settings * Navigating to Organization settings * ... and more {% hint style="info" %} Start typing into the search bar of the Quick Action Menu to narrow down options if you're looking for a specific shortcut. {% endhint %} ## Persistent URL shortcuts for live and next up releases Rather than manually editing a version number in a bookmarked URL or navigating with multiple clicks every time, Runway will accept `live` or `next` in place of version strings wherever they would normally appear in your Runway app's URL, to jump to the respective release. {% hint style="success" %} For example, let's say that the current iOS version for the "Tab" app is `3.4.0`. If you take an existing Runway URL and replace the version number with `live` or `next`... * Example: `.../releases/3.4.0` becomes `.../releases/live` * Example: `.../releases/3.5.0/overview` becomes `.../releases/next/overview` ...you'll be brought directly to version 3.4.0 (live version) or 3.5.0 (next up version) of the Tab iOS app within Runway. And a week or two later when your team has released `3.5.0`, visiting the same URL or bookmark will now bring you to versions 3.5.0 and 3.6.0 in Runway, etc. {% endhint %} # App overview **App overview** is a dedicated view to understand at a glance the release history and current activity related to a particular app or app platform. ## Version history sidebar A timeline with all historical, current, and upcoming versions of your app appears to the left. At the top, you'll see the name of the selected app and platform. ![](/files/qfq2ryUDwlLouPK58pla) ### Link to app settings You can navigate to **App Settings** by clicking the gear icon (⚙️) at the top. ### Prepare a new release Click the **Prepare new** dropdown to choose to either prepare a new release, or create a hotfix release. ![](/files/Aj4xVxGCsVkZV8AQI2x8) * **Release version** (required) - Enter the planned version number of your next release. Runway will determine whether it's a major, minor, or point release based on [semantic versioning rules](https://semver.org/). * **Release pilot** - Choose a specific team member to act as release pilot for this release. If no selection is made, Runway will automatically assign a release pilot from a rotation of team members who are [eligible to be release pilots](/using-runway/organization-settings/team#groups) for this app. * **Target kickoff date** - Specify a target date for when you plan to kick off this release. * For release branch teams, Runway considers a release kicked off when a release branch is detected or [created by Runway](/automations/types-of-automations#release-cycle). * For static branch teams, Runway considers a release kicked off when code is detected past the last release tag, or when [Runway promotes code](/automations/types-of-automations#release-cycle) from your development branch to your release branch. * **Target submit date** - Specify a target date for when you plan to submit this release to the app store for review. * **Target release date** - Specify a target date for when you plan to release this app update to end users. {% hint style="warning" %} If you have related [release cycle automations](/automations/types-of-automations#release-cycle) enabled, Runway will attempt to perform these automations on the target dates specified here. {% endhint %} #### Hotfix release If you choose to prepare a hotfix release, Runway will: * Predict a hotfix version and attempt to warn on any issues regarding intended version. * (Optional) Immediately create a release branch from the previous release tag. * (Optional) Bump version on release branch. * Your cadence/scheduled automations will not be applied. * If you have an active [release schedule cadence](/using-runway/app-settings/release-schedule), your normal release schedule will remain unaffected on other releases. If the hotfix isn't released prior to your next kickoff, Runway will push back your future releases' target dates to compensate. * Certain automations are skipped by default. View the list [here](/using-runway/hotfixes#hotfixes-and-automations). {% hint style="info" %} You can set an option on checklist items, approvals items, or regression testing items in Runway that will have them apply only to hotfix releases, or only to non-hotfix releases. {% endhint %} ### Release list Here you'll see a list of all releases, including: * **Completed** - Releases that have been released from the app store. * The initial release date is shown alongside completed releases (for phased releases, the date shown is Day 1 of the phased release) * If the most recent Completed release is a Phased release in progress, you'll see the Phased percentage in place of the release date. * A half-filled circle represents a phased release that never reached 100%. * An alert icon ( :warning: ) represents a release that has not yet been tagged. {% hint style="info" %} Releases are considered **completed** under the following conditions: * iOS: Manually or automatically released (or Day 1 of a phased rollout) * Android: When updated is submitted for review * Runway doesn't have visibility into status past this point due to API limitations. {% endhint %} * **Next release** - The 'active' release in progress, intended to be the next version released to end users. * **Upcoming** - Future releases planned past the next release. Click into any release to see the dedicated [Release view](/using-runway/release-steps) for that version. ## Release summaries In the main content area of **App Overview**, you'll see a scrolling list of modules representing each version, including **Upcoming**, **Next release**, **Live**, and **Completed** releases. ![](/files/B7D0CfqEzI6gf7keMyNL) ![](/files/sjDzgy2Dut8FUEMcRZgn) # Releases The **Release** view is your dashboard for all activity and progress relating to a particular version release. On the left, you'll find links to the [**Release overview**](/using-runway/release-steps/release-overview) as well all [**Release steps**](/using-runway/release-steps#release-steps). {% content-ref url="/pages/4JcOavR8vf30zACBgFi7" %} [Release overview](/using-runway/release-steps/release-overview) {% endcontent-ref %} ### Release steps All Release steps are shown with status dots indicating progress towards overall completion: * **Gray** - Step is inactive * **Yellow** - Step is pending, waiting, or in progress * **Green** - Step is complete * **Red** - Step has failed or is blocked | **Step name** | **Purpose** | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | [Kickoff](/using-runway/release-steps/kickoff) | A summary of kickoff details for this version release, including code and branch-related setup, and pilot and planning information | | [Feature readiness](/using-runway/release-steps/feature-readiness) | A view that reconciles the status of work tickets and actual code present in your branch | | [Release candidate](/using-runway/release-steps/ci) | Build status and history pulled in from your CI/CD workflow | | [Regression testing](/using-runway/release-steps/regression-testing) | Status of any regression testing occurring on release candidate builds | | [Beta testing](/using-runway/release-steps/beta-testing) | Status of beta testing occurring on release candidate builds | | [Screenshots](/using-runway/release-steps/screenshots) | View screenshots currently staged for this release in the app store | | [Metadata](/using-runway/release-steps/metadata) | View and edit release notes for this release that will appear in the app store | | [Approvals](/using-runway/release-steps/approvals) | Status of approvals needed from various stakeholders to continue with the release | | [App submission](/using-runway/release-steps/app-submission) | Select a build, review any final release settings and submit your update to app stores for review | | [App store review](/using-runway/release-steps/app-store-review) | Status of review from app stores | | [Release](/using-runway/release-steps/release) | Status of final release to the app store, stability monitoring, cleanup tasks | # Release overview From the **Release overview** page, you can make edits to release parameters and status, as well as view a number of useful high-level metrics related to the release. Some metrics are evergreen through the life of the release, and others only appear after a release has been completed. Many of these statistics will display a “Change” value which shows how the particular metric is tracking compared to the historical average for that metric across previous releases. This helps your team understand how certain key metrics are trending over time, and whether things are moving in a positive or negative direction. At the top of the Release overview page, you'll find important dates for the release, as well as a button to **Edit release** and update release status. ### Edit release Clicking the **Edit release** button at the top-right corner opens a dialog that allows you to modify the following: * Version * Release pilot * Release name * Target dates Additionally, by clicking into the `...` dropdown options on the side of the **Edit release** button, you can change the status of the release, including: * Complete release * Un-complete release * Skip release * Delete release {% hint style="info" %} If you choose to **un-complete** a release, you must confirm that there is no active release with the same version on the **production track** in Google Play Console. If such a release exists, Runway will automatically re-complete the release upon the next refresh. {% endhint %} ### Product sprint In the Product sprint section of the Release overview page, you’ll see a number of product-related statistics about your release surfaced, including: * Items of work completed * Number of fixes * Fix percentage (percetange of completed work items that were fixes) * Fixes approved / rejected * Number of CI builds * Number of App Store / Play Console builds * Time spent “Waiting for review” (iOS only) * Time spent “In review” (iOS only) * Number of product teams that contributed to the release * Based on the number of completed tickets in a release, and the team associated with each completed ticket. A bar graph will also display teams that have completed the most tickets in the release, in descending order. ![](https://lh5.googleusercontent.com/6mzU20ez1Sawar6Al948Hik7EM_cw624nvfsWCfHZhLt-JfXIaT29YhaOzbc4PzK9x3kZhbpm1O2XQ04MNaCmuJ91loI7_2yjhEWXdJLZzLETL2VJtL3CFeSIUFqCRk8hdMIq2_A) ### Code The Code section of release overview shows metrics related to CI/CD builds and code for the release. Here, you’ll find statistics such as: * Build workflow success rate * Number of commits * Average build time * Number of code contributors * A bar graph will also display individuals that have contributed the most commits to the release, in descending order. * Number of files changed * Includes a list of top changed files, ranked by the volume of code that was changed in those files. ![](https://lh5.googleusercontent.com/8ann8JqVSPyjGafrc5bckcb47heYG2y4CDn1vmMpUtp4S9nQYjjbpUtOLEjJY1uEUL5DOc7D1-_lzJPisLkYssLfw1rwTF6HWapsy7QtWGS2tw0yHplktMxbuphpLgOcoER-k92J) ![](https://lh6.googleusercontent.com/bEqvwDvAePTAEA2CPp8ccmv_yBrrgXHb2ByPkAZxAaVe_lFZ6R5i1uT2XXtppnUVX8aWN8c4TnD8WKMbl5Z43VaQPYpM2BzpLKzDgLdl4v-nlJ8EGFX50fnnq45kFfJXZX1v7l2Z) # Feature flags The **Feature flags** page is a dedicated place within a release to view all active feature flags for your app, giving you an at-a-glance view into your team’s active feature flags, their associated status, and relevant flag targeting and delivery rules. For each release, Runway will surface a list of relevant feature flags – only feature flags that were created *before* the release was kicked off will be shown in this list.
{% hint style="info" %} Feature flags are fetched based on the project and environment configured as part of the feature flag integration's setup. Only flags that are not archived are shown in the list of active feature flags. {% endhint %} Runway highlights feature flags that target the current release version — if a feature flag has at least one rule that targets the current release version, it will appear with a star icon . This serves as a reminder for your team to pay special attention to that feature flag during the course of the release and beyond. Relevant information for each feature flag is surfaced, including: * Feature flag name * Status * Rules * Variations * Created at date * Minimum version * Maximum version * Target versions {% hint style="success" %} To determine minimum, maximum, and target versions for each feature flag, Runway looks for any rules that target an audience or segment that includes a version attribute (as defined by your integration's *Release version attribute name*). {% endhint %} Clicking into a feature flag from the list opens a drawer where you'll find additional information including variation details (including rollout percentages for each variation) and targeted delivery rules. You can also enable and disable flags directly from here.

# Dependency management The **Dependency management** page is a dedicated place within a release to view all active dependencies for your app, surfacing which versions you're currently on and highlighting anything that’s out-of-date as well as OS requirements where applicable. For teams shipping multiple apps within one Flightpath, there's a separate tab per app so you can review dependencies for each.
Dependency management

Dependency management view

{% hint style="info" %} This view is currently only supported in iOS. {% endhint %} # Kickoff The **Kickoff** step serves as an overview for code and branch-related details, as well as pilot and planning information that may be helpful as your release process is getting started. ![](/files/EEWUmyseqYUZ4Ajd36Pe) Two key actions contribute to the Kickoff step in Runway: * Release branch is created or code is promoted (static branch teams) * Version is bumped Once a release is kicked off, Runway will: * Assign a release pilot based on the app's [pilot rotation](/using-runway/app-settings/release-pilot-rotation) (if set) * Treat the release as kicked off until it has either been marked as [skipped](#skip-release), or successfully released. Once released, Runway will automatically mark the release as completed. ## Actions from 'Edit release' button ### Edit release Modify basic parameters about your release here: * **Release version** (required) - Enter the planned version number of your next release. Runway will determine whether it's a major, minor, or point release based on [semantic versioning rules](https://semver.org/). * **Release pilot** - Choose a specific team member to act as release pilot for this release. If no selection is made, Runway will automatically assign a release pilot from a rotation of team members who are [eligible to be release pilots](/using-runway/organization-settings/team#groups) for this app. * **Target kickoff date** - Specify a target date for when you plan to kick off this release. * For release branch teams, Runway considers a release kicked off when a release branch is detected or [created by Runway](/automations/types-of-automations#release-cycle). * For static branch teams, Runway considers a release kicked off when code is detected past the last release tag, or when [Runway promotes code](/automations/types-of-automations#release-cycle) from your development branch to your release branch. * **Target submit date** - Specify a target date for when you plan to submit this release to the app store for review. * **Target release date** - Specify a target date for when you plan to release this app update to end users. ### Complete release This action will mark the release as completed in Runway. * The release will be moved to the 'Completed' section of releases * The next up release will then become the active release. {% hint style="success" %} This can be used in cases where there was no automated feedback that the release completed naturally (*e.g.* complete status from app stores, or a completed CI workflow run for OTA apps). {% endhint %} ### Skip release This action will mark the release as skipped. * The release will be moved to the 'Completed' section of releases * The next up release will then become the active release. * When choosing to skip a release, Runway presents the following options: * **Roll forward metadata changes from this release:** This will ensure that any metadata changes ("What's new" text, etc.) made to this release are applied to the next active release. * **Pull active app submission:** This will ensure that the subsequent release is not blocked from submission due to this skipped release. This option will only be present if Runway detects that this release is currently in a submitted state in an app store. {% hint style="info" %} Typically, the 'Skip' option is used when a release hasn't actually been published to the app store or otherwise has not been pushed live to users, but the team wants to mantain a record that it existed. {% endhint %} {% hint style="warning" %} If Runway's [Tag releases at the end of the release cycle](/automations/types-of-automations#tag-releases-at-the-end-of-the-release-cycle) automation is enabled, it will not run for skipped releases. {% endhint %} ### Delete release This action will remove the record of this release from Runway's list of planned app versions. ## Release information ### Feature affiliations Here, you'll see a list of labels / fix versions used in your [project management tool](/integrations/project-management) that are associated with ticketed work for this particular release. Runway uses feature affiliations to [track work items](/using-runway/release-steps/feature-readiness#items-of-work) that are intended to go out with the release but might not be in the actual code yet (and, optionally, can [add missing labels / fix versions](/automations/types-of-automations#add-missing-labels-or-fix-versions-to-tickets) to tickets that have associated code that is already part of the intended release). {% hint style="info" %} You can set up or manage feature affiliations from the [Integrations settings](/using-runway/app-settings/integrations-settings#feature-affiliations) page. {% endhint %} ### Release branch Shows the status of the branch that your release will be built from. * **Release branching teams** - Runway checks for a matching release branch for this specific version. * If the release branch was created by Runway (via [automation](/automations/types-of-automations#kick-off-release-on-target-date) or using the **Create branch** button at the bottom of the Kickoff step), you'll see a link to the associated PR here. * If Runway's attempt to create the release branch was unsuccessful, you'll be asked to resolve here by clicking through to the associated PR. * **Static branching teams** - Runway monitors the branch you release from to detect new commits past your last release tag. * If code promotion was performed by Runway (via [automation](/automations/types-of-automations#kick-off-release-on-target-date) or using the **Promote code** button at the bottom of the Kickoff step), you'll see a link to the associated PR here. * If Runway's attempt to promote code was unsuccessful, you'll be asked to resolve here by clicking through to the associated PR. {% hint style="warning" %} You can change the details of your branch setup from the [Integrations settings](/using-runway/app-settings/integrations-settings#release-branch) page. Runway may not be able to accurately determine the status of your release if this information is incorrect. {% endhint %} ### Version in code Runway detects where your version may be determined in your code, and shows you the status of the associated code on your working branches as well as the branch you'll release from. * Runway can bump the version in code on your behalf by using the [**Bump version**](/using-runway/release-steps/kickoff#bump-version) button at the bottom of the Kickoff step. Once the version bump is performed, you'll see a link to the associated PR here. * If Runway's attempt to bump your version in code was unsuccessful, you'll be asked to resolve here by clicking through to the associated PR. ### Previous release tag The name of the tag for the previous release and a link to the code diff in your version control system (e.g. GitHub). ### Release pilot The name of the associated pilot for this release. This can be changed by editing [release settings](/using-runway/release-steps/kickoff#edit-release-settings). ### Release description You can enter notes here about anything your team needs to keep track of for this version release. For example, you might call out in the release description that a major feature is being modified and needs extra attention from the team during the release process. These notes are internal to Runway and not visible to app store users. * Markdown is accepted. * This content can be customized using [Patterned tokens](/getting-started/pattern-strings-tokens) ## **Kickoff actions** You can use the buttons at the bottom of the Kickoff step to perform key actions during your release kickoff. ### Bump version Runway detects where the app version is referenced in your code and bumps it to match the version number of the current planned release. * Once the version bump is performed, you'll see a link to the associated PR shown along with [version in code information](/using-runway/release-steps/kickoff#version-in-code) on the Kickoff step. * If Runway's attempt to bump your version in code was unsuccessful, you'll be asked to resolve here by clicking through to the associated PR. ### Create branch (Release branch teams) Runway will create a release branch for this version. * Once the release branch is created, you'll see a link to the associated PR shown along with [release branch information](/using-runway/release-steps/kickoff#release-branch) on the Kickoff step. * If Runway's attempt to create the release branch was unsuccessful, you'll be asked to resolve here by clicking through to the associated PR. ### Promote code (Static branch teams) Runway will promote code from your working branch to your main branch. * Once code promotion has been performed, you'll see a link to the associated PR shown along with [release branch information](/using-runway/release-steps/kickoff#release-branch) on the Kickoff step. * If Runway's attempt to promote code was unsuccessful, you'll be asked to resolve here by clicking through to the associated PR. ## Kickoff automations You can configure the following Kickoff automations by visiting the **Automations** tab on this step: * [Bump version number in code](/automations/types-of-automations#bump-version-number-in-code) * [Kick off release on target date](/automations/types-of-automations#kick-off-release-on-target-date) * [Create new App Store Connect versions when the release is ready to be prepared](/automations/types-of-automations#create-new-app-store-connect-or-play-console-versions-when-the-release-is-ready-to-be-prepared) * [Prepare next version in Runway when current release is kicked off](/automations/types-of-automations#prepare-next-version-in-runway-when-current-release-is-kicked-off) * [Merge pull requests opened by Runway](/automations/types-of-automations#merge-pull-requests-opened-by-runway) * [Trigger workflow after release kickoff](/automations/types-of-automations#trigger-workflow-after-release-kickoff) * [Create release-specific Slack or Microsoft Teams channel(s)](/automations/types-of-automations#create-release-specific-channel-s) * [Create regression test runs](/automations/types-of-automations#create-regression-test-runs)
{% hint style="warning" %} Editing automation settings from an individual release will apply those changes to all of your upcoming releases for that app. {% endhint %} ## Kickoff checklist You can add **checklist items** to this step by visiting the **Checklist** tab. Checklist items cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). {% content-ref url="/pages/-Mjj12OTH2s5C-sghI3t" %} [Checklists](/using-runway/checklists) {% endcontent-ref %} # Feature readiness The **Feature readiness** step shows you the status of all work that is slated for the release. Instead of seeing only a siloed view of *only* project tickets or *only* committed code, Runway intelligently reconciles both to provide a single source of truth and a better understanding of your team's progress towards being feature complete.
## Items of work In the Feature readiness view, Runway pulls together a list of all items of work for a given version, including: 1. Any commits/code in the diff since the preceding version's release tag 2. Any open PRs against the release branch 3. Any tickets which are explicitly labeled for the release via a “feature affiliation” (e.g. a label or 'Fix version' in Jira) 4. Any tickets, regardless of explicit label or otherwise, which are referred to (via commit message, PR title, or branch name) by code that is associated with the release (either 1 or 2 above) 5. Any code, regardless of where it lives, that refers to (via commit message, PR title, branch name) a ticket which is explicitly labeled for the release {% hint style="success" %} If you have the '[Add missing labels or fix versions to tickets](/automations/types-of-automations#add-missing-labels-or-fix-versions-to-tickets)' automation enabled, Runway will auto-apply any missing feature affiliations to tickets referred to by code associated with the release. {% endhint %} In cases where committed code or open PRs are associated with a ticket, Runway combines those references into a single item so you're not seeing duplicated information. In cases where code has no associated ticket, or a ticket doesn't correspond to any code as of yet, Runway calls that out as well. When possible, Runway will surface CI build information on Feature readiness items by looking at both the Release Candidate and the development (or working branch) builds, surfacing only the latest build that contains the given commit from the Feature readiness item. ### Pending / Done tables Items of work are divided into two tables: * **Pending** — Items are considered Pending when the ticket status has not yet reached the “Done” status in your project management software, or corresponding code has not yet been merged into the relevant branch. You can manually mark an item to not be considered towards overall Feature readiness percentage by clicking the “...” icon at the end of the row and selecting **Ignore**. * **Done** — Items are considered Done when the ticket status matches one of your team's [configured “Done” statuses](/integrations/project-management), and any corresponding code has been merged into the release branch. #### Table content * Ticket information (appears on the left side of the row) * **Status** — This label will reflect the current status of this item of work in your project management software. * “Done” statuses appear as green and will move the item of work to the Done table as long as the corresponding code has been merged into the branch. * All other ticket statuses appear as gray and will cause the item of work to appear in the “Pending” table regardless of code status. * **Ticket name** — The identifier for this item of work in your project management software, shown alongside an icon representing your project management tool (Jira, Linear, etc). You can click the icon or the ticket name to go directly to the ticket information view in your project management software. * **Ticket title** — Ticket title from your project management software. If truncated, hover over this area to view the full title in a tooltip. {% hint style="info" %} If an item of work is identified related to the current release without a corresponding ticket (for example, committed code without any references to a Jira ticket), the ticket information area will show “No ticket found”, and ticket status will not be considered in determining **Done** status. {% endhint %} * Code information (appears on the right side of the row) * **Status** — This label will reflect the current status of this code relative to the release branch (or working branch, if you’ve changed the base branch on the view) * “Merged” status appears as green, and will move the item of work to the Done table as long as the corresponding ticket status is also considered “Done” * “Open PR” or “Not on release branch” statuses appear in orange, reflecting code that is expected, but has not yet arrived on the release branch * **Branch and code identifier** — Current branch (or destination branch for PRs) and commit hash (or PR number) for the corresponding code, shown alongside an icon representing your version control software. You can click the icon or code identifier to go directly to commit information or PR in your version control software. * **Commit message or PR title** — Commit message or PR title from your version control software. If truncated, hover over this area to view the full message in a tooltip. * **Owner** — An icon representing the version control user associated with this code (either via commit or PR). Hover over the icon to view the full name in a tooltip. {% hint style="info" %} If an item of work is identified related to the current release without any corresponding code references (for example, a Jira ticket without any associated commits in GitHub), the code information area will show “No code found”, and code status will not be considered in determining **Done** status. {% endhint %} * **Other actions** — Click the “...” icon at the end of the row to view additional actions. * **Ignore** — Click to exclude this item from being considered towards feature readiness/completeness. Ignored items will remain in the Done or Pending table according to normal rules, but will not be included in the overall count. * **Info** — Hover over the info icon at the end of the row to see a short summary explaining why the item of work was pulled into this release and how code and ticket status were determined by Runway. ### View options #### Base branch selector Use this control to view overall progress of work items relative to the selected branch. {% hint style="info" %} If your team uses release branches, the base branch selector is useful for viewing progress towards feature completeness on a release which hasn’t been kicked off yet (a release branch hasn’t been created yet for the release). {% endhint %} #### Filtering * **Hide tickets that are subtasks** — Don't show tickets in this view that are subtasks of other tasks. * **Only show tickets with the feature affiliation for this release** — Don't show tickets in this view unless they are explicitly associated with this release via feature affiliations. If this option is OFF, Runway will pull in info for any tickets that are referenced by relevant PRs or commit messages. ## Fixes If you need to get fixes into the release branch post-kickoff, you can also do this right from the feature readiness page. Fixes are work items that aren't yet in on the release branch, that your team would like to pull into the release – these can either be open PRs against the working branch, or PRs or commits that have already been merged into the working branch. ### Configuring fixes Within Settings > Fix Requests, there are a number of different configurations to customize how fixes work for your team: * Fixes for open PRs * Create a fix for all open PRs against the release branch * Disallow new fix requests once release is submitted * Thread related fix notifications * Fix approvals * Fix approvals enabled: if enabled, then all fixes must be approved by a teammate with the relevant permissions in order for the fix to be included in the release * Number of approvals required * Status checks enabled: if enabled, Runway will include a status check on any pull requests created for fixes going into the release branch. The status check will only pass when the fix request associated with the PR has been approved * Fix request form template * Fix request form fields: in addition to configuring the fields that your teammates should fill in when requesting a fix, you can also set a minimum character limit and indicate which fields are required or optional * Auto-merge fixes * Auto-merge user-created PRs with fixes enabled: if enabled, user-created PRs with fixes against the selected target branches will be automatically merged if they are approved and have no conflicts ### Adding fixes To add a fix to the release, click **Add fix** from the top of the Feature Readiness work items list. You'll be presented with a form to choose the work (PR or commit) you'd like to include with the fix. Based on your team's fix request configuration, you see form field(s) prompting you to provide additional context explaining the need for the fix.
Alternatively, any work item that includes either an open pull request against the working branch, or a merged PR or commit on the working branch can be added as a fix for the release by clicking **Pull in as fix** from the action menu.

Select an existing work item to pull into the release as a fix

You can also add a fix to the release via Slack. The following Slack slash command will pull up a form to add a fix to the current release without ever leaving Slack: ``` /runway add fix ```
Once a fix has been added, it will appear in the list of pending work items for the release branch. You can either manually cherry-pick the work item into your release branch, or if you have the [Pull (cherry-pick) fixes](/automations/types-of-automations#pull-cherry-pick-fixes-into-the-release) into the release automation enabled, Runway will automatically take care of pulling the fix into the release via cherry-pick. ### Fix request approvals Your team can also choose to gate fixes with *approvals* – to enable fix approvals go to **App Settings > General > Fixes > Require fix approvals**. For more details, visit the [Fixes settings documentation](/using-runway/app-settings/general-settings#fixes-settings). {% hint style="success" %} You can take fix request approval gates even further by enabling additional options from **General > Fixes**: 1. **Create fix for open PRs against release branch:** Runway will create a fix entity for every PR against a release branch, which will initiate the fix request flow. 2. **GitHub status check:** Runway will add a GitHub status check to any open cherry-pick fix PRs. The status check will prevent the merge of any cherry-pick fix PRs that have not received the necessary approval in Runway. You can enable fix request GitHub status checks by going to **Require fix approvals > Add pull request status check for fix request approvals**. {% endhint %} If fix approvals are required, Runway will only automatically merge cherry-pick pull requests if the associated fix request has been approved. Fix requests can be approved from the action menu of the work item included in the fix, or from the details drawer of the fix's work item. ![](https://lh7-us.googleusercontent.com/W3M4cwpLYwHYriB_Wzpk9p_hPFu0s0zX7f5-gj_lb9AKlLSfPmthjIsUhnb6d9_1Da6GoEHyuS6X76nLaiQjdZCD3Sjn22BijHNa6G6NvqDSAuQ-PCGXlqRW_XqpwkoTfgY6F4aGbIKLDTT7pT2kdRA)![](/files/QAEcAvfCw1rTpooSDuME) ## Feature readiness automations You can configure the following Feature readiness automations by visiting the **Automations** tab on this step: * [Add missing labels or fix versions to tickets](/automations/types-of-automations#add-missing-labels-or-fix-versions-to-tickets) * [Pull (cherry-pick) fixes into the release](/automations/types-of-automations#pull-cherry-pick-fixes-into-the-release) * [Backmerge changes from the release branch](/automations/types-of-automations#backmerge-changes-from-the-release-branch) * [Post build info to project management tickets](/automations/types-of-automations#post-build-info-to-project-management-tickets) {% hint style="warning" %} Editing automation settings from an individual release will apply those changes to all of your upcoming releases for that app. {% endhint %} ## Feature readiness checklist You can add **checklist items** to this step by visiting the **Checklist** tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # Translations

Strings table found on the Translations release step

### Localizable string items In the Translations step view, Runway pulls together your app’s localizable strings by merging together localizable string keys found in your translations provider with those found in your codebase on the selected branch. Each localizable string row shows: * The source key’s value * The file the source key is in * The source key’s associated localized strings for each supported locale * The computed status of the source key * Source keys that are new or have been updated since the last release (highlighted with a star icon) #### Localizable string statuses Each localizable string will have a status that reflects the state of the string relative to the code on the target branch and the string on the translations provider. There are a few states that a localizable string can be in: * **Synced** — The source key’s value matches the value in the translations provider, and the translations in all languages match what’s found in the code on the target branch * **Upload needed** — The source key’s value in the code has diverged from the source key’s value in the translations provider. This indicates that a change has been made in the code that requires the updated localizable string file to be uploaded for translation. * **Translations pending** — The source key’s value in the code matches the value in the translations provider, but one or more languages have not been translated. * **Export needed** — The source key’s value in the code matches the value in the translations provider, and the key has been translated to all languages. The key and its translations are ready to be exported back into the codebase. * **Branch update needed** — The source key’s value in the code matches the value in the provider, and the key has been translated to all languages and exported to the working branch, but the updated translations have not been pulled into the release branch. {% hint style="success" %} Enable the [Update translations on the release branch from the working branch ](/automations/types-of-automations#update-translations-on-the-release-branch-from-the-working-branch)automation to let Runway automatically pull over up-to-date translations from the working branch to the release branch as needed. {% endhint %} {% hint style="warning" %} Runway supports source key and value parsing for a handful of common file types for each platform. The source values for any localizable string keys found outside of these supported file types will not be parsed. iOS: * `.strings` * `.stringsdict` * `.xcstrings` * `.xliff` Android: * `.xml` * `.xliff` {% endhint %} ### Pending / Done sections Localizable string items are divided into two tables: * **Pending —** Localizable string items are considered Pending if the source key’s value in the selected branch’s code does not match the value in your app’s translations provider, or if any of the source key’s translations in the selected branch’s code do not match the translations in the translations provider. This indicates that either an upload to the provider for translation, or an export from the provider to the code is needed to get the key in sync. * **Done —** Localizable string items are considered Done when the source key’s value and all its translations match between the selected branch’s code and the app’s translations provider. This indicates that the localizable string is fully synced. {% hint style="info" %} Use the **Show new and updated only** filter button to only see localizable strings that were newly added or updated in the current release. {% endhint %} ### Syncing localizable strings When one or more of your localizable strings are out of sync with your translations provider, actions to resolve the state of your localizable strings are available right from the Translations step: * **“Upload localizable strings for translation”** — Any localization files that have at least one localizable string with an Upload needed status will be uploaded to your translations provider for re-translation. * **“Export strings to release branch”** — Runway will open a PR against your target branch containing updated localizable string files for any locales containing strings that have been updated in the translations provider. {% hint style="success" %} When performing a translations export, your team may choose to export to the working branch before pulling over updated strings to the release branch. If you have the [Update translations on the release branch from the working branch](/automations/types-of-automations#update-translations-on-the-release-branch-from-the-working-branch) automation enabled, Runway can automatically do this for you by pulling over exported translations from the working branch to the release branch as needed. {% endhint %} * **“Sync”** — Use this action to let Runway intelligently perform any necessary upload or export (or both) as needed, based on the current state of your localizable strings. {% hint style="success" %} If you have the Sync localizable string translations automation enabled, Runway will automatically keep your translations synced on the release branch by uploading and exporting as needed. {% endhint %} ### Approving the Translations step Your team may choose to go ahead with the release even though not all localizable strings are fully translated and synced. Users with the correct permissions can use the “Approve translations” button to approve the Translations step, regardless of the sync status of localizable strings. # CI The **CI** step can be connected to any CI workflow, whether it's to generate a build, run a script, or trigger any automated process in your CI system. If the CI step is connected to a CI workflow that generates a build, the step will communicate the status and history of builds, and will provide controls to automatically or manually specify which builds are selected for subsequent steps in the release process. ![](/files/m8zPUKZO2KYER59uBDIw) ### Active build Starting with the CI step connected to your Release Candidate CI workflow, Runway will assist you in keeping track of your desired Release Candidate (RC) through the build process, regression and beta testing, upload and selection and submission to the app stores for review, and ultimately releasing the app update to the store. By default, Runway assumes that the latest build from your CI provider is your target RC, but provides the option to [manually select](/using-runway/release-steps/ci#history) a different build if necessary. {% hint style="success" %} Runway will automatically select your latest uploaded build in the app store if the [Select the latest build](/automations/types-of-automations#select-the-latest-build-in-app-store-connect-or-play-console) automation is enabled. {% endhint %} The **active build** module will display workflow status and information about your active build. This will be the latest build that Runway has detected from your Release Candidate CI workflow, unless an earlier build has been manually selected (or ‘frozen’) as the active build for the remainder of the release process. Information available here includes: Build status, CI build number, timestamp of latest workflow status, commit info (branch / commit / message), and artifact download links [if present](/automations/types-of-automations#provide-build-artifact-downloads-and-notify-in-slack-when-available). If Runway was able to link the RC build to a matching upload in the app store, a corresponding app store build number will be shown as well. With the [Auto-generate summary of diff in CI builds](/automations/types-of-automations#auto-generate-summary-of-diff-in-ci-builds) automation enabled, a **Diff Summary** module will appear above this step's artifacts, summarizing what changed between the active build and the previous successful build. {% hint style="info" %} Click the CI build number link to jump to your CI provider's workflow details view. {% endhint %} {% hint style="warning" %} Runway isn’t always able to match a CI build to your selected build in the app store. This can occur if a build was manually uploaded to the app store, or if commit info is missing from your build in CI. Read more on build matching [here](https://docs.runway.team/using-runway/build-matching). {% endhint %} ### History At the bottom of the view, Runway shows a count and a list of all builds (including status and build information) detected from your RC workflow for this version. #### Lock a build as the active RC Release pilots, or other team members with sufficient privileges, can click the **Lock as active RC** button to lock that build in as active for the remainder of the release process. This will affect the target build that is the focus of the Regression testing step, as well as the build selected in the app stores in preparation for submission and release. {% hint style="info" %} If you have the ‘[Select the latest build](/automations/types-of-automations#select-the-latest-build-in-app-store-connect-or-play-console)’ automation enabled and you manually lock a particular RC build, Runway will suspend automatic selection of your latest uploaded build in the app store. {% endhint %} You can revert a manual selection by clicking the **Resume auto-selecting latest build** action above the history list. ### Override status and approve step For some teams, more complex CI workflows could fail but still produce a usable build artifact. In this scenario, you may want to override the status of the CI step and mark it as passed in order to proceed with the new build, and an action will appear at the bottom of the step that allows this. You can undo the override at any time, if needed.
Override status and approve this step button

Override status and approve this step button

### CI automations * [Enable artifact downloads](/automations/types-of-automations#enable-artifact-downloads) * [Upload build artifacts for distribution](/automations/types-of-automations#upload-build-artifacts-for-further-distribution) * [Upload dSYMs to stability monitoring](/automations/types-of-automations#upload-dsyms-to-your-stability-monitoring-provider) * [Auto-generate summary of diff in CI builds](/automations/types-of-automations#auto-generate-summary-of-diff-in-ci-builds) ### CI checklist You can add **checklist items** to this step by visiting the **Checklist** tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # Regression testing The **Regression testing** step is QA's home for communicating the status of regression testing to the rest of the team. Even for teams without dedicated QA, Runway provides an easy-to-use regression testing script tool that can help to catch feature regressions before they become more costly to fix out in the wild. ## Build testing status Use the **build testing status** dropdown to update the status of regression testing on a specific build. You can choose a status of **In progress**, **Passed**, or **Failed** and specify which build the new status applies to. ### Build testing status settings Click **Build testing status settings** to manage how new builds, and status and completion of regression testing items, affect overall build testing status. There are multiple strategies to choose from: * **If Runway detects a new build, clear current build and status** * Requires a build and status to be manually selected in the Build testing status dropdown when testing * **If Runway detects a new build, update selected build and reset status to "In progress"** * **Do not automatically update selected build or status, manual updates only** * **Status of regression testing items determines build testing status** * **Status of regression testing items and checklist items determines build testing status** * **Completion of regression testing items always updates build testing status to Passed** * Build testing status will be set to 'Passed' as long as all regression testing items have a status of passed or failed * **Completion of regression testing items and checklist items always updates build testing status to Passed** * Build testing status will be set to 'Passed' as long as all regression testing items have a status of passed or failed AND all checklist items have been marked as done {% hint style="info" %} Regression testing results can be used to **gate submission or release automations**, because Runway requires this step to be complete (green) **before** automatically submitting an update for review to the app stores. {% endhint %} ## Test runs If you've connected a [regression testing integration](/integrations/regression-testing), Runway will surface information about relevant test runs for each release within the Regression testing step. ![](/files/0PPrO5txjNDMP3PskwK7) {% hint style="info" %} Runway parses test run names for the presence of a version string (e.g. “**2.3.0**”) and any keywords specified in your regression testing integration settings in Runway to pull in the right test runs for each release. {% endhint %} Note that the overall Regression testing step status will still rely on the [build testing status dropdown](#regression-testing-status), so that you can be explicit about the final testing result. ## Regression testing lists From the regression testing step, you can put together a script of testing items that need to be checked by QA or other team members. This list lives across releases, so when you add new items to check, they'll show up as testing items on your next release as well.
Testers can mark an item as **In progress, Passed**, **Failed**, or **Blocked**. A tester can also leave an optional comment to provide additional context. Team members in the user group **QA** will by default have the ability to update the status of regression testing items, but items can also be assigned specific owners. If a regression item is assigned to a user group, any user in the group can update the status of the regression item. **Slack reminders** can be sent for all incomplete regression items, or individually for specific items to remind owners to update the status of their items. ### Managing regression testing lists You can view the list of all existing test items from the initial **Summary** tab. From here you can **Add** items to the list or **Edit** the existing list. If you click the **Edit** button, you'll see additional controls to **Delete** an item, **Edit** an item's details, or re-order the list. Hit **Done** when you're finished making changes. Click the **Add** button to create a new regression item. ### Regression test item components #### Release types Specify which types of releases (major, minor, point, hotfix) require this test item. #### Test item A name for this test item. This appears on the regression testing list itself, as well as notifications related to updates on this item. #### Notify in Slack or Teams when completed Keep this option selected if you want your team to be notified about updates to this testing item during a release cycle. Runway will post in Slack or Teams when this item is marked as Passed, Failed, or Blocked (or was formerly Passed but reverted), as well as who performed the change and when. #### Additional information *Optional* - You can add information here that can easily be surfaced in Runway for team members responsible for testing this item. These notes serve as documentation that will be available on every release cycle. Markdown is supported, and there's a built-in viewer. {% hint style="info" %} For example, you might have a state in your app that requires a specific sequence to test. You could leave a note in **Additional information** that says something like: > Use the coupon code TEST123 to check if the coupon field shows up correctly in the Subtotal table > {% endhint %} #### Owners Regression items can optionally specify user groups or individuals as owners. Designate an owner if a task is intended to be completed by a specific team member (or by a team member from a specific group). Owners — individuals, or any members of the specified group(s) — will be able to update the item's status or leave comments. {% hint style="info" %} In addition to any specified owners / owner groups, anyone with a default or custom role that has the 'Update regression items status' permission will be able to update the status or leave comments on any regression testing item. {% endhint %} ### Regression testing automations You can configure the following App submission automations by visiting the Automations tab on this step: * [Create regression test runs](/automations/types-of-automations#create-regression-test-runs) # Beta testing The **Beta testing** step shows the status of beta testing for the active Release Candidate. If a beta testing integration (TestFlight or Google Play testing track) is active, additional information such as beta testing history, and test details (testers, testing groups, beta testing release notes) will be shown. ![](/files/THy1v9NmrUE9cRav5Iau) ### Beta soak status The **active build** module shows the current status of your beta soak (*i.e.* a minimum period of time allocated to verify that the stability and functionality of your release candidate meets expectations). You can change your preferred beta testing style from either [App settings](/using-runway/app-settings), or from the **Change beta style** link on the Active build module found on the beta testing step. * **Non-blocking** — No beta soak period. The Beta testing step will automatically be shown as complete (green). * **Open-ended soak** — An open-ended beta testing soak period. The Beta testing step will be marked as complete once the soak period is manually ended. * **Time-limited soak** — Set a beta soak duration, in hours. The Beta testing step will be marked as complete once the soak duration has finished. (You can still manually end the beta soak period early.) {% hint style="warning" %} Changing beta style from an individual release will apply that setting to all future releases. {% endhint %} The active build’s status will show as **In testing** while a beta soak period is ongoing, and **Testing complete** when the soak period has ended or was set as non-blocking. ### Active build with a beta testing integration If your team has connected a beta testing integration (TestFlight or Google Play testing tracks), Runway will additionally pull in several more details about your beta testing parameters. * **(iOS) Review status** — If you have external testers participating in beta testing via TestFlight, Apple requires an initial review. Runway will show you the status of your beta review: **Needs review**, **In review**, or **In testing** (the latter means that your build has been approved for external testers). You can manually submit each build for beta review via the button in the active build module, or enable the [Submit new builds for beta review](/automations/types-of-automations#submit-new-builds-for-beta-review) automation. * **(iOS) dSYMs** — Links are surfaced here to download dSYMs from App Store Connect. If the [Download dSYMs from App Store Connect and upload to stability monitoring](/automations/types-of-automations#download-dsyms-from-app-store-connect-and-upload-to-stability-monitoring) automation is enabled, Runway will also show the status of that upload here. * **What to test / Release notes** — Let your testers know what you would like them to test in this build. This information will be available to testers in all groups who have access to this build. * **Testers** — An additional tab will be active that displays all testers added for beta testing. Use the dropdown menu to view members of specific groups. * **(iOS) Groups** — Here, you can enable access to this beta build for additional predefined testing groups. Currently, you’ll need to visit App Store Connect directly to create new Groups, edit existing Groups, or remove Groups that currently have access. All eligible builds are automatically available to users in the App Store Connect Users group (these are considered ‘internal testers’ by Apple). * **(iOS) Individual testers** — View a list of any individual testers (i.e. testers that are not part of a Group) that have been given access to this beta test. Currently, you’ll need to visit App Store Connect directly to edit this list. #### History At the bottom of the view, Runway shows a count and a list of all builds (including final testing status) that have previously been tested for this version release. Expand each row to see further information (dSYMs, release notes, testers). ### Beta testing automations You can configure the following App submission automations by visiting the Automations tab on this step: * [(iOS) Assign beta testing builds to default testing groups](/automations/types-of-automations#assign-beta-testing-builds-to-default-testing-groups) * [(iOS) Submit new builds for beta review](/automations/types-of-automations#submit-new-builds-for-beta-review) * [(iOS) Apply default Export Compliance Information to new builds in App Store Connect](/automations/types-of-automations#apply-default-export-compliance-information-to-new-builds-in-app-store-connect) * [(iOS) Download dSYMs from App Store Connect and upload to stability monitoring](/automations/types-of-automations#download-dsyms-from-app-store-connect-and-upload-to-stability-monitoring) * [(Android) Promote new builds to testing track](/automations/types-of-automations#promote-new-builds-to-testing-track) ### App submission checklist You can add **checklist items** to this step by visiting the Checklist tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # Screenshots On the **Screenshots** step, you can view, add, remove, and approve screenshot and preview videos that are currently staged to go out with this release in the app store for Apple and Google platforms.
### Viewing screenshots and preview videos Use the **Device** selector to switch between assets for different device sizes or alternate hardware types. You can click on any given screenshot or preview video to view it in full size. {% hint style="info" %} If a particular size is set to share assets from another size on iOS/tvOS platforms, you’ll see a “Using XX Display” message. {% endhint %} Each localization for your app will be displayed in a separate tab. * A green status dot will appear on tabs where specific assets have been found for that localization, and minimum app store requirements have been met. * An orange status dot will appear on tabs where required assets are still missing. ### Editing screenshots Screenshots and preview videos can be added or removed for a given device size. Note that screenshot re-ordering is currently not supported. {% hint style="info" %} Videos cannot be directly edited on the Screenshots step for Google platform apps. To edit a video go to the [Metadata step](/using-runway/release-steps/metadata) and add or update the YouTube Video URL field. {% endhint %} {% hint style="warning" %} For upcoming releases, the version must exist in the App store in order to edit screenshots. {% endhint %} ### Approval Granting approval for screenshots is a way for your team to communicate in Runway that screenshots have been verified on each release. {% hint style="warning" %} App stores are not affected by the approval status of the Screenshots step in Runway. Missing approvals on the Screenshots step will not block a manual submission or release performed from Runway or from the app stores. {% endhint %} Release pilots or other users with sufficient privileges can click the **Approve screenshots** button at the bottom of the view to mark this step as ready. This will set the Screenshots step as green/ready (and may unblock automations like [Submit app for review on target date](/automations/types-of-automations#submit-app-for-review-on-target-date) that depend on all previous steps being green). Approval can be reversed by users with sufficient privileges by clicking the **Rescind screenshots approval** button. This will return the step status to orange and may block automations that depend on this step being green/ready. ### Screenshots checklist You can add checklist items to this step by visiting the Checklist tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # Metadata From the **Metadata** step, you can edit and review version release notes (also referred to as ‘What’s New in this Version’ for iOS) and other release metadata that will be reflected in the app stores upon release of the current version. Certain app-level metadata fields (e.g. App name, App subtitle) can also be edited from this step.
{% hint style="info" %} Within Runway, you can proactively edit metadata for upcoming releases even before the version exists in the App store. {% endhint %} ### Release notes / What’s New in this Version Enter the release notes for your upcoming version here. If you have defined [default release notes in App Settings](/using-runway/app-settings#default-app-store-play-store-release-notes), you can click the **Apply default release notes** button to pull in your default notes. * A green status dot will appear on tabs where notes have been filled in for that localization. * An orange status dot will appear on tabs where required notes are still missing. Each available localization will be displayed in a dedicated tab. {% hint style="success" %} If you turn on the [Apply default release notes](/automations/types-of-automations#apply-default-whats-new-text-to-new-releases-in-app-store-connect) automation, Runway will automatically apply your default notes to each release. {% endhint %} You can choose to **Save \[Region] changes** on each tab individually, or **Save all changes** via the button at the bottom of the view. Save actions will send your changes to App Store Connect or the Play Console. #### Autogenerate release notes Using AI, Runway automatically drafts release notes by analyzing project management tickets and code changes (PRs and commits only, not the source code itself). When used for app store submissions, Runway tailors the notes to meet platform-specific requirements, such as character limits and disallowed characters.
{% hint style="success" %} Runway does not maintain or train any AI models on customer data, nor is our AI provider allowed to train on any of our customers' data. {% endhint %} For more structured outputs, Runway can generate changelogs that focus either on the release’s code diff or the associated project tickets. You can also define template-based release notes with dynamic tokens (e.g., `{workItems}` ,`{contributorsCount}`, `{releasePilot}`), which Runway fills in automatically based on the release context. {% hint style="info" %} All of the above options are available in Runway wherever you can enter different kinds of release notes: store metadata, release description, release summary, and beta testing notes. Read more about [allowed tokenized patterns for release notes here.](/getting-started/pattern-strings-tokens) {% endhint %} #### Feature list Click the **Feature list** button on any tab to open a drawer listing new work that is appearing in the current release. This is a list of ticket titles that are associated with the current version. {% hint style="info" %} The feature list can be handy in situations where an outside team member (often from Design or Marketing) is tasked with writing user-friendly release notes, but may not be familiar with the work going into the release. {% endhint %} ### Additional metadata fields See below the complete list of metadata fields that can be currently edited from Runway for each platform. #### iOS * Keywords * Promotional text * App name * App subtitle * App description #### Android * Short description * App name * Video URL {% hint style="warning" %} Some metadata fields don't need to be submitted as part of a version update and will be submitted for review as soon as they're saved/updated in Runway. {% endhint %} ### Approval Granting approval for metadata is a way for your team to communicate in Runway that metadata have been verified on each release. {% hint style="warning" %} App stores are not affected by the approval status of the Metadata step in Runway. Missing approvals on the Metadata step will **not** block a manual submission or release performed from Runway, or those performed directly from the app stores. {% endhint %} Release pilots or other users with sufficient privileges can click the **Approve metadata** button at the bottom of the view to mark this step as ready. This will set the Metadata step as green/ready (and may unblock automations like [Submit app for review on target date](/automations/types-of-automations#submit-app-for-review-on-target-date) that depend on all previous steps being green). Approval can be reversed by users with sufficient privileges by clicking the **Rescind metadata approval** button. This will return the step status to orange and may block automations that depend on this step being green/ready. ### Metadata translations If you have a Translations integration connected to your app, you can use Runway's Metadata step to upload release metadata for translation, and export translated metadata from your translations provider to the relevant app store. The translation status of each metadata field for each locale will be shown as follows: * **Synced** – the field's value has been translated and synced to App Store Connect or Play Console. * **Export needed –** the field's value has been translated but an export is required to sync the latest translation to App Store Connect or Play Console. * **Waiting for translation –** the field's updated source value has been uploaded and is pending translation in your translations provider. * **Upload needed –** the field's source value has been updated in Runway but haven't yet been uploaded to the translations provider. {% hint style="warning" %} Due to a Crowdin API limitation, if you use the Crowdin Translations integration, your translated and approved translation strings will appear as untranslated in Runway until all metadata fields are translated and approved. {% endhint %} **Uploading metadata for translation** To upload new release metadata for translation, save changes to the desired metadata fields in your app's **source locale.** You can then manually trigger an upload using the **Upload for translation** button – updated source value release metadata will be uploaded for translation to your your translations provider. **Exporting translations to App Store Connect or Play Console** To export translated metadata to App Store Connect or Play Console, you can manually trigger an export using the **Export translated metadata** button from the Metadata step. Any locales that have complete metadata translations in your translations provider will be exported to App Store Connect or Play Console and synced to Runway. {% hint style="success" %} Enable the [Sync metadata translations automation](/automations/types-of-automations#sync-metadata-translations) to have Runway automatically upload updated source locale metadata for translation, and export translated metadata to App Store Connect or Play Console as needed. {% endhint %} ### Metadata automations You can configure the following Metadata automations by visiting the **Automations** tab on this step: * [Apply release notes to new releases in App Store Connect or Play Console](/automations/types-of-automations#apply-whats-new-text-or-release-notes-to-new-releases-in-app-store-connect-or-play-console) * [Sync metadata translations](/automations/types-of-automations#sync-metadata-translations) * [Sync release metadata from version control](/automations/types-of-automations#sync-release-metadata-from-version-control) {% hint style="warning" %} Editing automation settings from an individual release will apply those changes to all of your upcoming releases for that app. {% endhint %} ### Metadata checklist You can add checklist items to this step by visiting the Checklist tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # Approvals The **Approvals** step is a great way to get final sign-off from stakeholders before a release moves into its final stages (typically, before an app update is submitted to the stores for approval). Approvers can mark an item as **In progress, Approved**, **Rejected**, or **Blocked**. An approver can also leave an optional comment to provide additional context. Team members with an assigned role of **Approver** will have the ability to update the status of Approval items, but will otherwise have read-only access to the rest of Runway. {% hint style="info" %} Approvals can be used to **gate submission or release automations**, because Runway requires the Approvals step to be complete (green) **before** automatically submitting an update for review to the app store. For example, your team might need the Compliance department to give you the green light for every app update, or you might have a VP of Product who wants to stay in the loop. {% endhint %} ### Managing approval lists You can view the list of all existing Approval items from the initial **Summary** tab. From here you can **Add** items to the list or **Edit** the existing list. If you click the **Edit** button, you'll see additional controls to **Delete** an item, **Edit** an item's details, or re-order the list. Hit **Done** when you're finished making changes. Click the **Add** button to create a new Approval item. ### Approval item components #### Release types Specify which types of releases (major, minor, point, hotfix) require this Approval. #### Approval item A name for this Approval item. This appears on the Approval list itself, as well as notifications related to updates on this item. #### Notify in Slack or Teams when completed Keep this option selected if you want your team to be notified about updates to this item during a release cycle. Runway will post in Slack or Teams when this item is marked as Approved, Rejected, or Blocked (or was formerly Approved but reverted), as well as who performed the change and when. #### Additional information *Optional* - You can add information here that can easily be surfaced in Runway for team members responsible for approving this task. These notes serve as documentation that will be available on every release cycle. Markdown is supported, and there's a built-in viewer. {% hint style="info" %} For example, your Legal department might need quick tips on how to download and view the latest build in order to sign off. You can leave those instructions in 'Additional information' and they'll be easy to find on each release. {% endhint %} #### Owners Approval items can optionally specify user groups or individuals as owners. Designate an owner if an approval is intended to be granted by a specific team member (or by a team member from a specific group). Owners — individuals, or any members of the specified group(s) — will be able to update the item's status or leave comments. {% hint style="info" %} In addition to any specified owners / owner groups, anyone with a default or custom role that has the 'Update approval items status' permission will be able to update the status or leave comments on any approval item. {% endhint %} # App submission Use the **app submission** step to verify or change your selected release candidate build in app stores, review any final release settings, and submit your update for review. ![](/files/MOn3zDZVnqoImkY6FW8G) ### Release workflow If a **release workflow** or **deploy branch** is defined in your settings — for teams that produce different builds for staging/RC and production — you will see an additional module that displays the status of your production build workflow, along with a **Run workflow** action. See our [Builds and Branches](/getting-started/setting-up-your-integrations/builds-and-branches) article for additional information about configuring Runway for multiple build workflows. ### Selected build in app store
The **selected build** module indicates which build is currently selected in the relevant app store, as well as its matching CI build identifier. {% hint style="warning" %} Runway isn’t always able to match a CI build to your selected build in the app store. This can occur if a build was manually uploaded to the app store, or if commit info is missing from your build in CI. {% endhint %} You can click the **Change selected build** action to switch the build that will be submitted for review. The list of builds will also show linked app store and CI build identifiers if available. {% hint style="warning" %} (iOS) Builds can take up to five minutes to show up in Runway after being uploaded to App Store Connect. {% endhint %} {% hint style="success" %} Runway will automatically select your latest uploaded build in the app store if the ‘[Select the latest build](/automations/types-of-automations#select-the-latest-build-in-app-store-connect-or-play-console)’ automation is enabled. Note that Runway will **stop** automatically selecting the latest build if it detects that a build was manually selected either in Runway, or in App Store Connect or the Play Console. {% endhint %} ### (iOS) Additional review submission items Additional items (custom product pages or in-app events) can be included alongside your app version submission. To add an item to your review submission, use the **Add item** button visible on the App submission step. Additional items included in your review submission can be removed from the submission bundle anytime prior to version submission. {% hint style="warning" %} Once a review submission bundle has been submitted for review, individual items included in the submission cannot be modified or removed. To remove an item from a submitted bundle, you must first pull the bundle from review. {% endhint %} #### Handling items blocking review submission If you see an error that the submission is blocked, you can choose one of the following options: * Select "Unblock submission" from Runway. This will pull the current submission down and will then submit your new release with the previously submitted items included. {% hint style="danger" %} The "Unblock submission" action pulls the current blocking item(s) from review before resubmitting and therefore **restarts** the App Store Connect review process. {% endhint %} * Manually pull the review in App Store Connect and resubmit the new items with the previously submitted items. #### Handling review submission issues If there's a problem with one or more of your review submission items, you can choose one of the following options: * Remove the problematic review submission item and proceed with the release of approved items. You can do this from Runway. * Manually resolve the problematic review submission item by going in to App Store Connect — this may involve making changes to the item, or answering questions posed by the App Store Review team. Note that manual item resolution is not currently supported within Runway. * Pull your review submission bundle from review and resubmit. ### (iOS) App Store Connect release settings This module reflects current settings for this app version in App Store Connect. * Version release * Automatically release this version * Automatically release this version after App Review, no earlier than a specified time * Manually release this version {% hint style="warning" %} If you want Runway to automate the release of your app update, the **Version release** setting in App Store Connect should be set to **Manual**. {% endhint %} For more details on version release options, visit :link: [Apple’s documentation](https://help.apple.com/app-store-connect/#/devf7c309ab5). * Phased release * Off * On — When choosing this option, Apple will automatically increase your phased release percentage in the App Store each day over a 7-day period. {% hint style="info" %} Phased release sequence: 1% of users on Day 1, 2% on Day 2, 5% on Day 3, 10% on Day 4, 20% on Day 5, 50% on Day 6, and 100% on Day 7. {% endhint %} For more details on Phased releases, visit :link: [Apple’s documentation](https://help.apple.com/app-store-connect/#/dev3d65fcee1). ### App review information Here, you can verify key information that will be passed along to Apple’s reviewers here. To make changes, or to view all available fields, visit App Store Connect directly. * **Contact** — Information for the contact person in your organization if the App Review team needs additional information. * **Sign-in required** — Sign-in information for a demo account, if relevant. * **Review notes** — Additional information about your app that can help during the review process. For more details on App review information, visit :link: [Apple’s documentation](https://help.apple.com/app-store-connect/#/devbef8ace74). ### (Android) Retained builds (Additional builds) In certain cases for Android releases, you may want to include one or more past builds alongside new builds with your submission – this is known as *retaining* builds in the Play Console. To choose past builds to include (retain) with your submission, click the dropdown on the right of "Change selected build", and click "Include build(s) from a previous release". Choose the past builds that you would like to retain and include alongside new builds with your submission. Runway will automatically include the past builds you select when submitting your app for review. {% hint style="info" %} Runway will automatically carry over any chosen retained builds to upcoming releases. You can stop retaining builds at any time by simply clearing the selection and saving. {% endhint %} ### (Android) Release settings This module reflects the settings that Runway will use when submitting your app for review with Google. {% hint style="danger" %} **A note on Google review:** Because of a limitation with the Google Play Publishing API, Runway is unable to differentiate between updates that are in review with Google and those that have been released to the Google Play Store. Because of this, when you submit an Android build for review, Runway's Submission, Review, and Release steps will appear ready (green), though they may still be in review with Google. {% endhint %} {% hint style="warning" %} Due to a limitation with the Google Play Publishing API, Runway cannot offer support for Managed Publishing. If you have Managed Publishing enabled on the Google Play Console, you must manually publish updates from there. Additionally, the status of an update may appear as **Released** or **Staged Rollout** **In Progress** in Runway even if it has not yet been made available for users via the Play Console. {% endhint %} * Staged rollout * Don’t stage, release updates to all users immediately * Staged rollout to a percentage of users * Initial staged rollout percent * Select the percentage of users who will receive your rollout when initially released. {% hint style="info" %} Your app's staged rollout percentage won't increase automatically by default. Runway offers a [Customized staged rollouts](/automations/types-of-automations#customized-android-staged-rollouts) automation that you can configure and enable to effect multi-day rollouts with increasing staged percentages (similar to Apple's 7-day phased releases, but more customizable). {% endhint %} * Set in-app update priority for Google Play Console releases * Indicate how strongly to recommend a given update to users by selecting a number between 0 (default) to 5 (highly recommend). For more information on how to use this setting, see Google's [update priority documentation](https://developer.android.com/guide/playcore/in-app-updates/native#update-priority).

### App submission automations You can configure the following App submission automations by visiting the Automations tab on this step: * [Submit app for review on target date](/automations/types-of-automations#submit-app-for-review-on-target-date) * [Select the latest build in App Store Connect or Play Console](/automations/types-of-automations#select-the-latest-build-in-app-store-connect-or-play-console) * (iOS) [Apply default Export Compliance Information to new builds in App Store Connect](/automations/types-of-automations#apply-default-export-compliance-information-to-new-builds-in-app-store-connect) * [Upload build artifacts for distribution](/automations/types-of-automations#upload-build-artifacts-for-further-distribution) * (iOS) [Upload dSYMs to stability monitoring](/automations/types-of-automations#upload-dsyms-to-your-stability-monitoring-provider) ### App submission checklist You can add **checklist items** to this step by visiting the Checklist tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # App store review From the **App store review** step (which may appear as “**App Store review**”, “**Play Store review**”, etc depending on your selected distribution platform), you can quickly see the status of your app update as it goes through the store review process.
### Available actions: * (iOS) **Developer Reject** — Pull your in-progress submission from the review queue. * (Android) **Mark submission rejected by Google** — Manually flag a submission as having been rejected by Google. {% hint style="info" %} If you wish to pull a release from review, or if your release is stuck in a rejected state, navigate to the [App submission](/using-runway/release-steps/app-submission) step and select 'Pull from review' to proceed with submitting a new build. {% endhint %} {% hint style="warning" %} Due to a limitation with the Google Play Publishing API, Runway cannot offer support for Managed Publishing. If you have Managed Publishing enabled on the Google Play Console, you must manually publish updates from there. {% endhint %} ### Selected build in app store The selected build module indicates which build was submitted for review, as well as its matching CI build identifier. This module will only appear after your app update has been submitted for review. {% hint style="warning" %} The selected build can’t be changed after your app update has been submitted for review. If needed, you can Developer Reject the current submission to select a different build, and then re-submit for review. {% endhint %} ### (iOS) App review information Here, you can view and edit key information that will be passed along to Apple’s reviewers. * **Contact:** Information for the contact person in your organization if the App Review team needs additional information. * **Sign-in required:** Sign-in information for a demo account, if relevant. * **Review notes:** Additional information about your app that can help during the review process. * **Review attachment:** The review attachment file that will be made available to reviewers, if present. For more details on App review information, visit :link: [Apple’s documentation](https://help.apple.com/app-store-connect/#/devbef8ace74). ### App store review automations You can configure the following App store review automations by visiting the Automations tab on this step: * [(iOS) Apply default review attachment to new app versions in App Store Connect](/automations/types-of-automations#apply-default-review-attachment-to-new-app-versions-in-app-store-connect) ### App submission checklist You can add **checklist items** to this step by visiting the Checklist tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). # Release The **Release** step shows you the status of your final app update once it has been published, including phased release status, a release summary, and any final release tasks, such as tagging the completed release.
### Build released in App Store / Play Store This module indicates which build was submitted for review, as well as its matching CI build identifier. #### Stability If you have a stability integration connected, you’ll see a short summary here of top line crash rates (rate of crash-free users and rate of crash-free sessions expressed as a percentage), adoption rate, and a list of most frequently occurring crashes with this release. Crashes that are new in the current version will appear in the "New" tab of the stability section. ### Phased release and staged rollout status If your app's platform supports phased rollouts and the current version was released as a phased rollout, a module showing phased release status is shown, with actions to pause or accelerate rollouts manually available from here. ### Release summary The default release summary includes stats on your release like number of work items completed, number of contributors to the release, the release duration, and more. You can configure the default 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. {% hint style="success" %} You can also have your release summary automatically distributed via email if you enable the [Distribute release summary at the end of each release cycle](/automations/types-of-automations#distribute-release-summary-at-the-end-of-each-release-cycle) automation. {% endhint %} ### Automated release tasks These tasks can be automatically performed by Runway once your app is released, but can also be performed manually from the "Automated release tasks" module. * **Release tagging** — The status of your final release tag for this version, with direct links to the tagged release and final tag commit in your version control system. If needed, you can select or update the tag commit here. {% hint style="success" %} Runway can automatically tag your releases at the end of the release cycle via the [Tag releases at the end of the release cycle](/automations/types-of-automations#tag-releases-at-the-end-of-the-release-cycle) automation. If supported by your VCS provider, a "Release" is also automatically created in your VCS, which includes a list of all commits and their associated project management tickets that were included in the release. {% endhint %} ### Release automations You can configure the following step automations by visiting the Automations tab: * [Release app](/automations/types-of-automations#release-app-on-target-date) * [Tag releases at the end of the release cycle](/automations/types-of-automations#tag-releases-at-the-end-of-the-release-cycle) * [Attach build artifacts to VCS release record when tagging](/automations/types-of-automations#attach-build-artifacts-to-vcs-release-record-when-tagging) * [Mark releases as completed in project management tool](/automations/types-of-automations#mark-releases-complete-in-project-management-tool) * [Halt unstable phased releases](/automations/types-of-automations#halt-unstable-phased-releases) * [Backmerge changes from the release branch](/automations/types-of-automations#backmerge-changes-from-the-release-branch) * [Release stable phased releases to 100% of users](/automations/types-of-automations#release-stable-phased-releases-staged-rollouts-to-100-of-users) * [Delete version-specific release branches at the end of the release cycle](/automations/types-of-automations#delete-version-specific-release-branches-at-the-end-of-the-release-cycle) * [Update status of issue tracking tickets upon release completion](/automations/types-of-automations#update-status-of-issue-tracking-tickets-upon-release-completion) * [Distribute release summary at the end of each release cycle](/automations/types-of-automations#distribute-release-summary-at-the-end-of-each-release-cycle) * [Prepare rollback releases](/automations/types-of-automations#prepare-rollback-releases) * [Customized phased rollouts](/automations/types-of-automations#customized-ios-phased-rollouts) * [Customized Android staged rollouts](/automations/types-of-automations#customized-android-staged-rollouts) ### Release checklist You can add checklist items to this step by visiting the Checklist tab. [Checklist items](/using-runway/checklists) cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed). \
\
# Flightpaths For organizations that need to streamline a more complex release process, like cross-platform, white labeling, or advanced workflows with multiple instances of '[steps](/using-runway/release-steps#release-steps)', **Flightpaths** enables you to configure modular setups to manage branching, multi-step workflows as a single, cohesive release. This can help (for example) to provide a greatly simplified workflow and a clearer understanding of the status of multiple apps that are going through the release process in tandem. Additionally, you'll be able to apply the same settings across all apps within the flightpath, reducing setup time and the risk of forgetting to apply certain settings to multiple apps. Here are some example scenarios that are ideal use cases for leveraging Flightpaths: * **White label**: same codebase used to ship multiple variations of the same app. * **Multi-platform**: the same codebase used to build across multiple platforms, such as iOS and tvOS apps, or Android and wearOS apps. * **Multi-store**: the same codebase used to build a single APK that is distributed to different app stores, such as Google Play Console and Amazon Appstore. * **Cross-platform**: same codebase used to build iOS and Android apps that go to their respective app stores. * **Mature teams with complex releases**: customize Runway to perfectly capture all the different steps and dependencies that exist in your release process. Whether you’re shipping for mobile, TV, wearables, auto or all of the above, you can manage and automate releases exactly how you want to. ### Key definitions * **Step archetype:** these are the different steps along the release management journey. They consist of **Kickoff**, **Feature readiness**, **Translations**, **Release candidate**, **Regression testing**, **Beta testing**, **Screenshots**, **Metadata**, **Approvals**, **App submission**, **App store review**, **Release,** and **Rollout**. {% hint style="info" %} Runway currently supports multiple instances of **Release candidate**, **Beta testing**, **Regression testing**, **Screenshots**, **Metadata**, **Approvals**, **App submission**, **App store review**, **App store Release,** and **Rollout** steps within one Flightpaths workflow. {% endhint %} * **Step configuration:** a unique instance of a step (of a specific archetype) within a Flightpaths workflow. * **Flightpaths workflow:** a collection of step configurations and settings describing your team’s process for releasing one or more apps. ### Explaining Flightpaths with examples #### White label Mercury is a white label iOS app with 6 flavors. All apps follow the same release schedule and are built via the same CI workflow, but are released via different apps in the same App Store Connect account. As part of this team's release process, this team has a rollout step pointing to the beta build, and a separate rollout step pointing to the production build. | Step archetype | Step configuration | | -------------------- | ------------------------------------------------------------------------------------------------ | | Kickoff | 1 step for 6 iOS apps | | Feature readiness | 1 step for 6 iOS apps | | Translations | 1 step for 6 iOS apps | | Release candidate | 1 step for 6 iOS apps | | Regression testing | 1 step for 6 iOS apps | | Beta testing |

6 steps

| | Rollout (beta) |

6 steps

| | Screenshots |

6 steps

| | Metadata |

6 steps

| | Approvals | 1 step for 6 apps | | App submission |

6 steps

| | App store review |

6 steps

| | Release |

6 steps

| | Rollout (production) |

6 steps

| #### Cross-platform Gemini is a cross-platform, React Native app that builds both an iOS and Android app. Both apps follow the same release schedule so that they’re released to users as close to the same time as possible. Gemini leverages the same CI workflow to build its release candidates. During beta testing, Gemini typically goes through both alpha and beta testing before the apps progress to the next step in the release process. In this scenario, Gemini would have the following Flightpaths workflow setup: | Step archetype | Step configuration | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Kickoff | 1 step for iOS & Android apps | | Feature readiness | 1 step for iOS & Android apps | | Translations | 1 step for iOS & Android apps | | Release candidate | 1 step for iOS & Android apps | | Regression testing | 1 step for iOS & Android apps | | Beta testing |

4 steps

| | Screenshots |

2 steps

| | Metadata |

2 steps

| | Approvals | 1 step for iOS & Android apps | | App submission |

2 steps

| | App store review |

2 steps

| | Release |

2 steps

| #### Mature teams requiring flexibility Appollo is built natively in iOS and Android. Since different teams build each app, both iOs and Android Appollo apps will remain separate within Runway. However, both teams wish to have multiple CI steps and Approval steps throughout their release process. The below example focuses on just the iOS app, but both apps could be configured similarly. | Step archetype | Step configuration | | --------------------------------------------------------------------- | ------------------------------------- | | Kickoff | 1 step for 1 iOS app | | Feature readiness | 1 step for 1 iOS app | | Translations | 1 step for 1 iOS app | | Release candidate | 1 step for 1 iOS app | | Regression testing | 1 step for 1 iOS app | | CI step (triggers CI workflow once regression testing step is Passed) | 1 step for 1 iOS app | | Beta testing | 1 step for 1 iOS app | | Screenshots | 1 step connected to App Store Connect | | Metadata | 1 step connected to App Store Connect | | Approval (submission) | 1 step for 1 iOS app | | App submission | 1 step connected to App Store Connect | | Approval (release) | 1 step for 1 iOS app | | App store review | 1 step connected to App Store Connect | | Release | 1 step connected to App Store Connect | | Rollout | 1 step for 1 iOS app | # Release schedule View key dates for active, upcoming, and past releases. The release schedule view shows key release dates for active, upcoming, and past releases in a calendar view. It can be accessed at the app level, which will show all releases for the app, or at the release level, which will surface key events only for the given release. The app level release schedule will also predict release cycles into the future, so you can better plan ahead for upcoming releases in the calendar year. {% hint style="info" %} Runway will use your app's configured schedule cadence to predict upcoming release cycles if set, otherwise it will estimate key release cycle dates by analyzing timing patterns observed from past releases in Runway. {% endhint %} The following key release cycle events can be seen on the release schedule: * Release kickoff dates * Release submission dates * Version release dates (Apple platforms only) * Custom staged rollout dates * Phased rollout dates ## Pausing your release schedule You can pause your release schedule at any point from the schedule view on **any release**. Pausing your release schedule will prevent any scheduled [kickoff](/automations/types-of-automations), [submit](/automations/types-of-automations#submit-app-for-review), or [release](/automations/types-of-automations#release-app) automations from triggering. All other configured and enabled automations will continue to execute as normal. * Your scheduled release automations will appear as **Paused** under the release schedule view, and within the **Automation tab** of each release step When you're ready to resume your schedule, click **Resume schedule** from the schedule view on **your current release**. Runway will resume the execution of any scheduled upcoming kickoff, submit, or release automations. {% hint style="warning" %} If pausing your schedule has caused an automation to miss its target date, you'll have to manually update to a new target date in the future in order for Runway to perform the automation. You can do this by going to **Kickoff** -> **Edit release settings** for the release. {% endhint %} ## Scheduling a lifecycle freeze You can schedule to freeze any planned [release cycle automations](/automations/types-of-automations#release-cycle) (e.g. kickoff, submit, release) from occurring during selected dates by navigating to your app's **Schedule** settings and selecting "Add lifecycle freeze dates to prevent release events." You can schedule an unlimited number of lifecycle freezes. For each lifecycle freeze, you can select which release cycle automations you wish to freeze. If a planned release cycle automation is scheduled to run during a lifecycle freeze, Runway will consider the release paused and will not perform any release cycle automations. Once the freeze ends, the release will automatically resume according to the release schedule. Additionally, if a release was already kicked off before the freeze, Runway will pick up where it left off and continue running the release cycle automations for the previously kicked off release. If a rollout begins prior to a lifecycle freeze, the rollout will not be paused during the lifecycle freeze; however, if a rollout is scheduled to begin during a lifecycle freeze, then the rollout will not be started. The freeze period considers the beginning of the first date until the end of the second date. In the example below, the freeze period would be 12am on July 12 - 11:59pm on July 14.
Select lifecycle freeze dates

Select lifecycle freeze dates

## Calendar integration capability Runway offers an external calendar integration capability that will sync your Runway release calendar to an external calendar, for example, a Google calendar. Additionally, any custom events that are added to your external calendar will also be pulled in and displayed in Runway's release schedule calendar view. For more information, visit the [Calendar integration capability documentation](/integrations/calendar). # Rollout {% hint style="warning" %} This feature is limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) to learn more. {% endhint %} The Rollout view helps you to navigate release rollouts with less collective stress, and more confidence, by creating a unified dashboard that gives your team a complete and instantly understandable picture of release health. Here, you’ll have one place to monitor live signals from across all the different tools you typically use to measure app health: crash reporting, observability & product analytics, the app stores (for per-version user ratings). Additionally, this view provides a visual status of the progress of phased releases, adoption percentage, and the state of rollout-related automations (and their associated health metrics). ### Integrations Runway can take advantage of a number of types of integrations to pull together a complete picture of the health of your release: * [Stability monitoring](/integrations/stability-monitoring) * [Observability & analytics](/integrations/observability-and-analytics) * [App store](/integrations/app-stores) #### Defining product health metrics To get the most value out of the Rollout view, we recommend configuring health metrics – your team's unique definition of “healthy” – by visiting **Settings > Health metrics**. {% content-ref url="/pages/2n4xZ3NWq2GgYJbuepw0" %} [Health metrics settings](/using-runway/app-settings/health-metrics-settings) {% endcontent-ref %} ### Summary cards At the top of the Rollout view, you’ll see a number of small cards with at-a-glance, live data about your release and its health, each with visual cues that communicate the status of those particular metrics (progress percentages, and indicators of healthy vs unhealthy if your team has [set up health metric definitions](/using-runway/app-settings/health-metrics-settings)). Certain cards are shown by default, and others are surfaced based on key events you have selected in corresponding integration settings. Default cards include: * Crash-free rate (sessions and users) * Both metrics are calculated over the release's lifetime. * Crash-free rate sessions calculation is: `(1 - (crashedSessionsCount) / totalSessionsCount)) * 100` * Crash-free rate users calculation is: `(1 - (crashedUsersCount) / totalUsersCount)) * 100` * User ratings
Additional summary cards are populated based on the Observability & Analytics integrations (and associated events) you've configured. For a complete list of all metrics shown in the Rollout view, visit the [Metric Types documentation](/using-runway/app-settings/health-metrics-settings#metric-types). ### Phased release {% hint style="info" %} Supported for apps being distributed through the Apple App Store and Google Play Store only. {% endhint %} Here, you’ll find more granular detail about: * Adoption rate — Adoption rate of the current version, relative to your other most adopted versions * This requires a Stability monitoring integration * Rollout status — Phased release status, with available actions to pause or accelerate rollouts manually, or quickly kick off a hotfix * Requires App store integration * Automations — Details about [rollout-related automations](/automations/types-of-automations#release-stable-phased-releases-staged-rollouts-to-100-of-users) in Runway, including configured rulesets and current status ### Detail cards & graphs Additional sections on the Rollout view will provide additional detail on the following categories of data: * **Stability** — Data from your stability monitoring integration, as well as detail on top crashes found in the current version. * For each stability issue, you’ll see the number of times that it has occurred both in the current release and across all releases. Clicking into a specific issue will show further details, including the file and line number the issue occurred on, and a stack trace. * **Observability & analytics** — Data on key events from your observability & analytics integration. * **Reviews** — Average user rating and recent reviews for the current version, from users in the App Store or Play Store. [Review issues](#review-issues) are also surfaced in this section. {% hint style="info" %} Review rating surfaced in the **Rollout** view is always the average user rating per version, rather than a time-based aggregate of ratings across multiple versions.\ \ Due to limitations in the Google Play Developer API and App Store Connect API, Runway calculates Android and iOS user review averages per version using **only written reviews**. This means the per version averages shown in Runway may differ from those in Google Play Console and App Store Connect. {% endhint %} Along with topline metrics, you’ll find graphs showing how things have tracked over time, as well as how things look relative to your team’s [configured health thresholds](/using-runway/app-settings/health-metrics-settings) (if they’ve been configured for the metric in question). For more detail on how data for each metric type is calculated, visit the [Metric Types documentation](/using-runway/app-settings/health-metrics-settings#metric-types).
{% hint style="info" %} Rollout graphs show recent data points for each available metric. In the first 24 hours after a release goes live, graphs will show the most recent data points – usually one every 10 or so minutes. After 24 hours, graphs will show the last collected data point for each day since the release went live. Note that there is sometimes a small delay between when the release went live and when version data is available for a given metric. {% endhint %} Finally, each graph will show if there’s an associated automation that is set to trigger (or already has) if healthy — or unhealthy — conditions have been met. ## Review issues Runway can automatically detect potential issues with your app by scanning user reviews posted in the app stores to highlight issues that might not otherwise appear on crash reports, observability data, or product analytics. Using AI, Runway filters signals from noise by parsing through user reviews to identify commonly mentioned issues. Issues are then surfaced alongside recent reviews in Rollout and App Overview pages.
{% hint style="success" %} Runway does not maintain or train any AI models on customer data, nor is our AI provider allowed to train on any of our customers' data. {% endhint %} # Hotfixes Hotfix releases in Runway are special releases that are created off the previous release tag rather than off your team's main working branch. In Runway, the hotfix release process is designed to be as streamlined as possible, and in some cases have special behavior to be aware of. ## Preparing hotfix releases You can create a hotfix release in the Runway app by clicking **Prepare release > Hotfix**.
You can then choose to create a roll-forward hotfix release by branching off your previous release's tag, or preparing a rollback release. For more information on how to set up, create, and ship rollbacks, visit the [Rollbacks ](/using-runway/rollbacks)documentation. By default, roll-forward hotfixes will branch off your live release's tag. You can choose whether you'd like Runway to immediately create a hotfix release branch and bump the version. If you leave these two options unchecked, you will still be able to manually create the release branch and bump the version from the Kickoff step, but doing it as part of the prepare hotfix flow helps streamline the process. {% hint style="success" %} If your team uses a special release branch pattern for hotfix releases (e.g. hotfix-{version}), you can configure that in **Integrations > Release branch patterns**. {% endhint %} #### Pulling in (cherry-picking) fixes You can also optionally select one or more commits from the working branch to pull in as fixes directly. Runway will attempt to cherry-pick the selected commits into the hotfix branch immediately. {% hint style="info" %} If Runway is not able to cherry-pick directly to a release branch due to GitHub settings, Runway will create a PR in GitHub. In order to complete the cherry-pick, force-pushes must be allowed on the hotfix branch or on the PR branch in GitHub. {% endhint %} {% hint style="info" %} Conflicts can sometimes prevent Runway from cherry-picking in selected commits. When that happens, Runway will proceed with creating the hotfix release branch and bumping the version if needed, but will notify of the cherry-pick failure. {% endhint %} {% hint style="info" %} This functionality is supported in GitHub and GitLab. {% endhint %} ## Hotfixes and automations To streamline the hotfix process, Runway will by default skip performing certain automations for hotfix releases. Automations that will be skipped for hotfixes are shown with an **Inactive** status in the Automations tab for the relevant step. #### Automations that are skipped by default for hotfixes: * [Add latest build to the production track release](/automations/types-of-automations#add-the-latest-available-apk-aab-to-the-draft-release-on-the-production-track-in-the-play-console) (Google platforms only) * [Kick off release](/automations/types-of-automations#kick-off-release) * [Bump version](/automations/types-of-automations#bump-version-in-code) * [Trigger workflow post-kickoff](/automations/types-of-automations#trigger-workflow-after-release-kickoff) * [Prepare rollback releases](/automations/types-of-automations#prepare-rollback-releases) * [Submit for review](/automations/types-of-automations#submit-app-for-review) * [Release app](/automations/types-of-automations#release-app) # Rollbacks This feature is limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) 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. #### Explaining rollbacks through an example The example below assumes the following: * `9.0.0` is the latest stable version on the app store that you're submitting to * `10.0.0` is the version that you are preparing to ship Runway will perform the following steps to prepare a rollback release: * Runway will generate `10.0.1` , which is a copy of `9.0.0` * Since app stores only allow one app "in review" at a time, Runway will wait until `10.0.0` is approved, and then will submit `10.0.1` for review * If `10.0.0` is submitted for review, approved, distributed to production, and there's a bug that requires a rollback, `10.0.1` will already be reviewed and ready to publish to production ### 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 seven 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)** #### **Re-signing strategies** When creating a rollback, you'll be prompted to choose a **re-signing strategy** from one of the following: * **Re-sign by Runway**: Runway will edit your source version's binary to bump the version and then re-sign it using the signing key you've provided * **Rebuild by your CI**: Runway will create a new branch for your rollback from the same commit as the source version's binary, edit your version files to bump the version, and then trigger your CI workflow to build the rollback binary. **Re-sign by Runway** ensures that your rollback version is the same binary as the source version, just with a modified version and then re-signed. However, code signing is an intricate process and it may take some troubleshooting to ensure your binary is able to be re-signed by Runway. Alternatively, the **rebuild by your CI** option lets you leverage the existing code signing that you've already set up on your CI/CD. We'll create your rollback from the same commit that was used to build the source version. #### 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. Depending on your **re-signing strategy:** 1. **Re-sign by Runway**: Updates the build number & version string (version code and version name on Android) on the source version binary. 2. **Rebuild by your CI**: Creates a branch for the rollback and edits your version files on that branch to bump the version 2. Once updated: 1. **Re-sign by Runway**: re-signs the binary using your app's signing key. 2. **Rebuild by your CI**: triggers your release candidate CI pipeline on the rollback branch to build a new binary. 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](/automations/types-of-automations#apply-beta-testing-notes-to-new-beta-builds) 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](/automations/types-of-automations#upload-dsyms-to-your-stability-monitoring-provider-ios) 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 on the production track will be fetched from the Play Console and incremented by one {% hint style="warning" %} 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.* {% endhint %} {% hint style="info" %} 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. {% endhint %} {% hint style="info" %} 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. {% endhint %} 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)](#create-release-specific-channel-s) * [Kick off release on target date](/automations/types-of-automations#kick-off-release-on-target-date) * [Trigger workflow after release kickoff](#trigger-workflow-after-release-kickoff) * [Release app on target date](/automations/types-of-automations#release-app-on-target-date) * [Release stable phased releases to 100% of users](/automations/types-of-automations#release-stable-phased-releases-staged-rollouts-to-100-of-users) * [Halt unstable phased releases](/automations/types-of-automations#halt-unstable-phased-releases) * [Backmerge changes on release branches at the end of the release cycle](#backmerge-changes-on-release-branches-at-the-end-of-the-release-cycle) * [Delete version-specific release branches at the end of the release cycle](#backmerge-changes-on-release-branches-at-the-end-of-the-release-cycle-1) * [Cherry pick work from the working branch to the release branch](#cherry-pick-work-from-the-working-branch-to-the-release-branch) * [Customized iOS phased rollouts](#customized-ios-phased-rollouts) * [Customized Android staged rollouts](#customized-android-staged-rollouts) * [Promote new builds to testing track (Android)](/automations/types-of-automations#promote-new-builds-to-testing-track) * [Assign beta testing builds to default testing groups (iOS)](/automations/types-of-automations#assign-beta-testing-builds-to-default-testing-groups) * [Apply beta testing notes to new beta builds](#apply-beta-testing-notes-to-new-beta-builds) * [Add missing labels or fix versions to tickets](/automations/types-of-automations#add-missing-labels-or-fix-versions-to-tickets) * [Mark releases complete in project management tool](#mark-releases-complete-in-project-management-tool) * [Prepare next version in Runway when current release is kicked off](/automations/types-of-automations#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](#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](#create-and-sync-app-store-connect-play-console-versions-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](#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](#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](#apply-whats-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](#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](#automatically-prepare-rollbacks-for-each-release) for more details.
# 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](/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](/using-runway/app-settings/signing-keys). {% endhint %} ### App store integration You must have an [App store integration capability](/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](/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](/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](/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**](/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.

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. {% 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.

Convert to roll-forward hotfix options


# Checklists You can add **checklist items** to any step in Runway to cover any unique parts of your team's release process. Checklist items can be created to apply to a single release, or across all releases, or even at the organization level to apply to multiple apps' releases. A step won't be marked as complete (green) in Runway until all checklist items have been completed -- in addition to the normal criteria that would mark a step as completed. When a checklist item is marked as **completed**, Runway will keep track of when the status changed, and who updated it. {% hint style="info" %} For example, you might need to send an email to the VP of Product every time a new release gets kicked off. Creating a checklist item called "**Email Helen**" on the Kickoff step will document this as a part of your release process, and gives your team a way to indicate that the task has been completed for each release. {% endhint %}
### Managing checklist items Checklist items can be managed in three places in Runway: * **At the step level** by navigating to a specific release > selecting a step > selecting the Checklist tab * When creating a checklist item at the step level, you have the additional option to include a checklist item for the current release only. * **At the app level** by navigating to Settings > Checklists * **At the org level** by navigating to Organization settings > Checklist Items * Checklist items created at the org level will populate down to any apps in the org [that you specify](#org-level-only-choosing-apps-that-this-checklist-item-will-apply-to), and any changes made at the org level will be reflected across all apps selected.
### 'Ping pending' actions When items belonging to a checklist are still pending, you can use the "**Ping**" action behind the `...` icon for an individual item to send a Slack or Teams message to the checklist item owner, or the “**Ping all pending**” button in the upper-right corner above the checklist to send messages to all owners of pending items. ### Checklist item components

Create checklist item dialog

#### Release step Specify which step of the release process this checklist item applies to. {% hint style="info" %} Checklist tasks can be particularly helpful for **gating automations**. For instance, you could set a checklist item as part of the Beta Testing step, which Runway requires to be complete (green) **before** automatically submitting an update for review to the app store. {% endhint %} #### Release types Specify which types of releases (major, minor, point, hotfix) require this checklist item. #### (Org level only) Choosing apps that this checklist item will apply to When managing checklist items from Organization settings, you can choose which apps the item applies to. Apps can be selected individually by name or grouped by platform type.
#### Title A name for this task. This appears on the checklist itself, as well as notifications related to updates on this item. #### (From step level only) Include checklist item for current release only When creating a checklist item from the Checklist tab on a particular release, you'll see an additional option to have the checklist item apply only to that release. #### Set a target completion time When creating or editing a checklist item, you can set a target completion date that is relative to the release's kickoff, submission, or release.

Add a target completion time

View the status of items with target completion times

#### Send a reminder if incomplete Keep this option selected if you want your team to be notified if the target completion date passes and the item is still marked as incomplete. Runway will post in Slack or Teams when the target completion date passes, as well as the owner of the incomplete task. #### Send a completion notification Keep this option selected if you want your team to be notified about updates to this item during a release cycle. Runway will post in Slack or Teams when a task is completed, or was formerly completed but reverted, as well as who performed the change and when. #### Additional information *Optional* - You can add information here that can easily be surfaced in Runway for team members working on this task. These notes serve as documentation available on every release cycle. Markdown is supported, and there's a built-in viewer. {% hint style="info" %} For example, if a specific command needs to be run at a certain point in your release cycle, you could paste a code snippet here for engineers who need to complete this task. Or if a PM needs to share an update with leadership, you could add a handy email template for sending a message to stakeholders. {% endhint %} #### Owners Checklist items can optionally specify user groups or individuals as owners. Designate an owner if a checklist item is intended to be completed by a specific team member (or by a team member from a specific group). Owners — individuals, or any members of the specified group(s) — will be able to update the item's status. {% hint style="info" %} In addition to any specified owners / owner groups, anyone with a default or custom role that has the 'Complete/uncomplete checklist items' permission will be able to update the status on any checklist item. {% endhint %} # Build matching Wherever Runway surfaces build information in the platform and in notifications, we try to show both CI build info and app store build info for full context. We also use the relationship between CI builds and store builds to power certain automations. For example, Runway’s automation to tag each release traces from the store build that was released to the CI build that generated it, and uses the commit info on the CI build to know exactly which commit should be tagged. Because there’s no actual link between CI builds and store builds, Runway needs to perform matching between builds. There are a number of factors used for this matching, each of which is given different priority. These include: * Build numbers (identical or overlapping, e.g. CI build #123 and store build #12345) * CI artifacts (if you have enabled artifact handling by Runway, we are able to access store build info on CI artifacts) * Relative timing (CI build start/stop times versus store build upload timestamp) * CI build status Certain factors guarantee 100% match success, such as identical or overlapping build numbers, but if your team doesn’t adhere to such conventions, Runway can still match builds successfully in most cases. {% hint style="warning" %} If your team runs many overlapping RCs or release builds and higher priority matching factors aren’t available, Runway can occasionally mismatch builds. This can cause confusion, so we recommend adjusting your build numbering and/or enabling build [artifact handling](/automations/types-of-automations) in Runway if possible, in line with the bullets above. Otherwise, you can contact us to have build matching disabled via a backend configuration. {% endhint %} {% hint style="info" %} If your team has [artifact handling](/automations/types-of-automations#enable-artifact-downloads) enabled in Runway, Runway will *require* matching build info on CI artifacts, without falling back on any of the other matching factors. Therefore, if there is an issue with your CI integration and artifacts aren't populated on a given CI build in Runway, there will be no build match for that build. {% endhint %} # App settings From the **App settings** page, you can configure various options that will apply to all releases for the selected app. ### Navigate to App Settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar ### Settings categories {% hint style="warning" %} Some features may be limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) to learn more. {% endhint %} * [General](#general) * [Team](/using-runway/app-settings/team-settings) * [Health metrics](/using-runway/app-settings/health-metrics-settings) * [Integrations](/using-runway/app-settings/integrations-settings) * [Automations](/using-runway/app-settings/automations-settings) * [Notifications](/using-runway/app-settings/notifications-settings) * [Schedule](/using-runway/app-settings/release-schedule) * [Beta testing](/using-runway/app-settings/beta-testing-settings) * [Metadata](/using-runway/app-settings/metadata-settings) * [Release defaults](/using-runway/app-settings/release-defaults) * [Checklists](/using-runway/app-settings/checklists-settings) * [Custom strings](/using-runway/app-settings/custom-strings-settings) ## General ### Version files From here, you can [configure an override list](/using-runway/app-settings/general-settings) of files that contain references to your app's version number. Runway will bump the version in these files during manual or [automated version bumps](/automations/types-of-automations#bump-version-on-working-branch). ### Release steps From here, you're able to choose which steps will need to be completed (green) in order for Runway to perform [automated app submission](/automations/types-of-automations#submit-app-for-review-on-target-date) and [releases](/automations/types-of-automations#release-app-on-target-date). ![](/files/E9Eg9mDS7zmnX1jynM9l) {% hint style="warning" %} Even if a step is marked as blocking here, users with sufficient permissions can still manually submit and release. These settings will only affect whether Runway considers the steps as gates for [submit and release automations.](/automations/types-of-automations#release-cycle) {% endhint %} # General settings Manage your app's general settings ## Version files The file path(s) corresponding to your app's version files. Runway will bump the version in these files during manual or [automated version bumps](/automations/types-of-automations#bump-version-number-in-code), and parses these files to determine your app's `Version in code` for the working branch and the release branch. {% hint style="info" %} Version files are populated by default using platform-specific files where versions are commonly found, but you can always customize your app's version files to any files found in your repository. {% endhint %} The default file types that Runway will detect versions in are as follows: **iOS:** * `.pbxproj` * `.xcconfig` * `.plist` * `.json` * `.yaml` **Android**: * `.gradle` * `.json` * `.yaml` **React Native / OTA:** * `package.json` The table below describes the format (in regex) Runway is expecting to find the version in depending on the file type.
File typeRegular expressionDescriptionExample
.pbxprojMARKETING_VERSION = (\d+\.\d+\.\d+)Matches the string MARKETING_VERSION = (case sensitive) followed by one or more digits separated by a . characterMARKETING_VERSION = 12.2.2
.xcconfigMARKETING_VERSION = (\d+\.\d+\.\d+) Matches the string MARKETING_VERSION = (case sensitive) followed by one or more digits separated by a . characterMARKETING_VERSION = 12.2.2
.plistCFBundleShortVersionString<\/key>\s*<string>(\d+\.\d+\.\d+)<\/string>Matches the CFBundleShortVersionString</key> string (case sensitive) followed by zero or more white space characters (spaces, tabs, line breaks), followed by the <string> string, followed by one or more digits separated by a . character, followed by the </string> stringCFBundleShortVersionString</key><string>2.2.2</string>
.yamlversion:\s+?(\d+\.\d+\.\d+)Matches the version: string, followed by one or more white space characters (spaces, tabs, line breaks), followed by one or more digits separated by a . characterversion: 12.2.2
.gradleversionName.*?(\d+\.\d+\.\d+)|versionString.*?(\d+\.\d+\.\d+)Matches the versionName string, followed by zero or more of any character (except line breaks), followed by one or more digits separated by a . character OR the string versionString, followed by zero or more of any character (except line breaks), followed by one or more digits separated by a . characterversionName 12.2.2
.json

\"version\":\s+?\"(\d+\.\d+\.\d+)\"

Matches the "version": string (case sensitive), followed by one or more white space characters (spaces, tabs, line breaks), followed by the one or more digits separated by a . character wrapped in quotation marks"version": "12.2.2"
Default (all other file types)(\d+\.\d+\.\d+)Matches one or more digits separated by a . character 12.2.2
## Localization directories Specify the directory/paths that contain your app's localization files. Localization directories are relevant for teams using the [Translations release step](/using-runway/release-steps/translations) to track the status of their localizable strings. ## Fixes settings Configure settings for work item **Fixes** found on the Feature Readiness step.
* **Create fixes for open PRs against the release branch:** Runway will automatically create a Fix for any PRs that are opened against the release branch. * **Fix approvals:** If enabled, work items designated as fixes will surface an approval status. Team members with sufficient privileges can approve or reject fix requests. Approvals can be performed on the Feature readiness release step. {% hint style="info" %} Runway will only auto-merge cherry-pick PRs against open against the release branch if the fix has been approved in Runway. The following conditions must be true for this behavior to apply: * The "Pull fixes into the release" [automation](/automations/types-of-automations#pull-cherry-pick-fixes-into-the-release) and **Fix approvals** is enabled * The "Merge pull requests created by Runway" [automation](/automations/types-of-automations#merge-pull-requests-opened-by-runway) is enabled * "Fix approvals" are enabled {% endhint %} * **Add pull request GitHub status check for fix request approvals**: Runway will include a status check on any pull requests created for fixes going into the release branch. The status check will only pass when the fix request associated with the PR has been approved.
* **Thread related fix notifications**: Notifications relevant to a given Fix will be threaded in Slack. # Team settings Add and remove app users, and configure role mappings for your app. ## App users Add and remove users from your organization to the app. {% hint style="info" %} Only users who have been added to the app will be eligible to be added to the release pilot rotation. To automatically add all new users in your organization to all apps, enable the **Add new users to all apps** setting from the [organization settings](/using-runway/organization-settings) page. {% endhint %} {% hint style="info" %} Only users who have been added to the app will be able to perform write actions against that app. All other users in your organization will have read-only access to the app. {% endhint %} # Release pilot rotation Configure the release pilot rotation for your app. ### About release pilots Generally speaking, **Release pilots** are the team members given the ultimate responsibility of overseeing each release and resolving blocking issues that may arise. By default, release pilots have broad permissions to perform actions within releases in Runway, will be specifically pinged by certain notifications, and will be responsible for completing checklist items assigned to the Release pilot role. ### Managing your release pilot rotation The release pilot rotation is a list of app users that Runway loops through to automatically assign release pilots to upcoming releases in Runway. In the **Release pilot rotation** page in App settings, you can add and remove users from the release pilot rotation, as well as update the order of the list. For a user to be eligible to be added to the release pilot rotation , they must be in the list of app users for the app (**App settings > Team**) and they must have the **Release pilot** user role.

Release pilot rotation view

Upcoming releases and their predicted release pilots are shown on the release pilot rotation view. By default, two cycles of the rotation are shown in the list. {% hint style="info" %} A release pilot can always be changed manually for a particular release, by clicking **Edit release settings** on the Kickoff step for a release. This will display as an **override** in the release pilot rotation view. {% endhint %} {% hint style="info" %} To disable automatic assignment of release pilots from the rotation, simply remove all users from the release pilot rotation. Note that you'll need to manually choose a pilot for each release. {% endhint %} {% hint style="info" %} Release pilots have their full permissions at all times, whether or not they're currently assigned in the rotation. {% endhint %} {% hint style="info" %} Runway does not assign the next release pilot in the rotation for hotfix releases. Instead, the hotfix release inherits the release pilot from the "parent" release. {% endhint %} ### Using a Scheduling integration to manage the release pilot rotation The [Scheduling integration capability](/integrations/incident-management-and-scheduling) allows your app's release pilot rotation to be synced from scheduling integrations like PagerDuty and OpsGenie. When a Scheduling integration is connected, Runway will automatically assign release pilots to releases based on your configured schedule in the integration provider. Release pilots are first matched to shifts on the scheduling integration when the *target kickoff date* is set – the user whose scheduled on-call shift aligns with the release's target kickoff date will be assigned as the release pilot for the release. {% hint style="info" %} If an override for a shift is created in the scheduling integration, the pilot in Runway will be re-assigned to match the override in the integration. {% endhint %} Runway will additionally continue to update a release's pilot throughout the lifetime of its release – this facilitates mid-cycle hand-offs when one person's shift ends and another begins. Runway will continuously update the release pilot to match the on-call user in your scheduling integration for the currently active ("next") release and for the live release until its rollout has completed. {% hint style="warning" %} If a Scheduling integration is connected, release pilot selection in Runway will be *disabled*. You must manage release pilots and overrides from your Scheduling integration directly. {% endhint %} # Integrations settings Use the **Integrations** settings page to connect Runway to third-party tools that your team already uses as a part of your release workflow. ## Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar {% hint style="warning" %} We recommend connecting your key integrations as a first step before filling in additional settings for your app. {% endhint %} ## Release tag pattern Runway uses this to read tags from your [version control](/integrations/version-control) provider and delineate your releases, and also to generate tags when auto-tagging releases upon completion. {% hint style="info" %} The **Pattern** field accepts tokens like `{version}` and `{versionConcise}` as a stand-in for the release version. Read more about [allowed tokenized patterns for tags here](/getting-started/pattern-strings-tokens). {% endhint %} {% hint style="info" %} Do you tag all of your builds? That's great — you can keep doing that, but Runway will also need a unique, final tag to mark each release. Establishing a 'final' release tag naming convention will allow Runway to surface the correct diffs release to release, and will seamlessly work with the [Release tag automation](/automations/types-of-automations#tag-releases-at-the-end-of-the-release-cycle). {% endhint %} ## Release branch patterns This is where you'll specify the naming convention for release branches. Runway can detect branches that are created with this pattern, or will use this pattern when performing automations to create branches. You can assign different patterns to different types of releases using the **Release type** dropdown. {% hint style="info" %} For [branching strategies](https://www.runway.team/blog/choosing-the-right-branching-strategy-for-mobile-development) such as GitFlow or similar, **Release branch pattern** accepts the string `{version}` as a stand-in for the release version, e.g. `release-ios-{version}` {% endhint %} {% hint style="warning" %} Are you a trunk-based team that doesn't use release branches? Omit the tokenized pattern, e.g. `main` Be sure to select **all types** in the **Release type** dropdown. {% endhint %} {% hint style="info" %} Read more about [allowed tokenized patterns for branch names here](/getting-started/pattern-strings-tokens). {% endhint %} ## Additional branches Specify here other branches that are an essential part of your release workflow. {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} {% hint style="info" %} ### Working branch {% endhint %} Your main development working branch, e.g. `development`. ### Staging branch Set this if you create Release Candidate builds from a branch other than your release branch. ### Deploy branch Set this if you create your final, production builds from a branch other than your release branch. {% hint style="warning" %} Set this only if your deploy branch is different from your release branch. {% endhint %} ## Feature affiliations Set up the fields (such as labels or fix versions) that will be used to categorize items for a given release in your project management tool. * **Integration name** - Choose the name of the associated tool * **Affiliation type** - Label, Fix version, etc (options will vary depending on the selected integration) * **Affiliation pattern** - Use a tokenized string here to associate tickets with a specific version, *e.g.* `release-{version}` {% hint style="info" %} Read more about [allowed tokenized patterns for feature affiliations here](/getting-started/pattern-strings-tokens). {% endhint %} ## # Profiles and devices Manage devices and provisioning profiles for your app. {% hint style="info" %} Profile and device management is available for iOS platforms only. {% endhint %} Runway's profile and device management features make it easy for your team to securely automate the process of registering new devices in the Apple Developer portal, managing which devices are enabled and disabled, and updating relevant provisioning profiles as devices are added and removed. ## Devices The **Devices** tab of the **Profiles and devices** section of app settings shows a combined list of all devices that have been registered with app users in Runway and devices registered in the Apple Developer Portal since your last device reset date. Test devices that have been added to your app in Runway will also be shown in this list. The following properties of devices can be seen in the device list table, and by clicking into an individual device to open the device details drawer: * Device name * Device type * Device identifier (UDID) * Status Bulk actions on devices can be performed from the devices list, including selecting devices to register in the Apple Developer Portal, enabling and disabling devices, and removing devices from the devices list. {% hint style="info" %} Runway can manage automatically syncing devices in the Apple Developer Portal with users in Runway. [Learn more](/automations/types-of-automations#sync-devices-in-the-apple-developer-portal). {% endhint %} ### Adding your device to Runway Runway users can also add their devices to to their users in Runway so they can be managed automatically in the Apple Developer Portal. To add a device to your user in Runway, scan the QR code shown when hovering over the registration prompt in the **Devices** tab of the **Profiles and devices section**. Once you've added your device to your user in Runway, it will appear in the list of **Devices** for any apps your user is a member of. {% hint style="info" %} You can also add a device to your Runway user from your user's settings page. {% endhint %} ## Profiles The **Profiles** tab of the **Profiles and devices** section in app settings lists all active (non-expired) provisioning profiles associated with your app in the Apple Developer Portal. The following properties of each profile can be seen in the profile list table, and by clicking into an individual provisioning profile's details drawer: * Profile name * Profile type (Ad Hoc, Development, Distribution, In House) * Created on date * Expiry date * Devices: the devices associated with the provisioning profile. Note that this is only relevant for Ad Hoc and Development profiles * Certificate name and type: the certificate that's included in the provisioning profile {% hint style="info" %} Runway can manage automatically updating relevant provisioning profiles with an updated devices list as devices are registered, enabled and disabled. [Learn more](/automations/types-of-automations#sync-provisioning-profile-devices). {% endhint %} ### Configure provisioning profiles in Runway using fastlane To help explain, below is an example: ``` desc "Installs signing certificate in the keychain and downloads provisioning profiles from App Store Connect" lane :prepare_signing do |options| team_id = CredentialsManager::AppfileConfig.try_fetch_value(:team_id) api_key = lane_context[SharedValues::APP_STORE_CONNECT_API_KEY] keychain_name = "signing" keychain_password = "temp" delete_keychain( name: keychain_name ) if File.exist? File.expand_path("~/Library/Keychains/#{keychain_name}-db") create_keychain( name: keychain_name, password: keychain_password, default_keychain: true, unlock: true, timeout: 3600 ) import_certificate( certificate_path: ENV["SIGNING_KEY_FILE_PATH"], certificate_password: ENV["SIGNING_KEY_PASSWORD"], keychain_name: keychain_name, keychain_password: keychain_password ) # fetches and installs provisioning profiles from ASC sigh( adhoc: options[:adhoc], api_key: api_key, readonly: true ) end ``` As you can see, you can leverage fastlane's `sigh` action to grab the latest provisioning profiles from App Store Connect at build time. The most typical approach is to keep signing keys local (in source control with `match` or otherwise) since you can't just fetch them via API, but fetch provisioning profiles via API from App Store Connect, avoiding the overhead of managing those in source control. Read more in our blog post [here](https://www.runway.team/blog/how-to-set-up-a-ci-cd-pipeline-for-your-ios-app-fastlane-github-actions). # Signing keys Signing keys are used for two reasons: * re-signing binaries for rollback releases – during this process, the signing key of the original binary is checked and must match the signing key being used for re-signing. This means that signing keys can never be used to sign a binary that wasn’t previously signed with the same signing key. * generating universal APKs from AABs - since Android AAB builds cannot be directly installed on Android devices by default, Runway will use your app's signing key to automatically generate installable universal APKs. If your app has previously been shipped through the Google Play Console or App Store Connect, there’s a good chance the signing key for your app already exists. However, if you need to create a new one, please follow the instructions below.
How to generate a signing certificate and private key pair for App Store Connect **Step 1: Create a Signing Certificate (via a Certificate Signing Request - CSR)** 1. On your Mac, open the **Keychain Access** app. 2. From the top menu: `Keychain Access > Certificate Assistant > Request a Certificate from a Certificate Authority`. 3. Enter your **email address** and **Common Name** (like your name or your company name). 4. Select “Saved to disk” and click **Continue**. 5. This will create a **.certSigningRequest** file on your computer. **Step 2: Upload CSR and Download Certificate** 1. Go to [Apple Developer Certificates](https://developer.apple.com/account/resources/certificates/list) 2. Click **+** to create a new certificate (usually “Apple Distribution”). 3. Upload the **.certSigningRequest** file you created. **Step 3: Export the `.p12` File** 1. Double-click the downloaded `.cer` file to add it to **Keychain Access**. 2. In Keychain Access, locate the certificate (usually under “My Certificates”). 3. Right-click the certificate > **Export**. 4. Choose the `.p12` format and set a password. 5. Save the file — this is your **iOS signing certificate**.
How to generate a Keystore File for Google Play Console Use **Android Studio** or the command line: ```bash bashCopyEditkeytool -genkey -v -keystore your_app.keystore -alias your_alias_name -keyalg RSA -keysize 2048 -validity 10000 ``` * You’ll be asked to set a password and fill in info like name and company. * This will generate a `.keystore` file. **Tip:** Keep your keystore file safe! You’ll need it for future updates.
We take security seriously and have a robust system in place for keeping your signing keys safe. Signing keys are encrypted both in transit and while at rest and, once uploaded, they are inaccessible from the open internet – our signing server sits in a virtual private cloud (VPC).
# Health metrics settings Health metrics in Runway are configurable metrics you can use to monitor the health of a release as it rolls out. Runway supports a number of different [metric types](#metric-types) that are computed using data from your [Stability Monitoring](/integrations/stability-monitoring), [Observability & Analytics](/integrations/observability-and-analytics) and [App store](/integrations/app-stores) integrations. Runway uses your team’s custom ‘health’ definition on the [Rollout](/using-runway/rollout) page to give you a glanceable, immediately understandable view of how your app is faring post-release. Once health definitions have been created, they can be leveraged as rules for triggering automations that help manage your rollout, like [halting unhealthy phased rollouts](/automations/types-of-automations#halt-unstable-phased-releases) and [accelerating healthy phased rollouts](/automations/types-of-automations#release-stable-phased-releases-staged-rollouts-to-100-of-users). Runway will also send Slack notifications any time your defined health metrics fall outside of their thresholds during a release rollout. {% hint style="info" %} Custom thresholds related to observability & analytics integrations can only be configured for the key events that you have selected in those [integrations' settings](/integrations/observability-and-analytics). {% endhint %} ## Metric Types ### Stability monitoring metric types Runway polls the connected stability monitoring integration to retrieve updated values for metrics every 10 minutes (approximately) during the course of a release’s rollout. Values are segmented by release version, platform, environment, and build number. Supported metrics: * Crash-free sessions * Crash-free sessions delta from previous version value * Crash-free sessions delta from previous version as a percentage * Crash-free users * Crash-free users delta from previous version value * Crash-free users delta from previous version as a percentage #### **Crash-free sessions** The percentage of sessions for the release that have not experienced a crash. Calculated as follows: *(Number of sessions on a given version - number of sessions on a given version that have experienced a crash) / Number of sessions on a given version* #### **Crash-free users** The percentage of users for the release that have not experienced a crash. Crash rate per user is calculated as follows: *(Number of users on a given version - number of users on a given version that have experienced a crash) / Number of users on a given version* #### Crash-free sessions & users delta from previous version value The delta between the current release's user stability or session stability value and the previous version's value. #### Crash-free sessions & users delta from previous version as a percentage The delta between the current release's user stability or session stability and the previous version's as a percent change. ### Observability & Analytics metric types Runway polls the connected observability & analytics integration to retrieve updated values for metrics every 10 minutes (approximately) during the course of a release’s rollout. Values are segmented by release version and platform. Supported metrics: * Events per DAU * Events per DAU delta from previous version value * Events per DAU delta from previous version as a percentage * Events per session * Events per session delta from previous version value * Events per session delta from previous version as a percentage * Average of property value * Average of property value delta from previous version value * Average of property value delta from previous version as a percentge * Median of property value *(supported by Datadog and Amplitude only)* * Median of property value delta from previous version value * Median of property value delta from previous version as a percentage * Percentiles of property value (p90, p95, p99) *(supported by Datadog and Amplitude only)* * Percentiles of property value (p90, p95, p99) delta from previous version value * Percentiles of property value (p90, p95, p99) delta from previous version as a percentage #### **Events per DAU** The number of times an event is triggered per daily active user. Calculated by taking the total number of times an event has been triggered, and dividing that number by the total number of daily active users. #### **Events per session** The number of times an event is triggered per session. Calculated by taking the total number of times an event has been triggered, and dividing that by the total number of sessions. **Events per DAU and events per session delta from previous version value** The delta between the current release's count of events per DAU / per session and the previous version's value. #### **Events per DAU and events per session delta from previous version value as a percentage** The delta between the current release's count of events per DAU / per session and the previous version's value as a percentage. #### **Average of property value** For a given event, the average value of a specified property across all triggered events in the release version. For example: *Event name: "Add to cart"* *Event property: "amount"* *For all triggered "Add to cart" events in the release version, the average value of the "amount" property.* #### **Median of property value** For a given event, the median value of a specific property across all triggered events in the release version. *Event name: "Add to cart"* *Event property: "amount"* *For all triggered "Add to cart" events in the release version, the median value of the "amount" property.* #### **Percentiles of property value (p90, p95, p99)** For a given event, the 90th, 95th, or 99th percentile values of a specific property across all triggered events in the release version. *Event name: "Add to cart"* *Event property: "amount"* *For all triggered "Add to cart" events in the release version, the 90th, 95th, and 99th percentiles of the "amount" property.* #### **Average, median, and percentile of property value delta from previous version** The delta between the current release's average, median, or percentile (p90, p95, p99) of property value and the previous version's values. For example: Event name: *"Add to cart"* Event property: *"amount"* Average value: *95.00* Delta from previous version (value): +*5.00* #### **Average, median, and percentile of property value delta from previous version as percentage** The delta between the current release's average, median, or percentile (p90, p95, p99) of property value and the previous version's as a percentage. For example: Event name: *"Add to cart"* Event property: *"amount"* Average value: *95.00* Delta from previous version (percentage): +*5.5%* ### Ratings metric types Runway interacts with the relevant app store API to fetch the latest user rating average for a given release and app. Supported metrics: * User rating for version average * User rating for version average delta from previous version * User rating for version average delta from previous version as a percentage #### **User rating average** The user rating for the given release version. This value comes directly from the Play Store or App Store integration, and is segmented by release version. #### User rating average delta from previous version The delta between the current release's average user rating and the previous version's value. For example: Average user rating (current version): *3.5* Delta from previous version (value): *-0.5* #### User rating average delta from previous version as a percentage The delta between the current release's avg user rating and the previous version's value as a percentage. For example: Average user rating (current version): *3.5* Delta from previous version (percentage): -10% ### Calculated metrics There is a special metric type that allows you to apply an equation to one or more more existing metrics, with the resulting value becoming a calculated metric that you can use just like any other metric. This can be used for capturing funnels or certain conversion rates, for example. To add calculated metrics, choose the "Calculated from existing metrics" option in the Add Health Metric modal. You will select one or more existing metrics, and each will be assigned a token (M1, M2, etc.). Use those tokens to build the desired equation using standard mathematical operators, e.g. `100*M1/M2`. Currently supported for Observability & Analytics metrics only. # Automations settings Manage automations that allow Runway to perform actions for you
### Navigate to automations settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Automations** in the sidebar ### Settings for individual automations * **Enabled:** Toggle this type of automations on or off * Some automations may have additional settings Learn more about automations here: {% content-ref url="/pages/-MjGTIQn4J3\_WiLnE5kB" %} [Automations overview](/automations/overview) {% endcontent-ref %} # Notifications settings Manage how Runway notifies your team about key events
### Navigate to notifications settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Notifications** in the sidebar ### Settings for individual notifications All notifications can each be configured with a number of default settings. * **Enabled:** Toggle this type of notification on or off * **Mentions:** Mention individual users or user groups in the notification * **Channel(s):** Select or enter one or more channel names for this type of notification. * Leave this field blank to send notifications to your configured [primary channel](#primary-channel) (default). Some notification types may have additional settings that pertain to the specific functionality of the notification. For example, reminder notifications allow you to configure reminder frequency. {% hint style="info" %} You can also opt into receiving email notifications for each app-level notification type. For more details visit the [email notification settings documentation](/using-runway/user-settings#email-notification-settings). {% endhint %} Learn more about notifications here: {% content-ref url="/pages/-Mj\_d1UQ6tCzZLk6O53e" %} [Notifications overview](/notifications/notifications-overview) {% endcontent-ref %} # Schedule settings Use the **release schedule** to set up a regular cadence (sometimes referred to as a [release train](https://www.runway.team/blog/mobile-releases-feature-based-or-release-train)) and completely [automate](/automations/overview) key events along the way like kickoff, submission, and release. Once your release schedule is configured, Runway will automatically apply target dates to your upcoming releases according to your specified release cadence. ### Navigate to the schedule settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Schedule** in the sidebar ### Configure your release schedule 1\. Specify how often you'll be releasing updates to this app * **Weekly (or more)** - Releasing one or more releases every week * **Bi-weekly** - Releasing every two weeks * **Monthly** - Releasing once a month * **Not enabled** - Release schedule is OFF: Runway will not create target dates {% hint style="warning" %} Some configurations of the kickoff, submit or release [release cycle automations](/automations/types-of-automations#release-cycle) will only trigger if target dates have been set. If your release schedule is disabled, you will need to set target dates manually on each release in order for these automations to run. {% endhint %} 2\. Choose the day of the week, time, and time zone for release kickoff, submission, and release dates Configure a weekday, time, and timezone for at least one of target kickoff, submission or release (Apple platforms only). For the **Weekly (or more)** option, you can also optionally add multiple sets of dates to configure a schedule that involves shipping multiple releases within a week. For example, the following configuration is valid for teams looking to ship two releases in a week: First release: * Kickoff Mondays at 9am * Submit Wednesdays at 2pm * Release Fridays at 9am Second release: * Kickoff Tuesdays at 9am * Submit Fridays at 12pm * Release Mondays at 9am If your team would like to kick off or submit one week, but then release during a different week, you can enter a number under `Skip weeks` to indicate the number of weeks in between the kickoff or submit event and the release event.
3\. Save your changes Target dates will be applied to any current and upcoming releases active in Runway, unless target dates have previously been set. If you've configured your schedule with the **Weekly (one or more)** option, Runway will apply target dates to the first N upcoming releases, where N is the number of release date sets you've configured for your cadence. For example, if you've configured your cadence to ship three releases within a week, then target dates will be automatically applied to the first three active releases in Runway. {% hint style="info" %} Runway will not recalculate target dates for releases that already have target dates set. {% endhint %} {% hint style="warning" %} Runway will not apply target dates to releases that are marked as **hotfixes.** {% endhint %} {% hint style="info" %} If a release was kicked off and you subsequently wish to change the release kickoff date, we recommend that you: 1\. Delete the branch in your VCS. 2\. Confirm that Runway picked up the change on the **Kickoff** step's UI. 3\. Edit the target dates. The already created release should remain untouched and Runway will resume the release process on the updated target dates. {% endhint %} ### Viewing your release schedule
The release schedule is accessible on the "Release schedule" page on any release, and at the app level. From here you can view key dates for a given release, including kickoff, submission and (if applicable) release. You can also update target dates and pause your schedule cadence. For more details visit the [Release schedule documentation](/using-runway/release-schedule). To view the release schedule for all releases for a given app in Runway, visit the "Release schedule" page accessible from the main App overview page navigation bar.

App release schedule

# Beta testing settings ### Navigate to Beta testing settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Beta testing** in the sidebar ### Configuring beta testing style Choose which type of beta testing style your team will use for all releases of this app: * **Non-blocking** - No soak period. The Beta testing step will automatically be shown as complete (green). * **Open-ended soak** - An open-ended beta testing soak period. The Beta testing step will be marked as complete once the soak period is manually ended. * **Time-limited soak** - Set a soak duration, in hours. The Beta testing step will be marked as complete once the soak duration has finished. (You can still manually end the soak period early.) # Metadata settings ### Navigate to Metadata settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Metadata** in the sidebar ### Default App Store / Play Store release notes Set default App Store release notes for every locale you need to support, and Runway can automatically apply those defaults to new versions. {% hint style="warning" %} Runway will only apply these defaults if the [associated automation](/automations/types-of-automations#apply-default-whats-new-text-to-new-releases-in-app-store-connect) is enabled. {% endhint %} # Release defaults Configure default app store settings and Runway will apply them where needed across releases. Your release defaults will automatically applied when a release record is created in Runway. {% hint style="warning" %} Runway will not apply release defaults to hotfix releases. You can configure release settings prior to submission. {% endhint %} ### Navigate to the App store defaults page 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **App store defaults** in the sidebar ### App Store release defaults (iOS) #### Export compliance information Answer the presented questions to determine your app's export compliance requirements. For more details on how to answer export compliance questions for your app, visit Apple's [export compliance documentation overview](https://developer.apple.com/help/app-store-connect/manage-app-information/overview-of-export-compliance). {% hint style="info" %} Runway can automatically apply your export compliance information to new builds uploaded to TestFlight. You must enable the automation in order to see defeault export compliance settings applied to new builds. [Learn more](/using-runway/app-settings/release-defaults#export-compliance-information). {% endhint %} #### **Release method** Runway will set your default release method and phased release setting on every new release. You can still manually change these options for a specific release prior to submission. * **Manually release updates** — Choose this release method if you plan to release manually via Runway or App Store Connect, or if you're using Runway's automated release feature. * **Automatically release updates** — App Store Connect will release your app update as soon as it's approved. * **Phased release** — App Store Connect will release your app update over a 7-day period, as follows: * Day 1 – 1 percent * Day 2 – 2 percent * Day 3 – 5 percent * Day 4 – 10 percent * Day 5 – 20 percent * Day 6 – 50 percent * Day 7 – 100 percent ### Play Store release defaults (Android) #### Release method Runway will use this release setting for each new release. You can manually change the release method for a specific release prior to submission. * **Don't stage** — Releases update to all users immediately. * **Staged rollout to a percentage of users** — Choose a percentage of users that will initially receive the update. #### Default release method and the custom staged rollout automation Runway custom staged rollout automation can roll out your update over the course of several days. In order for the automation to start your custom staged rollout sequence, the release method for the release must be set to "Staged rollout to a percentage of users". If the automation is enabled, your *initial staged rollout* setting will be ignored – the staged rollout percentage indicated on Day 1 of your custom staged rollout configuration will be used instead.
# Checklists settings ### Adding, updating, or removing checklist items #### Navigate to checklists settings 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Checklists** in the sidebar Learn more about adding, updating, and removing checklist items here: {% content-ref url="/pages/-Mjj12OTH2s5C-sghI3t" %} [Checklists](/using-runway/checklists) {% endcontent-ref %} {% hint style="info" %} Checklist items can also be added, updated or removed directly from a release step. (Doing so will still affect checklist items for all releases unless the "Include this checklist item for this release only" option is enabled.) {% endhint %} # Custom strings settings Customize strings used by Runway when creating artifacts throughout the release's lifecycle As part of its core functionality, Runway is capable of creating a number of artifacts on your behalf, like pull requests during automatic bump version or promote code actions, git tags during automatic tagging at the end of the release cycle, and more. These artifacts are populated with default strings, but you can customize the content of any of these strings to suit your team’s needs. {% hint style="info" %} For any given string, there are a number of tokens available. In the final artifact, these tokens will be replaced with relevant values for the release or app in question. {% endhint %} A complete list of strings that can be customized (including default strings and available tokens for each) can be found in the table below.
String typeDefault valueAvailable tokens
Bump version PR titleBump version to {version}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Bump version PR bodyRunway bumped your version to {version}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Bump version commit messageBumping version to {version}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Promote code PR title{workingBranchName} ->{releaseBranchName} for release {version}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Promote code PR bodyRunway promoted {workingBranchName} to {releaseBranchName} for release {version}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Backmerge PR titleBackmerge {releaseBranchName} to {workingBranchName}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {appStoreBuildNumber}
  • {ciBuildNumber}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Backmerge PR bodyRunway backmerged release branch {releaseBranchName} to working branch {workingBranchName}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {appStoreBuildNumber}
  • {ciBuildNumber}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
VCS Release titleRelease {version}
  • {version}
  • {versionConcise}
  • {releaseName}
  • {appStoreBuildNumber}
  • {ciBuildNumber}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
VCS release bodyThe default string for the VCS release body is dynamically generated from the list of commits and any associated tickets in the diff for the release.
  • {version}
  • {versionConcise}
  • {releaseName}
  • {appStoreBuildNumber}
  • {ciBuildNumber}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
  • {workItems}*
Git tag messageRelease {version} tagged by Runway
  • {version}
  • {versionConcise}
  • {releaseName}
  • {appStoreBuildNumber}
  • {ciBuildNumber}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
Release summaryThe release summary generated by Runway at the end of each release
  • {version}
  • {versionConcise}
  • {releaseName}
  • {appStoreBuildNumber}
  • {ciBuildNumber}
  • {releasePilot}
  • {releaseBranchName}
  • {workingBranchName}
  • {workItems}
  • {appName}
  • {appPlatform}
  • {workItemsCount
  • {issuesCount}
  • {commitsCount
  • {contributorsCount
  • {linesOfCodeCount
  • {releaseNotes
  • {releaseDuration}
  • {releasedAt
  • {releaseWorkItemsLink}
  • {releaseAppStoreLink
  • {releaseVCSReleaseLink}
Cherry-pick PR title

The title of the cherry-pick PR created by Runway.

The default string for the cherry-pick PR title is dynamically generated from the code items that were cherry-picked as part of this work.

  • {version}
  • {versionConcise}
  • {releaseName
  • {releasePilot
  • {releaseBranchName
  • {workingBranchName}
  • {prTitleOrCommitMessage}
Cherry-pick PR body

The contents of the cherry-pick PR body for the PR created by Runway.

The default string for the cherry-pick PR body is dynamically generated from the list of commits that were cherry-picked as part of this work.

  • {version}
  • {versionConcise}
  • {releaseName
  • {releasePilot
  • {releaseBranchName
  • {workingBranchName}
  • {prTitleOrCommitMessage}
  • {prBodyOrCommitHash}
Cherry-pick commit messageThe commit message for commits cherry-picked by Runway
  • {commitMessage}
**\*** The `{workItems}` token pulls in a markdown-formatted list of commits in the release diff, with any associated project management tickets also linked. You can filter these items using a modifier trailing the token. For example: * `{workItems}[[bug]]` – will only include items containing the string `[bug]` in their commit message * `{workItems}[bug,fix]` – will only include items containing the string `bug` or `fix` in their commit message * `{workItems}[!bug]` – will only include items that *do not* contain the string `bug` in their commit message Note that filtering is case *insensitive*. # Build Distro
Build Distro by Runway is the easiest way to manage, share, search, and install pre-production builds for iOS and Android. Runway’s build distribution allows you to: * Create and customize build buckets (groups of builds) that can be accessed by individuals or roles on your team * Configure branch and PR rules on buckets to automatically pull build artifacts from workflow runs for quick and easy distribution (no fiddling with CI/CD scripts required!) * Easily install builds from your desktop browser using a QR code or by sending yourself a link to install on Slack * Install builds directly on your mobile device via the Runway mobile site * [Search key fields within builds](/using-runway/build-distro/search-in-build-distro) # Quickstart ## Get started in 5 easy steps
Follow these steps to get started with Build Distro by Runway. 1. Navigate to the build distribution page in your Runway app. 2. Click **Get Started**. Note that only admin users in your org can opt your app into Build Distro. {% hint style="info" %} Runway will automatically generate some default buckets for your app to get you started. To learn more about the buckets that are created by default, go to the [Default Buckets](/using-runway/build-distro/build-distro-buckets#default-buckets) section. {% endhint %} 3. **\[Recommended]** Connect a supported CI/CD integration and configure your workflow settings. This step is optional – you can always manually upload builds to buckets. {% hint style="info" %} Your CI/CD workflows must be configured to output installable artifacts in order to work correctly with Build Distro in Runway. To learn more about how to configure your CI/CD workflows to output binary artifacts, see the [Making artifacts from your CI/CD workflow available for download](#making-artifacts-from-your-ci-cd-workflow-available-for-download) section. {% endhint %} {% hint style="warning" %} The following build system integrations are not supported with Build Distro: * App Center Build * TravisCI {% endhint %} 4. **\[iOS only]** Connect with App Store Connect to unlock additional build distribution features like [automatic device provisioning](/automations/types-of-automations#sync-provisioning-profile-devices). This step is optional. 5. That’s it! If you've connected and configured a CI/CD integration, builds will start to populate in your respective buckets, and you can start installing by clicking “Install” on any installable build on a bucket. ## Making artifacts from your CI/CD workflow available for download Runway's Build Distro can help your team get build distribution set up in just a few steps as long as your team is already generating binary artifacts from your CI/CD workflow and making them available for download. For some CI/CD integration providers, making build artifacts available for download is the default behavior, so nothing needs to be done in order to get Build Distro set up in Runway. 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 on how to make build artifacts available to be pulled into Runway Build Distro for your provider.
Supported ProviderArtifacts available by default?Additional Info
BitriseYeshttps://devcenter.bitrise.io/en/builds/managing-build-files/build-artifacts-online.html
GitHub ActionsNo

Add an "upload artifact" step to your build job in your GitHub Actions yml file.

https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts

GitLab CINo

Use the artifacts keyword in your GitLab CI yml file.

https://docs.gitlab.com/ee/ci/jobs/job_artifacts.html

CircleCINo

Add a store_artifacts step to your CircleCI job's yml file.

https://circleci.com/docs/artifacts/#uploading-artifacts

# Uploading builds for distribution There are few different ways you can upload builds to Runway for distribution using Build Distro. By far the simplest way to get started is to connect a supported CI/CD integration and configure bucket rules to pull artifacts from workflows and branches or PRs of your choosing. You can read more about how to set up bucket rules in the [Configuring bucket rules](/using-runway/build-distro/build-distro-buckets#configuring-bucket-rules) section. Alternative ways you can upload builds to Runway for distribution are: * **Manual upload:** any user with at least the **Uploader** permission to the bucket can manually upload a valid binary to a bucket that has no rules configured.
* **Build upload via the Runway Public API**: uploading builds programmatically can be achieved using Runway's Public Build Distro API. For more information, visit our [API reference docs](https://api-docs.runway.team/#tag/buildDistro/operation/uploadBucketBuild). # Build Distro buckets
Buckets are groups of builds that can be automatically shared with a group of bucket members that you define. Buckets are a great way to group together similar kinds of builds (think release candidate builds, development/alpha builds, or even feature team builds) so there’s no ambiguity about the kinds of builds that are available for testing in a given bucket. All apps will come with two default buckets: the **Release Candidate** bucket, and the **Development** bucket. Certain users will also have **Personal** buckets created by default. {% hint style="success" %} In addition to the default buckets, custom buckets can also be created. Try creating a bucket for your WIP feature or for your team. {% endhint %} ## Bucket settings
Buckets have properties that can be configured to refine the kinds of builds that are available in a bucket and who has access to them. The following properties can be configured on any build bucket: * **Name**: the display name of the bucket. * **Rules**: the rules that define how builds get pulled into the bucket. * **PR rule**: Build artifacts will be automatically pulled into the bucket from matching workflow runs on any pull requests that are open against the configured base branch. * **Branch rule:** Build artifacts will be automatically pulled into the bucket from matching workflow runs on the configured branch. * **Filename(s)**: the names of the files (including file extension) that Runway should automatically pull from your workflow's build artifacts. If left blank, all files with the `.ipa` extension will be pulled in for iOS and tvOS platforms, and all files with the `.apk` extension will be pulled in for Android platforms * **Org-wide access**: enable org-wide access to make your bucket available to all users in your Runway org. Anyone in your Runway org with access can view and install builds from the bucket. If this setting is disabled, only bucket members can view and install builds from the bucket. * **Public access links:** enable the public access link to make your bucket available to users external to Runway. Users with the link will be able to view, download, and install builds from your bucket without logging in or being members of Runway. ### Configuring bucket rules #### Configuring PR rules When a PR rule is configured, build artifacts will be automatically pulled into the bucket from matching workflow runs on any pull requests that are open against the configured base branch. To configure a PR bucket rule, you'll define the following: * **CI/CD workflow and base branch:** the CI/CD workflow and PR base branch where Runway should pull build artifacts from. You can optionally specify workflow arguments if needed. * **Branch fields** support tokenized branch patterns, including the wildcard token `{*}` and several more token types. * **(optional) User:** Filter CI/CD workflow runs by PR author – only builds triggered by PRs authored by one of the specified users will be pulled into the bucket. Note that connecting a Version Control integration is required for this configuration. * **(optional) Filename(s):** The file names of the artifact files that be surfaced for each build. By default, all `.ipa` files will be surfaced for Apple platforms, and all `.apk` files will be surfaced for Android platforms. Tokenized patterns and wildcards are supported here as well.
#### Configuring branch rules When a branch rule is configured, build artifacts will be automatically pulled into the bucket from matching workflow runs on the configured branch. To configure a branch rule, you'll define the following: * **CI/CD workflow and branch:** the CI/CD workflow and branch where Runway should pull build artifacts from. You can optionally specify workflow arguments if needed. * **Branch fields** support tokenized branch patterns, including the wildcard token `{*}` and several more token types. * **(optional) User:** Filter CI/CD workflow runs by commit author – only builds triggered by commits authored by one of the specified users will be pulled into the bucket. Note that connecting a Version Control integration is required for this configuration. * **(optional) Filename(s):** The file names of the artifact files that be surfaced for each build. By default, all `.ipa` files will be surfaced for Apple platforms, and all `.apk` files will be surfaced for Android platforms. Tokenized patterns and wildcards are supported here as well.
{% hint style="warning" %} When configuring bucket rules, selected CI/CD workflows must already be configured to generate the required build artifacts (`.ipa`, `.apk` , or `.aab`files). To read more about how to configure your CI/CD workflow to generate build artifacts and make them available for download, go [here](/using-runway/build-distro/quickstart#making-artifacts-from-your-ci-cd-workflow-available-for-download). {% endhint %} {% hint style="info" %} Artifact files from Github Actions are stored in zip files. Use the "**File name(s)**" field to enter an artifact file name with the relevant extension (`.ipa` , `.apk`, or `.aab` ); Runway will extract the file if it exists. {% endhint %} {% hint style="info" %} When org-wide access is enabled, any non-members with access to the bucket will be treated as users with the **Tester** [bucket permission](#bucket-permissions). {% endhint %} ## Uploading builds to buckets There are currently three ways to upload builds to a bucket: * **Configure a bucket rule** and Runway will automatically pull build artifacts from matching workflow runs into the bucket * **Upload builds manually** to the bucket using the build upload flow on the bucket details page. You can upload `.ipa` files to buckets on apps of iOS platforms, and `.apk` or `.aab` files to buckets on apps of Android platforms * **Upload builds programmatically** to a bucket using Runway's [public API](https://api-docs.runway.team/#tag/buildDistro/operation/uploadBucketBuild) ## Default buckets Runway will by default start your team off with three distinct buckets: Release Candidates, Development, and for certain user groups, a Personal Bucket. ### **Release Candidates bucket** The Release Candidates bucket can be used to group together release candidate builds – if your team is already set up on Runway's Release Management product, the Release Candidates bucket will be automatically configured with a branch rule that uses your app’s Release Candidate CI/CD workflow and release branch (as defined during the setup flow of your CI/CD integration). {% hint style="info" %} Release Candidate buckets will by default include all org admins as well as all default user groups as bucket members. Org admins will be included as bucket admins. Default user groups will be included as bucket testers. {% endhint %} {% hint style="warning" %} Release Candidate buckets will start out with **Org-wide access** enabled. You can disable this setting from the bucket's settings. {% endhint %} ### **Development bucket** The Development bucket can be used to group together development or alpha builds – if your team is already set up on Runway's Release Management product, the Development bucket is by default configured with a branch rule that uses your app’s Development CI/CD workflow and working branch (as defined during the set up flow of your CI/CD integration). {% hint style="info" %} Development buckets will by default include all org admins as well as default user groups as bucket members. Org admins will be included as bucket admins. Default groups will be included as bucket testers. {% endhint %} {% hint style="warning" %} Development buckets will start out with **Org-wide access** enabled. You can disable this setting from the bucket's settings. {% endhint %} ### **Personal bucket** Any user with an admin role in the org, or any user in the app with a PM, EM, or Engineer role will get a Personal bucket by default. These buckets are designed as freeform workspaces – a bucket where you can upload any kind of build to share with whomever you like. {% hint style="info" %} Personal buckets aren't configured with a bucket rule by default, and don’t include any members besides the owner of the bucket. {% endhint %} ## Automations Bucket automations are scoped to the bucket they are a part of. To see a list of available bucket automations, visit the [Build Distro bucket automations](/automations/types-of-automations#build-distro-bucket-automations) page. ## Notifications The notifications tab in the bucket details shows a list of available notifications for the given bucket. Notifications can be toggled on and off at the individual bucket level, and customized so that notifications for a given bucket can be sent to different channels of your choosing. {% hint style="info" %} Bucket notifications are enabled by default on the Release Candidate and Development default buckets. {% endhint %}
{% hint style="info" %} You can also opt into receiving email notifications for each bucket-level notification type. For more details visit the [email notification settings documentation](/using-runway/user-settings#email-notification-settings). {% endhint %} ## Bucket permissions See below for details on which bucket actions can be performed by which kind of bucket member. | Action | Admin | Uploader | Tester | | ------------------------------------ | ------------------------- | -------------------------------- | -------------------------------- | | Update settings[^1] | **Yes** | No | No | | Update notifications | **Yes** | No | No | | Update members | **Yes** | No | No | | Share builds with individual testers | **Yes** | No | No | | Send link for build via Slack | Yes | Yes | Yes | | Upload builds | **Yes** | **Yes** | No | | Update build tester notes | **Yes** | **Yes** | **Yes** | | Install builds | **Yes** | **Yes** | **Yes** | | Archive build | **Yes** | No (default), but can be granted | No (default), but can be granted | | Edit buckets | **Yes** (except personal) | No | No | | Delete buckets | **Yes** (except personal) | No | No | [^1]: # Sharing builds Runway's Build Distro buckets make sharing builds straight forward. To grant access to a set of builds to members of your team, you have a few options: * **Add individuals or user groups as bucket members:** this grants users access to view and install all builds in the bucket. * **Share individual builds** **with specific people:** this grants users access to viewing and installing only the specific builds you share with them. This is a great option if you want to share a specific build without granting the user access to the entire bucket. * **Enable org-wide access on a bucket**: this will grant all users in your Runway organization access to viewing and installing all builds in the bucket. There are two ways to share and distribute builds with your team in Runway: inviting team mates to be bucket members, or sharing specific builds with one or more of your team mates. ### Bucket members
Add individual testers or user groups as bucket members to grant them access to viewing and installing all bucket builds. Bucket members can have one of three different roles: * **Admin**: Admin bucket members can edit bucket settings, manually upload builds to the bucket, share builds with individual testers, and install builds from the bucket * **Uploader**: Bucket members with the Uploader role can manually upload, view, and install bucket builds * **Tester**: Bucket members with the Tester role can view and install bucket builds. They can also update build tester notes. You can add individual app users as bucket members or entire user groups which will grant bucket access to any app users with in the given user group. {% hint style="success" %} Use the **Share** button in the build details drawer to copy a link to the build to your clipboard. {% endhint %} ### Share individual builds If you don't want to share an entire bucket with someone, you can also choose to share specific builds with individual testers. Only bucket admins can share builds with individual testers. When you share a build with one or more testers, they'll appear in the "Shared with" section in the build details drawer. People that you've shared individual builds with will also get a Slack DM notification with the details of the shared build.
Builds that have been shared with you will appear in the “Shared with me” section.
If you share a build with an individual tester, they will be able to view and install that specific build, but they won't have access to other builds in the bucket. # Installing builds ## Register test devices Testers can register their devices from Runway's desktop site by navigating to **Profiles and devices** and selecting **Add a test device**. Runway provides the option to register devices via a QR code or manually. {% hint style="info" %} The QR code device registration flow is currently supported on mobile devices using Chrome and Safari. {% endhint %} ## Installing builds Builds can be installed on a compatible mobile (iOS or Android) device either from the [Runway desktop site](#installing-a-build-from-the-runway-desktop-site), or by navigating to the Runway site on your mobile device’s browser. Note that on iOS, only `.ipa` builds are currently installable. Supported binary file types are: * `.apk` * `.aab` * `.ipa` {% hint style="info" %} Android AAB builds cannot be directly installed on Android devices by default. {% endhint %} {% hint style="success" %} Runway can automatically generate installable universal APKs from AABs being pulled into a bucket. To enable this functionality you must upload your app's signing key to Runway under [App settings > Signing keys](/using-runway/app-settings/signing-keys). {% endhint %}

List of builds in buckets

Bucket detail with installation action

### Installing a build from the Runway desktop site To install a build from the Runway desktop site, click one of the two options on the “Install” menu for the desired build: * **Install on mobile device from QR code**: a QR code will be surfaced that you can scan with the camera app on your phone. You will be prompted to sign in on the Runway mobile site, after which the appropriate build installation page will open. Clicking “Install” from the build details page on your mobile device will install the build * **Share a link with myself on Slack**: A link to the installation page will be sent to you via Direct Message (DM) on Slack. Open the link on your mobile device, and then click “Install” on the build details page from your mobile device to install the build {% hint style="warning" %} iOS builds must be properly signed and provisioned for installation before you can install them on your device. See the [signing & provisioning cheatsheet](/using-runway/build-distro/signing-and-provisioning-cheat-sheet) section for more details on how to sign and provision builds for installation. {% endhint %} # Signing and provisioning cheat sheet Use this cheatsheet to understand how different provisioning and signing configurations allow (or disallow) for build installation on a given device. ## iOS signing and provisioning
Profile TypeCertificate TypeWho can install?
DevelopmentDevelopmentAny device whose device identifier is included in the Development profile that was used for the build
Ad HocDistributionAny device whose device identifier is included in the Ad Hoc profile that was used for the build
App StoreDistributionCannot be installed outside of TestFlight
In House (Enterprise)DistributionAny device. You must establish enterprise app trust before you can install an app with an Enterprise profile.
\ Android signing ---------------
Signing TypeWho can install?
UnsignedAndroid requires all APKs to be signed in order to be installed. Unsigned APKs cannot be installed.
SignedAll Android devices can install signed APKs as long as they’ve enabled the “Install unknown apps” setting. To enable this setting, follow these steps.
### **Enabling APK sideloading on Android devices** In order to enable your Android device to install APKs downloaded outside of the Play Store, you must first enable the “Install unknown apps” setting on your device. Follow these steps to enable this setting: 1. On your Android device go to **Settings > Apps** 2. Go to **General > Special App Access** 3. Scroll down and go to **Install unknown apps** 4. Select the app corresponding to your device’s browser (usually Chrome) and enable **Allow from source** {% hint style="info" %} The exact steps to enable APK sideloading may differ based on your device and version of Android. {% endhint %} # Search in Build Distro The following fields are searchable within Build Distro. We will try to partially match these field values with the search query. * Original file name * Bucket id * Bucket name * Created at * Updated at * CI build info * Identifier * URL * Started at * Finished at * Status * Provider build status string * Commit hash * Commit message * Commit author * Commit URL * Workflow displayable name * Branch * PR number * PR title * PR owner * Binary build info * ID * Type (`ipa`, `apk`, `aab`) * Number * External version string * Artifact file name * Provisioning profile info * Id * Name * Type * Expiration date * Creation date * State * Bundle id # Organization overview {% hint style="warning" %} Some features may be limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) to learn more. {% endhint %} The **Organization overview** page provides a high-level view of aggregated statistics across your entire organization. Your team can use these metrics to draw insights on the overall health of your release process, and identify areas that are trending either in a positive or negative direction across your organization. ## Navigating to the organization overview page * Method 1: Click your organization icon or name on the floating 'pill', at the bottom of the sidebar
* Method 2: Open the first dropdown at the top of the sidebar, and click your organization name
## Organization overview statistics and controls At the highest level, you’ll see statistical averages and trends for a number of key metrics across recent releases for all apps in your organization. {% hint style="info" %} Don’t see a statistic that your team would find useful? [Reach out](mailto:hello@runway.team) and let us know! We’ll be adding more types of statistics to this page regularly. {% endhint %} ### Filtering Leverage the filters on the left-hand side to drill into data across any time range, flightpath, destination, platform, or team. We've also added benchmark data to key metrics like release frequency, hotfix rate, and time to recovery so that you can understand how your team is performing relative to your peers. ### Layout **Click and drag from the bottom right** of any chart to adjust the height or width of the chart. **Click and drag from the top** of a chart to move its position within its category. ### Insights The **Insights** banner at the top of the view surfaces high-level, noteworthy trends. {% hint style="info" %} Insights are computed based on the past 90 days of data and reflect all available metrics, regardless of the time frame or filters applied. {% endhint %} ### Metrics details | Metric | Calculation | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Time to recovery |

Time elapsed between a failed release and a subsequent hotfix. A failed release is one that meets at least one of the following conditions:

- The release has a hotfix released directly afterwards
- Rollout health metrics are set up and one or more metrics become unhealthy after release
- The release was phased and its rollout was halted and never resumed

| | Release failure rate |

Period average of failed releases as a percentage of all releases. A failed release is one that meets at least one of the following conditions:

- The release has a hotfix released directly afterwards
- Rollout health metrics are set up and one or more metrics become unhealthy after release
- The release was phased and its rollout was halted and never resumed

Exclusions: Hotfix releases

| | Hotfix to non-hotfix release ratio | Period average of the ratio of releases that were hotfixes to releases that were not hotfixes. | | Checklist item completion time | Average time to complete a checklist item within a given release. | | Release step completion time (non-hotfixes) |

Completion times for all steps during a given release. Steps may be running in parallel, so the sum of all times for a given release will not necessarily correspond to real time elapsed.

Exclusions: Releases with no step timing data, hotfix releases. Missing step types do not factor into calculations.

| | Release step completion time (hotfixes) |

Completion times for all steps during a given hotfix release. Steps may be running in parallel, so the sum of all times for a given release will not necessarily correspond to real time elapsed.

Exclusions: Releases with no step timing data, non-hotfix releases. Missing step types do not factor into calculations.

| | Release frequency | Period average for the rate of releases. | | Lifecycle timing |

Aggregated period averages of time spent in each phase of the product development lifecycle.

Exclusions: Work items with no ticket creation time are excluded from wait time; negative durations are dropped.

| | | | | Target date hit rate - Kickoff |

Period average of percentage of releases where kickoff was completed on, or before, the target kickoff date.

Exclusions: Hotfix releases.

| | Target date hit rate - Submission |

Period average of percentage of releases where submission was completed on, or before, the target submission date.

Exclusions: Hotfix releases.

| | Target date hit rate - Release |

Period average of percentage of releases shipped on, or before, the target release date.

Exclusions: Hotfix releases.

| | Checklist item completion rate |

Percentage of checklist items completed.

Exclusions: Hotfix releases.

| | Checklist item overdue rate |

Percentage of checklist items that were not marked as completed before deadline passed.

Exclusions: Hotfix releases.

| | | | | Build distro builds | Total number of builds downloaded during the selected date range. | | Build distro artifact size | Average size (MB) of artifacts during the selected date range. | | Bundle install size |

Average install size on device (in MB) for selected app store build for a given release

Exclusions: non-iOS apps.

| | Bundle download size | Download size (in MB) for selected app store build for given release (or average download size for multiple Android builds) | | App store builds | Total app store builds during the given release. | | Build time | Average CI build duration for all builds during the given release. | | Build success rate | Percentage of CI builds that completed successfully during the given release. | | Builds | Total number of CI builds triggered during the given release. | | Release duration (hotfix) |

Time from kickoff to release for hotfixes.

Exclusions: Non-hotfix releases.

| | Release duration (non-hotfix) |

Elapsed time from kickoff to release completion for the given release.

Exclusions: Releases missing kickoff or release events, hotfix releases.

| | Fix acceptance rate | Accepted fix requests divided by total number of fix requests for a given release, expressed as a percentage. | | Lines of code added (non-hotfixes) |

Total lines of code added for the given release.

Exclusions: Hotfix releases.

| | Lines of code added (hotfixes only) |

Total lines of code added for the given hotfix release.

Exclusions: Non-hotfix releases.

| | Lines of code changed (non-hotfixes) |

Total lines of code changed for the given release.

Exclusions: Hotfix releases.

| | Lines of code changed (hotfixes) |

Total lines of code changed for the given hotfix release.

Exclusions: Non-hotfix releases.

| | Lines of code deleted (non-hotfixes) |

Total lines of code deleted for the given release.

Exclusions: Hotfix releases.

| | Lines of code deleted (hotfixes) |

Total lines of code deleted for the given hotfix release.

Exclusions: Non-hotfix releases.

| | Items of work completed |

Total number of work items shipped in a given release. Work items include any of the following:
- Any commits/code in the diff since the preceding version's release tag
- Any open PRs against the release branch
- Any tickets which are explicitly labeled for the release via a “feature affiliation” (e.g. a label, 'Fix version', tag, etc.)
- Any tickets, regardless of explicit label or otherwise, which are referred to by code (via commit message, PR title, or branch name) that is associated with the release (either 1 or 2 above)
- Any code, regardless of where it lives, that refers to a ticket (via commit message, PR title, branch name) which is explicitly labeled for the release

| | Number of fix requests | Total number of fix requests for a given release. | | Number of fixes | Total number of fixes for a given release. | | Number of tickets |

Total number of tickets associated with the given release. Runway associates tickets with a release via the following logic:
- Any tickets which are explicitly labeled for the release via a “feature affiliation” (e.g. a label or 'Fix version' in Jira)
- Any tickets, regardless of explicit label or otherwise, which are referred to (via commit message, PR title, or branch name) by code that is associated with the release (either 1 or 2 above)

| | Fix requests approved | Total number of approved fix requests for a given release. | | Fix requests rejected |

Chart: Total number of rejected fix requests for a given release.

Primary value: Average over the selected date range.

| | Completed work items fix percentage | Completed work items that were fix requests divided by total number of completed work items for a given release, expressed as a percentage. | | Review wait time |

Time a new app submission spent waiting in Apple's review queue before active review began.

Exclusions: Releases missing a submission or review start event.

| | Time in review | Time a new app submission spent actively in review by Apple. | | Release rejection rate |

Period average of percentage of releases that were rejected by the app store.

Exclusions: Non-iOS apps.

| | Number of commits (non-hotfixes) |

Total number of commits included in the given release.

Exclusions: Hotfix releases.

| | Number of late merges | Total number of pull requests merged after the release branch is cut. | | Session adoption rate | Max adoption rate achieved for a given release. | | Metrics from an 'Observability & analytics' integration | Metric (ingested from an 'Observability & analytics' integration and configured in Health metrics within Settings) associated with a given release. | | Crash-free sessions | Percentage of sessions without crashes in a given release. | | Crash-free users | Percentage of users without crashes in a given release. | | Beta crash-free sessions | Percentage of sessions without crashes in a given beta release. | | Beta crash-free users | Percentage of users without crashes in a given beta release. | | User rating (release-specific) |

Average rating from user reviews for a given release. Due to API restrictions, this only includes ratings associated with a written review.

Exclusions: Apps other than iOS and Android.

| | User rating (all releases) |

Period average of the overall app rating (across all versions).

Exclusions: Apps other than iOS and Android.

| {% hint style="info" %} **Trends** are computed using [basic linear regression](https://en.wikipedia.org/wiki/Simple_linear_regression). {% endhint %} # Organization settings Click your organization icon (on the sidebar all the way to the left, second from the bottom) to navigate to the **Organization overview**, then click the **Settings** button to the right to view team members, view and manage user groups, and manage SSO settings (if applicable). Some features may be disabled depending on your user's permissions. ### Adding users to your Runway organization #### Allowing others to automatically join your organization When the toggle under **Teammates can automatically join your organization** is enabled, teammates will be able to join your organization in Runway by visiting :link: [**app.runway.team**](https://app.runway.team) and signing up with your approved email domain(s). {% hint style="warning" %} If this setting is turned off and a teammate creates a Runway account without an [invite](#undefined) from an existing member of your organization, they will become part of a new, unassociated organization in Runway.\ \ If you need assistance moving over teammates from another organization, just [get in touch](mailto:support@runway.team). {% endhint %} {% hint style="info" %} If you need to add alternate approved email domains to your organization (*e.g.* your email address is **** but your teammate has the address ****), please [let us know](mailto:support@runway.team) and we'll assist. {% endhint %} ### Inviting your team Click the **Invite team** button to send invites to new team members. When they accept the email invite and create their accounts, they'll be automatically added as members of your existing Runway organization. {% hint style="warning" %} Runway does not verify [allowed domains](#allowing-others-to-join-organization) on email addresses for anyone sent an invite by an existing member of an organization. {% endhint %} ### Single Sign-On (SSO, SAML) If your organization is configured to use SSO/SAML, you'll see the configuration status here. Organizations on **Enterprise** tiers can enable this feature by [contacting Runway support](mailto:support@runway.team). Runway uses [WorkOS](https://workos.com/security) as an authentication provider for SSO/SAML organizations. Org admins can access the **SSO admin portal** from here. {% content-ref url="/pages/Dq6KoVV3EoYRcqUPk1AB" %} [SSO/SAML](/using-runway/organization-settings/sso-saml) {% endcontent-ref %} ### Integrations View all connected integration providers in your organization, and manage provider-level settings like the Runway user groups to Slack groups mapping. # Team ## Team settings #### **Add new users to all apps** When enabled, any new users joining your organization in Runway will automatically be added as app users to all apps in your organization. #### Enable role-based access controls Which features users can interact with in Runway will be determined by their assigned user groups. {% hint style="info" %} Role-based access control is available for teams on the **Enterprise** plan only. {% endhint %} ## Users View and manage users in your organization in Runway. The following information for each user is available in the user table: * User email * User permissions * User groups that the user is a member of * The apps the user is a member of {% hint style="info" %} Admin users can edit a user's groups and apps, and remove users from your Runway organization. {% endhint %} ## Groups View and manage user groups for your organization in Runway. User groups define a set of allowed user actions that group members can perform. {% hint style="info" %} If your organization uses Directory Sync, user groups and group membership are managed by your directory and can't be edited in Runway. To manage user groups in Runway while still provisioning users from your directory, see [Where Runway user groups are managed](/using-runway/organization-settings/sso-saml#where-runway-user-groups-are-managed). {% endhint %} {% hint style="info" %} Groups can be assigned as owners to checklist items, regression items, approval items, and as members of Build Distro buckets. They can also be mentioned in notifications. {% endhint %} The groups table shows all available user groups, including default user groups and their assigned members, plus any custom groups that have been created for your organization. ### Default user groups By default, all Runway organizations come with a set of user groups that are common to many mobile teams. The set of default user groups are: * Release Pilots * Engineering Managers * Engineers * Product Managers (PMs) * QA * Marketing * Design * Stakeholder / Approvers * CX * Ops Default user groups come with a defined set of user actions that group members are allowed to perform. {% hint style="info" %} The name and set of user actions associated with default user groups cannot be modified. If you wish to define a user group with a custom set of allowed user actions, you must create a custom group. {% endhint %} ### User permissions and actions The table below outlines the default set of allowed actions each default group is allowed to perform. It also describes the complete set of user actions that can be assigned to user groups. {% hint style="info" %} By default, all users have read access to every app in the organization; however, organizations can enable a setting that restricts visibility so users must be explicitly added as members of an app to view its data. [Get in touch](mailto:hello@runway.team) if you'd like this setting to be enabled for your organization. {% endhint %} {% hint style="info" %} App membership is required to perform write actions. You can opt in to automatically adding new users to all existing apps from **Org settings** > **Team**. {% endhint %} {% embed url="" fullWidth="false" %} Custom user groups can be created to define a specific set of user actions that a defined set of users can perform within Runway. To create a custom group, navigate to **Organization settings > Team > Groups** and click "Create group". Choose the group's name, the set of actions that users in the group will be allowed to perform, and specify group members.
{% hint style="info" %} Custom groups are available for teams on the **Enterprise** plan only. {% endhint %} {% hint style="success" %} Use the "Copy from existing group" helper action to copy over user actions and group members from another group when creating or editing a custom group. {% endhint %} {% hint style="info" %} A user's groups can also be modified from the user table by finding the specific user in the list of users, and clicking "Edit user". {% endhint %} For users that belong to multiple groups, the union of allowed actions across all groups they belong to will define the set of actions that user can perform. For example, if User A belongs to the following groups: * Feature team A * User action: Create/edit/delete releases * Feature team B * User action: Submit app for review User A will be have permission to perform both "Create/edit/delete releases", and "Submit app for review" actions. ### Mapping Runway user groups to Slack groups Slack groups can be a great way to group together members of your team so they can be mentioned with a single handle. User groups in Runway also provide a way group together related groups of users and define allowed actions for those users. In Runway, you can map Runway's user groups to groups in Slack, so that any time a group of users is mentioned in Slack notifications, Runway can mention the corresponding Slack group. This can be particularly useful for checklist items, Approvals items, and Regression testing items that are assigned to user groups – Slack reminder pings for these items will mention the appropriate Slack group. To update the mapping of Runway user groups to Slack groups for your organization's Slack integration provider, go to **Organization > Settings > Integrations > Slack,** and edit the **Runway user groups to Slack groups** mapping table. {% hint style="success" %} Enable the [Sync Slack groups automation](/automations/types-of-automations#sync-slack-groups) on your apps and Runway can take care of adding and removing team members from the appropriate Slack groups based on their group membership in Runway. {% endhint %} # SSO/SAML SSO/SAML support is available for **Enterprise** teams. Note that this functionality first **needs to be enabled** for your organization by the Runway team. [Get in touch](mailto:hello@runway.team) if needed, and we'll get this set up. Runway uses [WorkOS](https://workos.com/) to provide SSO/SAML capabilities to our teams, for a wide range of identity providers. {% hint style="warning" %} Signing into Runway with email and password will be disabled by default once SSO/SAML is enabled. If you’d still like to **allow email and password sign in** alongside SSO/SAML as an option, [let us know](mailto:hello@runway.team) and we’ll enable it. {% endhint %} {% hint style="info" %} Login sessions remain active for 72 hours. After that, users will be prompted to log in again for security and session management purposes. {% endhint %} ## SSO/SAML configuration ### Setup Setup and configuration are simple, and can be performed following the steps below. {% hint style="warning" %} The Runway user executing these steps must have the **IT Admin** role, which needs to be assigned by the Runway team. [Let us know](mailto:hello@runway.team) the email address of the person in your organization who will be completing SSO/SAML setup and we’ll assign the role. {% endhint %} 1. Sign into Runway using existing email/password credentials for an account that has the **IT Admin** role 2. Navigate to your organization’s settings by clicking on your organization avatar in the main navigation bar:\ \ ![](/files/zl0P6cb5QhF0aK9Sdis6)
3. On the **organization settings** page, navigate to the SSO/SAML tab. You’ll see an SSO module at the top that shows your current SSO connection status, and a button that redirects to the SSO admin portal. The status will read **Not Connected** until your IT admin has configured the SSO integration.
4. Click on the **SSO admin portal** button and follow the instructions in the WorkOS setup flow to configure your SSO connection. 5. Once you’ve completed the SSO connection setup process, you will be redirected back to Runway, where your SSO connection status should now show as **Active**.
## Directory Sync Directory Sync allows your organization to manage Runway users and, optionally, their Runway user groups and app membership from your company's central user directory. When enabled, your Runway organization will be automatically kept in sync with your company directory, so your directory can be the source of truth for Runway user provisioning and their access levels. Directory Sync can only be configured by a Runway user with the IT Admin permission. {% hint style="warning" %} If you choose to have your directory groups manage Runway user groups, **any existing user groups set up in Runway will be overwritten** to reflect your organization's structure in your directory provider. Additionally, if no user group directly mapping to a **Release pilot** group is found, existing pilot rotations in Runway will be lost. You choose this when you connect your directory, and you can change it at any time. See [Where Runway user groups are managed](#where-runway-user-groups-are-managed) for more details. {% endhint %} 1. In the **Organization settings** page, navigate to the **SSO/SAML** tab. You’ll see a module labeled Directory Sync with an initial status of **Inactive.**
2. Click the button labeled **Directory Sync admin portal**. \ You can choose where your groups will be managed. Pick **No, manage Runway groups separately from directory groups** to keep managing user groups yourself, or **Yes, update Runway groups based on your directory group changes** to have your directory manage them. For more details, see [Where Runway user groups are managed](#where-runway-user-groups-are-managed).
3. You’ll be redirected to an admin portal hosted by Runway’s SSO/SAML provider, WorkOS. Follow the instructions in the Directory Sync setup flow to configure the Directory Sync connection. 4. You will then be redirected back to Runway, where the Directory Sync status should read **Connected**.
4. If groups have been created in your identity provider, you’ll see them populated under the **Groups to Runway user roles** table. 5. If you chose **Yes, update Runway groups based on your directory group changes**, you can configure the mapping of **Groups to Runway user roles** for each group to automatically have Runway roles assigned to users that belong to each group.
Once setup is complete, Runway will automatically sync Runway user roles based on each user's configured groups. Additionally, users will be automatically provisioned and deprovisioned in Runway as needed using your directory provider as the source of truth. {% hint style="warning" %} Once Directory Sync has been successfully connected, managing Runway user roles from the Runway dashboard will be disabled; your directory provider should be the source of truth for Runway user roles going forward. Removing users from your Runway organization will also be disabled; removing users should be done from your directory provider, which will automatically propagate to Runway. {% endhint %} #### Where Runway user groups are managed Directory Sync can manage your Runway user groups for you, or leave them to you: * **Managed in Runway:** Directory Sync only provisions your users. You keep managing user groups yourself under **Organization settings > Team**, from both the **Users** table and the **Groups** table. Your **Groups to Runway user roles** mapping table stays visible as read-only, so an existing mapping isn't lost. To select this option, pick **No, manage Runway groups separately from directory groups** when activating Directory Sync for the first time. * **From my directory groups:** Groups from your directory provider define Runway user groups, according to the mapping you configure under **Organization settings > SSO/SAML**. User group assignments that already exist in Runway will be overwritten. To select this option, pick **Yes, update Runway groups based on your directory group changes** when activating Directory Sync for the first time. Either way, Directory Sync keeps creating, updating and deprovisioning users, and keeps syncing app membership if you use it. Runway asks where your groups should be managed when you click **Directory Sync admin portal** to connect a directory for the first time. \ To change it later, check or uncheck **Enable directory groups to Runway groups mapping** under **Organization settings > SSO/SAML**. {% hint style="warning" %} Enabling Directory Sync before your users and groups are properly configured may cause unexpected overwrites to existing permissions in Runway, including pilot roles and rotations. Selecting **From my directory groups** reapplies your directory groups across your whole directory: any user group assigned by hand in Runway that isn't part of a directory group mapping is removed. This runs in the background and may take a few moments for larger directories. Selecting **Managed in Runway** keeps the group assignments your users already have. {% endhint %} {% hint style="info" %} If you connect a directory from the WorkOS dashboard or straight from your identity provider rather than from Runway, your directory groups manage Runway user groups, and that can be changed afterwards under **Organization settings > SSO/SAML**. {% endhint %} ### Configuring Runway app membership sync with Directory Sync By default, all new users added to Runway are automatically added as members to all apps in your Runway organization. With Directory Sync, you can optionally choose to leverage your directory provider to manage which apps in Runway new users are added to. #### Setup 1. In your directory provider, add a custom attribute to your user model to represent the apps in Runway the user should be a member of (we recommend an attribute named `runway_apps`). The field should be an array of strings. Runway will use this field to assign users to the correct apps in Runway. 2. For each User in your directory, populate the `runway_apps` field with correct app IDs – note that the app IDs populated in the `runway_apps` field must match one of the app IDs for your organization’s apps in Runway. You can find each app’s app ID under **App settings > General > App identifier** for each app in Runway. 3. Alternatively, if your provider supports this, you can set up a rule at the group level to populate the `runway_apps` field for each user that belongs to the group. 4. Head to the Directory Sync admin portal in Work OS by navigating to **Organization settings > SSO/SAML > Directory Sync admin portal**. In the section titled **Attribute Mapping**, fill in the name of your custom attribute in the **Directory Provider Value** field.
Once configured, Runway will read from your custom attribute to populate the `runway_apps` field in Runway and sync the user's app membership to match what's defined in your directory provider. If you'd like a user to belong to all apps in Runway, set the value for `runway_apps` to the wild card, which is `["*"]` . {% hint style="warning" %} If the `runway_apps` field is detected on any user, the setting to **Add new users to all apps** (found in Organization Settings > Team) will be automatically disabled — your directory provider will be considered the source of truth for app membership going forward. Note that after step 4 is completed, any users that have an **empty** or **missing** `runway_apps` field will be considered as not belonging to any app in Runway, and any previous app membership will be removed, as the aforementioned field will be considered the source of truth. {% endhint %} # Tag management Tags are custom labels managed at the organization level that can be applied to one or more destinations across any Flightpath. They're useful for grouping destinations by shared characteristics — for example, `tier-1`, `region-us`, or `premium` — and filtering your org-wide data by those groups. Because tags live at the org level, a single tag can span destinations across multiple Flightpaths, though it doesn't have to. ### Managing tags From here you can: * **Create a tag** — give it a name and select which destinations it applies to * **Edit a tag** — update the name or the destinations associated with it * **Delete a tag** — remove it from all destinations it was applied to When creating or editing a tag, you can assign it to multiple destinations at once using the multi-select picker. ### Filtering by tags There are two places where you can filter by tags in Runway: **Org overview** and **Integration settings**. On the **Org overview**, you can filter charts and data by one or more tags. This lets you focus on a specific subset of destinations — for example, viewing release health only for your `tier-1` apps. To apply a tag filter on **Org Overview**: * Use the tag filter alongside the **Users & Groups** section * Select one or more tags — the data across all charts will update to reflect only the destinations associated with those tags On **Integration settings**, you can filter integrations by one or more tags. This lets you focus on integrations for a specific subset of destinations. To apply a tag filter on **Integration settings**, simply search by tag at the top right of the page. # User settings View and update your user's settings. Click your user's icon (on the sidebar all the way to the left, the icon on the very bottom) to navigate to the **User settings** page. ### My Devices The **My Devices** list displays a list of iOS devices that you have registered for use within Runway. Registering a device associates it uniquely with your user – this enables features for Apple platforms apps like automatically registering your device in App Store Connect and adding your device to Ad Hoc and Development provisioning profiles. For more details on device-related features available for Apple platform apps in Runway, click [here](/using-runway/app-settings/profiles-and-devices#devices). ### Email notification Runway may send you email notifications in various scenarios, and you can customize which email notifications you receive by opting in or out of different types of email notifications. Email notifications are grouped into a few categories: * **Organization level email notifications** – emails that share information for all apps in your organization, or pertaining to events occurring for your Runway organization. * Opt into the **Org app releases digest** to receive a biweekly summary of active and upcoming releases for all apps in the organization. * **App level email notifications** – emails that share information or pertaining to events occurring in a specific app in your Runway organization. You can customize which apps you want to receive email notifications for. * **Bucket level email notifications** – emails sharing information or pertaining to events occurring in a specific bucket within an app in your Runway organization. You can customize which buckets you want to receive emails notifications for each app in your organization. # Over-the-air (OTA) releases How to use Runway for over-the-air releases
Teams that are shipping apps built with React Native or Flutter that are doing over-the-air releases alongside their binary releases can use Runway’s special OTA platform to streamline their over-the-air release process. ## How it works Over-the-air (OTA) releases in Runway are surfaced as a separate app platform. Many of the release steps that are available in binary release contexts are also available for OTA releases. Other release steps are unique to the OTA platform type, since the process tends to differ from that of binary releases. The following release steps appear by default for OTA apps in Runway: * **Kickoff:** Monitors the kickoff of your OTA release process, including release branch creation (if relevant based on your configured branch patterns) and release versioning * **Feature readiness:** Surfaces the work items (code and project management tickets) going into the release * **Staging release**: Configured to point to the CI/CD workflow that’s responsible for building and uploading an OTA bundle to a staging environment * **Regression testing:** The status of regression testing on the staging build, and any regression testing items * **Beta testing:** The status of any beta testing being performed on the staging build * **Approvals:** Approval items, if needed For teams that leverage Expo EAS for OTA releases, Runway offers a [direct integration](/integrations/app-stores/expo-eas). Once the integration is connected, the following release steps appear by default in Runway: * **Release:** Select the update group for the branch mapped to your configured production channel in Expo EAS * **Rollout:** Monitor and manage staged/phased rollouts in Expo EAS directly from Runway For teams that do not leverage Expo EAS for OTA, the following release steps appear by default in Runway: * **Production release:** Configured to point to the CI/CD workflow that’s responsible for building and uploading an OTA bundle to your production environment {% hint style="info" %} OTA releases not through Expo EAS are considered complete once the “Production release” step is complete – that is, as soon as the CI/CD workflow that’s responsible for building and uploading an OTA bundle to your production environment has succeeded. {% endhint %} ### OTA release versioning Runway can be configured to detect an OTA release version from any file of your choosing. By default Runway will read from the version key found in your app’s `package.json`.
# AI in Runway A number of features within Runway are powered by AI. We integrate with third party APIs from both Anthropic and OpenAI, and you can select which provider is used by navigating to **Org settings > AI**. You can optionally provide your own API key for either provider and globally enable/disable AI for your org in the same area of settings. {% hint style="info" %} We do not maintain our own models nor do we train or permit third parties to train on any of our customers’ data. {% endhint %} Features in Runway that may leverage AI functionality: * [App store review issues](/using-runway/rollout#review-issues) * [App store review translation](/automations/types-of-automations#translate-app-store-reviews) * [CI build diff summaries](/automations/types-of-automations#auto-generate-summary-of-diff-in-ci-builds) * Org overview insights * Release notes and summaries * [Runway Release ATC chatbot](/integrations/notifications/slack#runway-release-atc) # Integrations overview Integrations are core to Runway, and we’ve put a lot of work into making them a seamless, robust, and secure part of the experience. Once you connect your toolchain, Runway does the rest, understanding your team’s unique workflow and adapting accordingly. Our architecture supports quick rollout of new integrations, and we’re always ready to prioritize based on customer needs. If a piece of your toolchain isn’t yet supported, chances are [we can get that implemented](mailto:hello@runway.team) for you. {% hint style="warning" %} Some core integrations rely on Runway having an accurate understanding of your team's branching strategy to work properly. * Learn more about [supported branching strategies and setup tips](/getting-started/setting-up-your-integrations/branching-strategies). * Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} ## Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar {% content-ref url="/pages/-Mjj0GhhcMVRWsFLZiC-" %} [Integrations settings](/using-runway/app-settings/integrations-settings) {% endcontent-ref %} ## Integration refresh/sync times Generally, when a change occurs in an integration, you can expect it to be reflected in Runway within 10 minutes. For many integrations (in particular, version control systems and CI/CD) updates will happen more quickly due to their webhook support. ### Trigger manual refresh 1. Click the cloud sync icon () found opposite the settings icon (⚙️) in the sidebar 2. Clicking the retry icon ( ). If a refresh is not already in progress, this action will not be available until it completes. {% hint style="warning" %} Manual refreshes are limited to 5 per hour. {% endhint %} ## Supported integration types {% hint style="warning" %} Some integrations may be limited to certain plans. Please visit our [pricing page](https://runway.team/pricing) to learn more. {% endhint %} {% content-ref url="/pages/-MjGrv6nxDu1qvmby-cz" %} [Version control](/integrations/version-control) {% endcontent-ref %} {% content-ref url="/pages/-MjGw-WHr-cmunqtCoK3" %} [Project management](/integrations/project-management) {% endcontent-ref %} {% content-ref url="/pages/-MjGz6yJE-IGNzuyW0jq" %} [CI/CD](/integrations/ci-cd) {% endcontent-ref %} {% content-ref url="/pages/-MjGzKQXpQfGlhp4L8vk" %} [App stores](/integrations/app-stores) {% endcontent-ref %} {% content-ref url="/pages/-MjndnooufNkOcpTfAZU" %} [Regression testing](/using-runway/release-steps/regression-testing) {% endcontent-ref %} {% content-ref url="/pages/dHyXhTZuorZ6l54GHTcU" %} [Beta testing](/integrations/beta-testing) {% endcontent-ref %} {% content-ref url="/pages/-MjH-3CNL22wEmdEaNhP" %} [Notifications](/integrations/notifications) {% endcontent-ref %} {% content-ref url="/pages/-MjH-A8ouMQypLMZRmsc" %} [Stability monitoring](/integrations/stability-monitoring) {% endcontent-ref %} {% content-ref url="/pages/FOJh5iHH35N76RFBruDZ" %} [Observability & analytics](/integrations/observability-and-analytics) {% endcontent-ref %} {% content-ref url="/pages/l8VL3IYxNEEO2whTEWNR" %} [Feature flagging](/integrations/feature-flagging) {% endcontent-ref %} {% content-ref url="/pages/wecgzInaYq8QO4MUmIhX" %} [Incident management & scheduling](/integrations/incident-management-and-scheduling) {% endcontent-ref %} {% content-ref url="/pages/juoO4KxghtVwtLRWFAY9" %} [Translations](/integrations/translations) {% endcontent-ref %} {% content-ref url="/pages/MaIyteWSlxuyeT7uSP0v" %} [Calendar](/integrations/calendar) {% endcontent-ref %} # Version control Automatically detect release branches, surface code-to-feature matches, and more. # Azure Repos ## ![](/files/pm2Xa8SCEtRjyuW5WFr8) ## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Azure Repos** 1. Find the **Azure Repos** integration module under the **Version control** section 2. Click the **Connect** button – you’ll be taken through a standard Azure DevOps App OAuth flow 3. Azure Repos will redirect you back to Runway 4. Select an Azure Repos project and repo to associate with your app in Runway ### **Add a release tag pattern** * Runway uses this to read tags from Azure Repos and delineate your releases, and also to generate tags when auto-tagging releases upon completion * Pattern accepts the string `{version}` as a stand-in for the release version, e.g. `v{version}` {% hint style="info" %} Runway expects version strings that adhere to [Semantic Versioning](https://semver.org/) principles — formatted as `x.y.z` (representing `major.minor.patch`). {% endhint %} ### **Add a release branch pattern** * For GitFlow or similar, pattern accepts the string `{version}` as a stand-in for the release version, e.g. `release-ios-{version}` * You can assign different patterns to different types of releases using the **Release type** dropdown * Omit pattern for trunk-based, e.g. `main` * Be sure to select **all types** in the **Release type** dropdown ### Add any additional branches * Working branch: your main working branch, e.g. `development` * Staging branch: if you create your Release Candidate builds from some branch other than your release branch, set that here * Deploy branch: if you create your final builds from some branch other than your release branch, set that here # Bitbucket
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Bitbucket** * Find the **Bitbucket** integration module under the **Version control** section * Click the **Connect** button * You’ll be taken through a standard Bitbucket OAuth flow * Select a specific Bitbucket org if you’re a member of multiple (otherwise will be pre-selected) {% hint style="warning" %} You must be logged in as a Bitbucket user with read/write permissions in the selected Bitbucket org. {% endhint %} * Bitbucket redirects you back to Runway, Runway presents a dialog in which to select the Bitbucket repository you want to connect ### **Add a release tag pattern** * Runway uses this to read tags from Bitbucket and delineate your releases, and also to generate tags when auto-tagging releases upon completion * Pattern accepts the string `{version}` as a stand-in for the release version, e.g. `v{version}` {% hint style="info" %} Runway expects version strings that adhere to [Semantic Versioning](https://semver.org/) principles — formatted as `x.y.z` (representing `major.minor.patch`). {% endhint %} ### **Add a release branch pattern** * For GitFlow or similar, pattern accepts the string `{version}` as a stand-in for the release version, e.g. `release-ios-{version}` * You can assign different patterns to different types of releases using the **Release type** dropdown * Omit pattern for trunk-based, e.g. `main` * Be sure to select **all types** in the **Release type** dropdown ### Add any additional branches * Working branch: your main working branch, e.g. `development` * Staging branch: if you create your Release Candidate builds from some branch other than your release branch, set that here * Deploy branch: if you create your final builds from some branch other than your release branch, set that here ### Adjusting permissions in Bitbucket Certain permissions need to be configured in Bitbucket in order for Runway to execute [automations](/automations/types-of-automations). #### **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: 1. Go to a repository in a project 2. Choose **Settings** > **Branch permissions** and select the target branch 3. Under the **Prevent changes without a pull request except by:** restriction, select the user that originally installed the Bitbucket integration in Runway {% hint style="warning" %} 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. {% endhint %} # GitHub
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect GitHub** * Find the **GitHub** integration module under the **Version control** section * Click the **Connect** button * You’ll be taken through a standard [GitHub app](https://developer.github.com/apps/) OAuth flow * Select one or more repos to grant access to {% hint style="warning" %} You must be logged in as a GitHub user with **admin** permissions in selected repo, or as an **owner** in the GitHub org. {% endhint %} * GitHub redirects you back to Runway * If you granted access to more than one repo, Runway will present you with a dropdown to select a specific repo ### **Add a release tag pattern** * Runway uses this to read tags from GitHub and delineate your releases, and also to generate tags when auto-tagging releases upon completion * Pattern accepts the string `{version}` as a stand-in for the release version, e.g. `v{version}` {% hint style="info" %} Runway expects version strings that adhere to [Semantic Versioning](https://semver.org/) principles — formatted as `x.y.z` (representing `major.minor.patch`). {% endhint %} ### **Add a release branch pattern** * For GitFlow or similar, pattern accepts the string `{version}` as a stand-in for the release version, e.g. `release-ios-{version}` * You can assign different patterns to different types of releases using the **Release type** dropdown * Omit pattern for trunk-based, e.g. `main` * Be sure to select **all types** in the **Release type** dropdown ### Add any additional branches * Working branch: your main working branch, e.g. `development` * Staging branch: if you create your Release Candidate builds from a branch other than your release branch, set that here * Deploy branch: if you create your final builds from some branch other than your release branch, set that here ## Adjusting permissions in GitHub Certain permissions need to be configured in GitHub in order for Runway to execute [automations](/automations/types-of-automations). ### How to update branch protection settings in GitHub {% hint style="info" %} 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 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. {% endhint %} #### Rulesets If your team uses rulesets, follow these steps to configure repository rulesets to allow Runway to bypass pull requests: 1. Navigate to your repository settings in GitHub 2. Select **Code and automation -> Rules -> Rulesets** and find the ruleset that you'd like to allow Runway to bypass pull requests for 3. Add Runway to the **Bypass list**
#### Branch protection rules If your team uses branch protection rules, follow these steps to allow Runway to bypass required pull requests for your target branch: 1. Navigate to your repository settings in GitHub 2. Select **Code and automation -> Branches** and find the branch for the target branch you'd like to allow Runway to bypass pull requests for 3. Under the **Require a pull request before merging** option, make sure that the setting **Allow specified actors to bypass required pull requests** is enabled 4. 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
5. 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
6. *(Optional — to allow Runway to create new branches)* Under the **Restrict pushes that create matching branches setting**, add the "Runway + GitHub" app to the list of apps allowed to create matching branches {% hint style="info" %} If you're seeing `422 Reference update failed` errors and you have ensured that your branch protection settings are appropriately configured, the error may be due to an illegal branch pattern. To test, please try to create the branch directly in GitHub and see if you receive the following error: `Sorry, that branch name is invalid.` {% endhint %} ### Ensure Runway can run status checks if needed
Enabling pull request bypass for Runway if your team is using GitHub rulesets is surprisingly simple thanks to the flexible and layered nature of how rulesets work. At a high level, simply add the Runway + GitHub app and mark it as **Exempt** to the bypass list of your repository's ruleset that contains the "Require a pull request before merging" branch rule. This 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](#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](/automations/types-of-automations#kick-off-release) automation or functionality in the Runway dashboard if your team uses version-specific release branches ### How to configure GitHub tag rulesets to enable tag creation Add the Runway + GitHub app to the bypass list for any active rulesets on the selected repositories where Runway needs to create tags, if those rulesets include any of the following rules: * **Restrict creations -** required for creating new tags # GitLab
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect GitLab** * Find the **GitLab** integration module under the **Version control** section * Click the **Connect** button * You’ll be taken through a standard [GitLab app](https://docs.gitlab.com/ee/integration/oauth_provider.html) OAuth flow {% hint style="warning" %} You must be logged into GitLab as a user with at least **Developer** permissions in the GitLab org. {% endhint %} {% hint style="warning" %} GitLab OAuth applications are tied to the user account that connected them. If this user account is deactivated from your GitLab organization, your Runway integration will also stop functioning. (This can be corrected by removing and reinstalling the GitLab integration as a new user.) We recommend that organizations connect to the GitLab OAuth application using a shared service account (e.g. a tools@ or dev@ account) to prevent disruptions to Runway's integration syncing service. {% endhint %} * GitLab redirects you back to Runway, Runway presents a dialog: * Select the project/repo where your code for this app lives ### **Add a release tag pattern** * Runway uses this to read tags from GitLab and delineate your releases, and also to generate tags when auto-tagging releases upon completion * Pattern accepts the string `{version}` as a stand-in for the release version, e.g. `v{version}` {% hint style="info" %} Runway expects version strings that adhere to [Semantic Versioning](https://semver.org/) principles — formatted as `x.y.z` (representing `major.minor.patch`). {% endhint %} ### **Add a release branch pattern** * For GitFlow or similar, pattern accepts the string `{version}` as a stand-in for the release version, e.g. `release-ios-{version}` * You can assign different patterns to different types of releases using the **Release type** dropdown * Omit pattern for trunk-based, e.g. `main` * Be sure to select **all types** in the **Release type** dropdown ### Add any additional branches * Working branch: your main working branch, e.g. `development` * Staging branch: if you create your Release Candidate builds from some branch other than your release branch, set that here * Deploy branch: if you create your final builds from some branch other than your release branch, set that here ### Adjusting permissions in GitLab Certain permissions need to be configured in GitLab in order for Runway to execute [automations](/automations/types-of-automations). #### 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: 1. In GitLab, select **Main menu > Projects** and find your project 2. On the left sidebar, select **Settings > Repository** 3. Expand **Protected branches** 4. From the **Branch** dropdown list, select the target branch 5. From the **Allowed to push** list, select the user that originally installed the GitLab integration in Runway {% hint style="warning" %} 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. {% endhint %} # Project management Import tickets from your project management tool to see at-a-glance what's going into your releases. # Asana
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Asana** * Find the **Asana** integration module under the **Project management** section * Click the **Connect** button * You’ll be taken through a standard [Asana app](https://developers.asana.com/docs/oauth) OAuth flow {% hint style="warning" %} You must be logged in as an Asana user in the workspace you want to attach. {% endhint %} * Asana redirects you back to Runway * Runway will present a dialog where you can select Asana projects to pull tasks from ### Add feature affiliations * Specify the tags that Runway should use to associate tasks with specific releases * Pattern is tokenized with the release version, *e.g.* `ios-{version}` # Azure Boards ## ![](/files/kdCo4mqTJaw5In7Jq4BM) ## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Azure Boards** * Find the **Azure Boards** integration module under the **Project management** section * Click the **Connect** button * You’ll be taken through a standard Azure DevOps OAuth flow {% hint style="warning" %} You must be logged in to Azure DevOps with a user that has access to the organization/project you want to connect. {% endhint %} {% hint style="warning" %} Make sure the **Third-party application access via OAuth** toggle is enabled from **Organization Settings > Policies** in Azure DevOps (see below) {% endhint %}
* Azure Boards redirects you back to Runway, Runway presents a dialog: 1. Select the project you want to connect from the dropdown of options 2. Optionally select any specific Azure Area Paths that contain work items that are in scope for this app (if no specific Area Paths are specified, Runway will consider all work items in the project) 3. Optionally select any *additional* columns that signify a “done” state for your work items (any columns marked as "done" states by Azure Boards are automatically treated as such by Runway) ### Add feature affiliations * Specify the tags that Runway should use to associate work items with specific releases * Pattern is tokenized with the release version, *e.g.* `ios-{version}` # GitHub Issues
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect GitHub** * Find the **GitHub** integration module under the **Version control** section * Click the **Connect** button * You’ll be taken through a standard [GitHub app](https://developer.github.com/apps/) OAuth flow * Select one or more repos to grant access to {% hint style="warning" %} You must be logged in as a GitHub user with **admin** permissions in selected repo, or as an **owner** in the GitHub org. {% endhint %} * GitHub redirects you back to Runway * If you granted access to more than one repo, Runway will present you with a dropdown to select a specific repo ### Add feature affiliations * Specify the labels and/or milestones that Runway should use associate tickets with specific releases * Pattern is tokenized with the release version, *e.g.* `ios-{version}` # Jira
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Jira** * Find the **Jira** integration module under the **Project management** section * Click the **Connect** button * You’ll be taken through a standard Jira app OAuth flow * Select a specific Jira org if you’re a member of multiple (otherwise will be pre-selected) {% hint style="warning" %} You must be logged in as a Jira user with read/write permissions in the selected Jira org. The Jira user that performs the OAuth needs to be granted the `ADMINISTER_PROJECTS` permission in each project from which you want to pull tickets. Make sure that this permission is assigned directly within Jira for all relevant projects. {% endhint %} {% hint style="info" %} Jira OAuth is "user bound", meaning all actions taken via the integration are associated to the Jira user that was used during the installation flow. Teams typically create a dedicated service account user for this purpose. {% endhint %} * Jira redirects you back to Runway, Runway presents a dialog: 1. Select all the Jira projects you want to pull tickets from 2. Select any additional columns that signify a “done” state for your tickets (Runway pre-selects any columns marked in Jira as “done” states) 3. Select any additional fields that you want to make available for filtering and visible in ticket details {% hint style="info" %} Runway also supports Jira Personal Access Token (PAT) authentication. If you would prefer to leverage this option, please [get in touch](mailto:hello@runway.team). {% endhint %} ### Add feature affiliations * Specify the labels and/or fix versions that Runway should use to associate tickets with specific releases * Pattern is tokenized with the release version, *e.g.* `ios-{version}` # Linear
With our Linear integration, you can see Issues (of all statuses) alongside the releases they’re a part of, the code they’re related to, and the people who are working on them. With builds and crash info layered on top, everyone on your team gets the complete picture at their fingertips, saving you from the noise of answering the same kinds of questions over and over again on Slack. Additionally, when you create a bug ticket in Linear and label it for a given release, Runway will highlight it as pending work and can gate app submission until it’s addressed. {% hint style="info" %} **Welcome Linear users! New to Runway?** Runway is mobile release management software that connects your existing project management, development, and performance monitoring tools together. This empowers you to see status and progress of all releases at-a-glance and to automate away a wide variety of release tasks both large and small. {% endhint %} ## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Linear** * Find the **Linear** integration module under the **Project management** section * Click the **Connect** button * You’ll be taken through a standard [Linear app](https://developers.linear.app/docs/oauth/authentication) OAuth flow {% hint style="warning" %} You must be logged in as a Linear user in the workspace you want to attach. {% endhint %} {% hint style="warning" %} This integration requires `admin`, `read`, and `write` scopes in order to allow certain automations, such as [Add missing labels or fix versions to tickets in project management tool](/automations/types-of-automations#add-missing-labels-or-fix-versions-to-tickets-in-project-management-tool), to work. {% endhint %} * Linear redirects you back to Runway, Runway presents a dialog: 1. Select all the Linear teams you want to pull tickets from 2. Select any additional columns that signify a “done” state for your tickets (Runway pre-selects any columns marked in Linear as “done” states) ### Add feature affiliations * Specify the labels that Runway should use associate tickets with specific releases * Pattern is tokenized with the release version, *e.g.* `ios-{version}` # Monday.com
## Setup ### Navigate to the Integration settings page 1. Select an app in the top left corner from the Switcher 2. Navigate to App Settings by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on Integrations in the sidebar ### Connect Monday.com {% hint style="warning" %} The Runway + Monday app must be installed on your team’s Monday.com workspace by a Monday.com account admin before it can be installed as an integration in Runway. For instructions on how to install the Runway + Monday app click [here](#installing-the-runway-+-monday-app-on-your-monday.com-workspace).
{% endhint %} 1. Find the Monday.com integration module under the Feature Management capability section 2. Click “Connect” 3. You’ll be taken through the standard Monday.com OAuth flow. ### Configure Monday.com Once the OAuth flow has been completed, you’ll be redirected back to Runway and prompted to configure your Monday.com integration with the following:
* **Boards**: select all boards that Runway should pull items in from for releases * **Done status columns**: for each board, choose which column should be used to track the status of items * **Feature affiliation columns**: for each board, choose which column should be used to associate items to specific release versions * **Additional Done statuses**: enter additional status strings that Runway should treat as “Done” for any given item. This is used to compute feature completeness for a given release in Runway. The status string "Done" is by default included in the list of Done statuses ### Add feature affiliations Specify the tags that Runway should use to associate tasks with specific releases. Feature affiliation patterns must be tokenized with release versions (e.g. `ios-{version}`).
### Installing the Runway + Monday app on your Monday.com workspace The Runway + Monday app must be installed on your team’s Monday.com workspace by a Monday.com account admin before it can be installed as an integration in Runway. Follow these steps to install the Runway + Monday app on your workspace:
1. As an account admin of your Monday.com organization, click [here](https://auth.monday.com/oauth2/authorize?client_id=1f69274505f7a6dfd3a27c6621f4a969\&response_type=install) to install the Runway + Monday app. 2. Select the relevant workspaces to install the app on. 3. Once the app has been installed, the Monday.com integration can be connected via OAuth and configured in Runway \ For more information on installing apps from the Monday.com app marketplace visit Monday.com’s [documentation](https://support.monday.com/hc/en-us/articles/360017126139-Understanding-apps-marketplace-security). # Shortcut
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Shortcut** * Find the **Shortcut** integration module under the **Project management** section * Click the **Connect** button * Enter a Shortcut API token * You can find your API token within Shortcut by navigating to :link: [Settings > Your Account > API Tokens](https://app.shortcut.com/settings/account/api-tokens) * Click **Save**; you’ll be presented with a dialog in which you can select projects to pull stories from ### Add feature affiliations * Specify labels that Runway should look for to associate stories with specific releases * Pattern is tokenized with the release version, *e.g.* `ios-{version}` # CI/CD Keep up to date with the status of the latest release candidate builds as they're made available. {% hint style="info" %} The **Workflow argument** field accepts tokens like `{version}` and `{appPlatform}` as a stand-in for the release version. Read more about [allowed tokenized patterns for tags here](https://docs.runway.team/getting-started/pattern-strings-tokens). {% endhint %} # App Center Build
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect App Center Build** * Find the **App Center Build** integration module under the **CI/CD** section * Click the **Connect** button * Enter an App Center User API Token * You can generate User API Tokens within App Center by going to **Account Settings** > **User API Tokens**: * :link: [**App Center API Documentation — Creating an App Center User API Token**](https://docs.microsoft.com/en-us/appcenter/api-docs/#creating-an-app-center-user-api-token) {% hint style="warning" %} Runway requires a User API Token with Full Access. {% endhint %} * Click **Save** {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # Azure Pipelines ## ![](/files/kdCo4mqTJaw5In7Jq4BM) ## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Azure Boards** * Find the **Azure Pipelines** integration module under the **CI/CD** section * Click the **Connect** button * You’ll be taken through a standard Azure DevOps OAuth flow {% hint style="warning" %} You must be logged in to Azure DevOps with a user that has access to the organization/project you want to connect. {% endhint %} {% hint style="warning" %} Make sure the **Third-party application access via OAuth** toggle is enabled from **Organization Settings > Policies** in Azure DevOps (see below) {% endhint %}
* Azure Pipelines redirects you back to Runway, Runway presents a dialog: 1. Select the project you want to connect from the dropdown of options 2. Select your Release Candidate pipeline, and optionally dev and deploy pipelines if distinct # Bitbucket Pipelines
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Bitbucket Pipelines** * Find the **Bitbucket Pipelines** integration module under the **CI/CD** section * Click the **Connect** button * You’ll be taken through a standard Bitbucket OAuth flow * Select a specific Bitbucket Pipelines org if you’re a member of multiple (otherwise will be pre-selected) {% hint style="warning" %} You must be logged in as a Bitbucket Pipelines user with read/write permissions in the selected Bitbucket org. {% endhint %} * Bitbucket Pipelines redirects you back to Runway, you’ll be presented with a dialog in which to select your Release Candidate pipeline, and (optionally) the name of your release pipeline if different than your RC pipeline # Bitrise
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Bitrise** 1. Find the **Bitrise** integration module under the **CI/CD** section 2. Click the **Connect** button 3. Enter a Bitrise Personal Access Token 4. You can generate Personal Access Tokens within Bitrise. :link: [**Bitrise - Acquiring a Personal Access Token**](https://devcenter.bitrise.io/api/authentication/) {% hint style="info" %} If possible, select **Never** for the token expiration so you don’t have to keep regenerating tokens and reconnecting Bitrise. {% endhint %} 5. Click **Save**; you’ll be presented with a dialog in which to select your Bitrise app and your Release Candidate workflow or pipeline, and (optionally) your release workflow if different than your RC workflow {% hint style="warning" %} Due to a Bitrise API limitation, new workflows created in Bitrise will not be available to select in Runway until they have been run at least once. {% endhint %} {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # Buildkite
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Buildkite** * Find the **Buildkite** integration module under the **CI/CD** section * Click the **Connect** button * Enter a Buildkite API Access Token * You can generate API Access Tokens within Buildkite: * :link: [**Buildkite Docs - Managing API Access Tokens**](https://buildkite.com/docs/apis/managing-api-tokens) {% hint style="info" %} Runway requires an API Access Token including the following scopes: * `read_builds` * `write_builds` * `read_organizations` * `read_pipelines` * `read_artifacts` {% endhint %} * Click **Save**; you’ll be presented with a dialog in which to select your Buildkite org and your Release Candidate pipeline, and (optionally) the name of your release pipeline if different than your RC pipeline {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # CircleCI
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect CircleCI** * Find the **CircleCI** integration module under the **CI/CD** section * Click the **Connect** button * Enter a CircleCI API Token * You can generate API Tokens within CircleCI by going to **User Settings > Personal API Tokens > Create New Token** {% hint style="warning" %} A **Personal** API token is required to integrate with Runway. A **Project** API token will not work, given CircleCI limits Project tokens to their v1 API (as opposed to v2), and the v1 API lacks many endpoints required for the integration. {% endhint %} * Click **Save**; you’ll be presented with a dialog in which to enter the following: 1. Project type (GitHub), org name, and repo name 2. The name of your RC workflow 3. (Optional) The name of your release workflow, if different than your RC workflow {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # Codemagic
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### Connect Codemagic * Find the **Codemagic** integration module under the **CI/CD** section * Click the **Connect** button * Enter a Codemagic Personal Access Token * You can view your Personal Access Token within Codemagic by visiting Teams > Personal Account > Integrations. Find the **Codemagic API** item in the list, and click **Show** to reveal the key * Click **Save**; you’ll be presented with a dialog in which to select your Codemagic app and your Release Candidate workflow, and (optionally) the name of your release workflow if different than your RC workflow {% hint style="warning" %} Due to Codemagic API limitations, there are a couple of scenarios in which Runway will not have access to your workflow data: 1. If you have not yet triggered a build at least once **before** setting up Codemagic in Runway. 2. If your Codemagic apps are configured using `codemagic.yaml`instead of the Workflow Editor. For both scenarios, you'll see only a non-functional "Default Workflow" available for selection in Runway. For the second scenario, you'll need to reach out to our team to manually configure your workflow selections. Please share the workflow names and IDs when you do. {% endhint %} {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # GitHub Actions
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### Connect GitHub Actions * Find the **GitHub Actions** integration module under the **CI/CD** section * Click the **Connect** button. You’ll be taken through a standard [GitHub app](https://developer.github.com/apps/) OAuth flow. (Or, you’ll be given the option to reuse the GitHub connection you already established when setting up GitHub for version control.) * GitHub redirects you back to Runway * Select the name of your repo from the list of options * Select the name of your Release Candidate workflow from the list of options * Optionally, enter the name of your release workflow (the one that generates the builds that you end up submitting to the App Store/Play Store) if it’s different than your Release Candidate workflow * Optionally, enter the name of the deploy branch on which your release workflows are triggered, if this branch is different than the branch your Release Candidate workflow is triggered on * For any of the above workflows, you can optionally enter workflow arguments (a.k.a. "inputs" or "trigger variables") as key-value pairs. * If you enter workflow arguments, Runway will pass them in calls to the GitHub API when you trigger builds from within Runway. * Runway can also filter the builds it fetches based on workflow arguments. This can be useful if you use the same workflow for multiple different build types and the specific build type that's built is determined by one or more workflow arguments. * **Note**: because the GitHub API does not return workflow arguments in its build responses, you must inject your arguments into the workflow [run name](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#run-name). Arguments must be surrounded by whitespaces and use the notation `key=value`, e.g. `pilot=Sully` or `pilot='Sully B.'` (wrap any keys or values that contain spaces in single quotes). * Valid: `Workflow pilot=Sully age=50` * Not valid: `Workflow (pilot=Sully, age=50)` {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} ### Triggering builds from Runway In order to trigger builds from Runway, your GitHub Actions workflow will need to have `workflow_dispatch` configured. See GitHub’s [documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) for more info. # GitLab CI
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### Connect GitLab CI * Find the **GitLab CI** integration module under the **CI/CD** section * Click the **Connect** button. You’ll be taken through a standard [GitLab app](https://docs.gitlab.com/ee/integration/oauth_provider.html) OAuth flow {% hint style="warning" %} You must be logged in as a GitLab user with **admin** permissions in your selected GitLab org. {% endhint %} * GitLab redirects you back to Runway * Select a project from the dropdown of options * Select your Release Candidate pipeline, and optionally dev and deploy pipelines if distinct {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # Jenkins
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Jenkins** * Find the **Jenkins** integration module under the **CI/CD** section * Click the **Connect** button * Enter a Runway-accessible URL to your Jenkins server * Enter your Jenkins username * Enter a Jenkins API Token * You can generate API Tokens within Jenkins by going to `/user/admin/configure` and clicking **Add New Token** in the **API Token** section * Click **Save**; you’ll be presented with a dialog in which to enter the name of your deployment job/workflows * The Release Candidate workflow should be the workflow that generates your Release Candidate builds, *i.e.* the builds you use to run Regression testing * Optionally, you can also enter the name of a Release job/workflow; *i.e.* the workflow that generates the builds that you end up submitting to the App Store/Play Store {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # TravisCI ​![](/files/Siuk5At0kiX3nMy7U8vP) ## Set up ### Navigate to the Integration settings view 1. 1.Select an app in the top left corner from the Switcher 2. 2.Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect TravisCI** * Find the **TravisCI** integration module under the **CI/CD** section * Click the **Connect** button * Choose the Host URL of your TravisCI server * Enter a TravisCI API Token * You can generate API Tokens via the TravisCI command line client: * :link: [TravisCI - Authentication](https://developer.travis-ci.com/authentication) * Click **Save**; you’ll be asked for a repo slug, formatted as `/` * Click **Submit** {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # Xcode Cloud
#### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar #### Connect Xcode Cloud * Find the **Xcode Cloud** integration module under the **CI/CD** section * Click the **Connect** button * Select an existing App Store Connect installation, or enter your ASC API key’s Key ID and Issuer ID, and upload the .p8 key file * Click **Save**; you’ll be presented with a dialog in which to select your Xcode Cloud product, your Release Candidate workflow, and (optionally) the name of your release workflow if different than your RC workflow {% hint style="info" %} You can generate API keys within App Store Connect. * You must be logged into App Store Connect with an **Admin** account to generate API keys. * Runway requires an API key with the **App Manager** role. :link: [**Apple - Creating API Keys for App Store Connect API**](https://developer.apple.com/documentation/appstoreconnectapi/creating_api_keys_for_app_store_connect_api). {% endhint %} ![Issuer ID, Key ID, and download link from the Users and Access section in App Store Connect](/files/4HmfttInHWir0w8PII2w) {% hint style="info" %} Learn more about [builds and branches in Runway](/getting-started/setting-up-your-integrations/builds-and-branches). {% endhint %} # Custom CI #### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar #### Connect Custom CI * Find the **Custom CI** integration module under the **CI/CD** section * Click the **Connect** button * Complete the form by writing in the custom integration name * Click **Connect** * Start making calls to [this endpoint](https://api-docs.runway.team/#tag/app/operation/uploadCustomCIBuild) using the unique Integration ID surfaced after clicking **Connect** # Regression testing Automatically pull in status and details from regression test runs. # BrowserStack
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect BrowserStack** * Find the **BrowserStack** integration module under the **Regression testing** section * Click the **Connect** button * Enter a BrowserStack API Access Key and the associated username * You can generate a username and associated API access key in BrowserStack by going to **Settings > Product > Service Accounts** * Click **Save**; you’ll be presented with a dialog in which to select your BrowserStack project and add any test run naming keywords {% hint style="warning" %} For the release linkage, Runway will parse your test run names for the presence of a version string (e.g. “**2.3.0**”) {% endhint %} {% hint style="info" %} You can optionally add test run naming keywords (case insensitive) to associate test runs with a particular app, e.g. "iOS" or "Android" {% endhint %} For more information on how Runway will leverage BrowserStack, visit the [Regression testing step](/using-runway/release-steps/regression-testing) article. # Qase
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Qase** * Find the **Qase** integration module under the **Regression testing** section * Click the **Connect** button * Enter a Qase API token * Generate an API token in Qase by going to * Click **Save**; you’ll be presented with a dialog in which to select your Qase project and add any test run naming keywords {% hint style="warning" %} For the release linkage, Runway will parse your test run names and milestones for the presence of a version string (e.g. “**2.3.0**”) {% endhint %} {% hint style="info" %} You can optionally add test run naming keywords (case insensitive) to associate test runs with a particular app, e.g. "iOS" or "Android" {% endhint %} For more information on how Runway will leverage Qase, visit the [Regression testing step](/using-runway/release-steps/regression-testing) article. # TestRail
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect TestRail** * Find the **TestRail** integration module under the **Regression testing** section * Click the **Connect** button * Enter your TestRail instance’s base URL, including the `https://` and excluding any trailing `/` * Enter a TestRail API Key * You can generate API Keys within TestRail by going to **My Settings > API Keys > Add Key** {% hint style="danger" %} The API key creation flow in TestRail can be confusing. **Make sure you both generate**** *****and***** ****add the new API key, then click "Save Settings" (takes multiple separate clicks)**. If you refresh the main TestRail API keys page (My Settings > API Keys) and the key you created doesn't appear, you missed a click! {% endhint %} * Click **Save**; you’ll be presented with a dialog in which to select your TestRail project and add any test run naming keywords {% hint style="warning" %} For the release linkage, Runway will parse your test run names for the presence of a version string (e.g. “**2.3.0**”) {% endhint %} {% hint style="info" %} You can optionally add test run naming keywords (case insensitive) to associate test runs with a particular app, e.g. "iOS" or "Android" {% endhint %} For more information on how Runway will leverage TestRail, visit the [Regression testing step](/using-runway/release-steps/regression-testing) article. # Xray
## Set up ### Navigate to the Integration settings view 1. Select an app in the top left corner from the Switcher 2. Navigate to **App Settings** by clicking the gear icon (⚙️) at the top of the Timeline sidebar 3. Click on **Integrations** in the sidebar ### **Connect Xray** * Find the **Xray** integration module under the **Regression testing** section * Click the **Connect** button * Enter your **Client ID** and **Client Secret** * Every Xray API Key you generate will have a Client ID and Client Secret associated and displayed alongside. You can generate API Keys for Xray within Jira by going to **Settings > Apps > Xray > API Keys** (:link: [Xray Documentation - Global Settings: API Keys](https://docs.getxray.app/space/XRAYCLOUD/44568019/Global+Settings+-+API+Keys)) {% hint style="info" %} When connected, Xray API actions will be performed on behalf of the user linked to the Xray API key being used. {% endhint %} * Click **Save**; you’ll be presented with a dialog in which to add any test execution naming keywords {% hint style="warning" %} For linking test executions to specific releases, Runway will parse your test execution names for the presence of a version string (e.g. “**2.3.0**”) {% endhint %} {% hint style="info" %} You can optionally add test execution naming keywords (case insensitive) to associate test executions with a particular app, e.g. "iOS" or "Android" {% endhint %} # Beta testing Distribute and monitor release candidate builds for internal and external testing. --- [Next Page](/llms-full.txt/1)