Guides9 min read

Fastlane + OtaKit: automate store builds and OTA releases together

Use Fastlane for the native store builds and OtaKit for the web-layer updates in between. How to combine both in one release lane so store submissions and live updates share a pipeline.

Fastlane is the workhorse of native mobile release automation — signing, building, and uploading to the App Store and Google Play. But most of your releases aren't native; they're web-layer changes that should ship over the air. The clean setup uses Fastlane for the native store builds and OtaKit for everything in between, in one coherent release process.

Mental model: Fastlane handles the rare, heavy native releases. OtaKit handles the frequent, light web-layer releases. Same repo, two lanes.

The division of labor

  • Fastlane — build and submit the native binary when native code changes (new plugins, permissions, Capacitor upgrades). Handles signing via match, uploads via deliver / supply.
  • OtaKit — ship the web layer (UI, logic, fixes) over the air, no signing, no store wait.

A native store lane

A minimal iOS lane that syncs the web build into the native project, then builds and uploads:

# fastlane/Fastfile
platform :ios do
  lane :release do
    sh("npm", "run", "build")
    sh("npx", "cap", "sync", "ios")
    match(type: "appstore")          # signing assets
    build_app(workspace: "ios/App/App.xcworkspace", scheme: "App")
    upload_to_app_store(skip_screenshots: true)
  end
end

Run this only when you actually change native code. When you do, bump runtimeVersion so later OTA bundles target the new shell.

An OTA lane in the same Fastfile

You can wrap the OtaKit release in a Fastlane lane too, so your team has one command surface for both kinds of release:

platform :ios do
  lane :ota do
    sh("npm", "run", "build")
    sh("otakit", "upload", "--release", "production")
  end
end

Now fastlane ota ships a live update and fastlane release cuts a native store build. The OTA lane needs no certificates — just the OTAKIT_TOKEN in the environment.

Wire it into CI

Both lanes run happily in CI. A common split: run fastlane ota on every merge to main, and fastlane release on version tags. That mirrors the GitHub Actions and GitLab patterns, with Fastlane as the shared command layer.

The payoff: your team runs one tool, but only pays the cost of a full native build when a release genuinely needs one. Most releases take the fast OTA lane.

Where to go next

See the CI automation docs and automating channel promotion for a safe beta-to-production flow.

Related docs