Getting started

To start the Quickstart CI/CD wizard, click the + icon the left navigation sidebar. Then, click "Get started" on the Quickstart CI/CD prompt.

Step 1: Connect to GitHub

After selecting a platform (Android/iOS), you’ll connect Runway to your GitHub repository using an easy OAuth flow. Connecting GitHub will allow the Quickstart wizard to scan your project files and extract all the necessary configuration details for the build-and-deploy workflow..

Step 2: Connect to App Store Connect or Play Console

Next, you’ll connect Runway to App Store Connect or Play Console. Runway uses this integration to grab additional details about your app that are needed for the workflow: things like your bundle identifier or package name, active provisioning profiles for iOS, etc.

During this step, Runway can also optionally upload the API key your workflow needs in order to talk to App Store Connect or Play Console for certain steps (like uploading your new builds to the stores). Runway uploads the keys to GitHub’s encrypted repository secrets which makes them accessible to your GitHub Actions workflows in a secure way.

Runway will upload the following secrets:

iOS

• ASC_PRIVATE_KEY: The App Store Connect API key (.p8) file used to authenticate with the App Store Connect API. This is needed for the workflow to be able to upload .ipas to App Store Connect

• ASC_KEY_ID: The identifier for the ASC API key

• ASC_ISSUER_ID: The issuer ID for the ASC API key

Android

• GPLAY_SERVICE_ACCOUNT_JSON_KEY: The service account key .json file used to authenticate with the Google Play Developer API. This is needed for the workflow to be able to upload builds to the Play Console

Step 3: Start the scan

During this step, the Quickstart CI/CD wizard scans your project files and app store records to pull key values and settings needed for the workflow’s configuration. You’ll get a chance to confirm that everything looks good with the resulting output. In some cases, Runway will surface multiple options for certain fields like build target and build type — be sure to select the option you normally use when preparing builds for app store distribution.

In some cases, the wizard maybe be unable to detect certain values. You can choose to manually fill these in, or leave them blank. Note that any configuration fields that are left blank will be added to the workflow configuration files as placeholders that you’ll need to replace to get your workflow running.

Step 4: Upload signing secrets

Next, you’ll upload the required signing certificates or keys to GitHub. As before, Runway uses GitHub’s encrypted secrets for this so everything stays secure. With these uploaded and safely stored, your workflow will be able to properly provision and sign your builds for distribution.

The wizard will always upload signing secrets directly to GitHub — your signing secrets are never stored anywhere on Runway’s servers.

While the upload secrets step is optional, these signing secrets are necessary for the workflow to be able to properly sign your builds for distribution. If you choose to skip this step, be sure to manually add these secrets to your repository GitHub secrets.

The following secrets are saved as GitHub encrypted repository secrets for each platform:

iOS

• IOS_DIST_SIGNING_KEY: The distribution signing certificate and private key pair (.p12) file used to sign builds for distribution to the App Store

• IOS_DIST_SIGNING_KEY_PASSWORD: The password associated with the distribution signing certificate and private key pair

Android

• ANDROID_KEYSTORE: The keystore file (.keystore or .jks) for the signing key used to sign your builds or your upload key used to upload builds to the Play Console

• ANDROID_KEYSTORE_PASSWORD: The password for your keystore file

• ANDROID_KEY_ALIAS: The alias for the key included in the keystore file

• ANDROID_KEY_PASSWORD: The password for the key included in the keystore file

Step 5: Generate files and open a pull request

Runway uses your configuration options to generate a GitHub Actions YAML file which defines your workflow, a fastlane Fastfile to configure and run your builds, and any additional files needed to install fastlane and set it up properly (e.g. a Ruby Gemfile). You can choose to automatically open a pull request to get these files straight into your repo, or download them instead.

Merge the files into your repository to make the new workflow available in GitHub Actions.

Step 6: Run your workflow

Once all of the files the Quickstart wizard auto-generated for you make their way into your repo (via Runway PR or manually), head over the Actions tab in your GitHub repo, find your new build-and-deploy workflow in the left hand menu, and click “Run workflow” to see it all in action!

Extending your workflow further

The generated build-and-deploy workflow is by default configured to be manually triggered from GitHub Actions by choosing a branch. But you can also include event triggers to automatically run your workflow on pushes to a specific branch. We recommend including an automatic event trigger for your workflow so that it runs on pushes to any release branches like so:

on:
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:
  # Triggers the workflow on push to release branches
  push:
    branches:
      - "releases-{**}"

You can read more about available event triggers in GitHub’s documentation.