Over-the-air (OTA) releases

How to use Runway for over-the-air releases

Teams that are shipping apps built with cross-platform frameworks (like React Native or Flutter) that are also doing over-the-air releases alongside their binary releases can use Runway’s OTA platform to streamline their over-the-air release process.

Leveraging Runway for OTA releases unlocks your team’s ability to consistently ship all releases with the appropriate approvals and processes, eliminating the need for separate workflows and scripts specific to OTA releases and helping you manage dependencies between OTA and binary.

Best practices

• Workflow:

  • Have one unified workflow for the native components of the application

  • Have one workflow for the OTA component of the application

• Branching strategy:

  • We recommend version-specific release branches. If you are using a shared version sequence for native and OTA releases, we recommend the following strategy:

    • Regular binary release (v1.2.0):

      • Cut release/1.2.0 from main

    • Regular OTA release (v1.2.1)

    • Next regular OTA release (v1.2.2)

    • Hotfix release (binary) (v1.2.3)

• Tagging strategy:

  • Binary releases: v1.2.0 on the release branch when submitted to stores

  • Hotfix releases:

    • OTA: v1.2.1, v1.2.2 etc. on the release branch when OTA update is published

    • Binary: v1.2.1, v1.2.2 etc. on the release branch when submitted to stores

Setting up OTA releases in Runway

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.

Step 1: Connect the CI/CD integration within Runway

• In App settings > Integrations > CI/CD, find your team’s CI/CD tool

• Click Connect — reuse your existing CI/CD connection

• Select your repository and set your Release Candidate workflow. For the purposes of this example, the workflow is build-and-submit.yml

• Set your internal staging OTA workflow. For the purposes of this example, the workflow is ota-update.yml

Step 2: Configure steps

Runway structures OTA releases into these sequential steps:

Kickoff	Detects new OTA release via branch creation or version bump in package.json
Feature Readiness	Surfaces PRs and project management tickets associated with the release
CI (Staging)	Points to CI staging workflow
Regression Testing	Optional: connect to your team’s Regression testing provider, or create Regression Testing Items within Runway or via our Public API
Beta Testing	Optional: external beta tester tracking
Approvals	Sign-off gate before production OTA push

For teams that leverage Expo EAS for OTA releases, Runway offers a direct integration. Once the integration is connected, the following release steps appear by default in Runway:

Release	For default OTA apps, points to ota-update.yml . For OTA apps integrated with Expo EAS manage update group selection and publish to prod
Rollout	Surfaces a visual status of release health, progress of phased releases, adoption percentage, and state of rollout-related automations

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

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.

Step 3: Configure OTA Version Detection

By default Runway reads the version field from package.json. To change it:

• Go to App Settings > General

• Under "OTA Version", select the file and field to read from

Step 4: Configure ‘Create next Runway release' automation in Runway

By default Runway will create a release branch for all apps within a Flightpath. Since we recommend that you ship OTA for hotfixes only, we recommend the following:

• Go to App Settings > Automations > ‘Create next Runway release' automation

• Remove Hotfixes and Rollbacks from the default Release types section

• For Standard releases, select to create the next Runway release for the binary app(s)

• For Hotfix and Rollback releases, select to create the next Runway release for the binary app