Flightpaths
Flightpaths enables you to set up all of your apps in one place to manage their releases as a cohesive unit. This helps provide a clearer understanding of the status of all apps that are going through the release process in tandem. Additionally, you will 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 all apps.
The following scenarios are the 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.
Runway currently supports multiple instances of Release candidate, Beta testing, Regression testing, Screenshots, Metadata, App submission, App store review, App store Release, and Rollout steps within one Flightpaths workflow.
Step configuration: a unique configuration for a step within a Flightpaths workflow of a specific archetype.
Flightpaths workflow: a collection of step configurations and settings describing your team’s process for releasing one or more apps.
Explaining Flightpaths with an example
Appollo 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. Appollo leverages the same CI workflow to build its release candidates. During beta testing, Apollo typically goes through both alpha and beta testing before the apps progress to the next step in the release process.
In this scenario, Appollo would have the following Flightpaths workflow setup:
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
Alpha - 2 steps to test iOS & Android apps
Beta - 2 steps to test iOS & Android apps
Screenshots
2 steps
iOS app connected to App Store Connect
Android app connected to Google Play Console
Metadata
2 steps
iOS app connected to App Store Connect
Android app connected to Google Play Console
Approvals
1 step for iOS & Android apps
App submission
2 steps
iOS app submits to App Store Connect
Android app submits to Google Play Console
App store review
2 steps
iOS app reviewed in App Store Connect
Android app reviewed in Google Play Console
Release
2 steps
iOS app releases in App Store Connect
Android app releases in Google Play Console
Last updated
Was this helpful?