> For the complete documentation index, see [llms.txt](https://docs.runway.team/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.runway.team/using-runway/over-the-air-ota-releases.md).

# Over-the-air (OTA) releases

<figure><img src="/files/WdYlnniSbiDtrLg0qrBo" alt=""><figcaption></figcaption></figure>

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.&#x20;

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.&#x20;

## 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:**&#x20;
  * 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:**&#x20;
  * Binary releases: v1.2.0 on the release branch when submitted to stores
  * Hotfix releases:&#x20;
    * 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&#x20;

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.&#x20;

### **Step 1: Connect the CI/CD integration within Runway**&#x20;

* 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**&#x20;

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](/integrations/app-stores/expo-eas.md). Once the integration is connected, the following release steps appear by default in Runway:&#x20;

| 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:&#x20;

| 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 %}

### **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**&#x20;

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:&#x20;

* Go to App Settings > Automations > ‘Create next Runway release' automation
* Remove Hotfixes and Rollbacks from the default Release types section&#x20;
* For Standard releases, select to create the next Runway release for the binary app(s)&#x20;
* For Hotfix and Rollback releases, select to create the next Runway release for the binary app