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 viadeliver/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
endRun 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
endNow 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.