Technologies / Delivery tooling
Mobile CI/CD that ships a tested build every sprint
Mobile CI/CD is the pipeline that turns every merged change into a signed, tested build on TestFlight and Google Play, without anyone running scripts on their laptop. It is why we can promise a demo build every two weeks, and why an urgent fix can reach users the same day it is approved rather than waiting for the one person who has the signing certificate.
The two decisions that matter are which tools to use and who controls the signing keys. It is part of the tooling in our mobile app development technologies hub and supports the process on how we work.
- Builds from your repository, not a laptop
- Signing keys held in your accounts
- Tests run before every build
- Staged releases with a rollback plan
Why mobile CI/CD is harder than web CI/CD
A web deploy replaces files on a server. A mobile release has to be compiled on the right toolchain, signed with keys tied to your developer accounts, uploaded to Apple and Google, and approved by review before users see it. Once installed, you cannot roll it back. Four things make the pipeline different:
- macOS is required for iOS. iOS builds need Xcode on a Mac, so you need Mac build machines, either hosted or your own. Since 28 April 2026, App Store uploads must be built with Xcode 26 or later.
- Code signing. iOS needs certificates and provisioning profiles; Android needs an upload key. Lose control of them and releases stop.
- Store review and tracks. Builds go to test tracks first, then production, with review in between.
- Many devices. Automated tests catch regressions, but real-device checks still matter.
Mobile CI/CD tools compared
We use all four. The right one depends on your platforms, your team and where your code already lives.
| Tool | Best fit | Cost model and limits |
|---|---|---|
| Xcode Cloud | Native iOS teams who want Apple’s own service, integrated with Xcode and App Store Connect | 25 compute hours a month included with the Apple Developer Program; paid tiers from $49.99/month for 100 hours. iOS and Apple platforms only. |
| GitHub Actions | Teams already on GitHub who want one CI system for app, backend and web | Hosted macOS runners on Apple silicon (M1, 3 CPU, 7 GB RAM) with labels such as macos-15 and macos-26; check GitHub’s current minute pricing for macOS |
| fastlane | Automating signing, screenshots, TestFlight and Play uploads inside any CI | Open source (MIT licence); free, runs on whatever machine your CI provides |
| Codemagic | Flutter, React Native, Unity, KMP and .NET MAUI projects that need iOS and Android from one config | 500 free macOS M2 minutes a month on personal accounts, then $0.095/min (M2) or $0.114/min (M4); team plans from $3,990/year |
Prices as listed on each vendor’s site when checked; confirm current pricing before you commit.
How we choose a pipeline
For a native iOS app, Xcode Cloud is the shortest path: it manages signing for you and the included hours cover a small team’s sprint builds. For a Flutter or React Native app, Codemagic or GitHub Actions builds both platforms from one workflow.
If your backend already runs on GitHub Actions, we often keep everything there so one team owns one system. In every case we use fastlane lanes for the build, sign and upload steps, so moving between CI providers later means changing the runner, not rewriting the release process.
Questions we ask first
- Native, Flutter, React Native or Unity?
- Where is the code hosted today?
- Who on your side should approve releases?
- How many builds a week do you expect?
- Do you need white-label or multi-flavour builds?
Code signing: who holds the keys
Signing is where agency relationships go wrong. If the only copy of an Android upload key or an iOS distribution certificate sits on a contractor’s laptop, you do not fully control your app. Our rule matches our wider policy that you own the code and store accounts.
iOS
Certificates and provisioning profiles are created in your Apple Developer account. We use App Store Connect API keys for CI uploads instead of personal Apple IDs, and either Xcode Cloud’s managed signing or fastlane match with an encrypted certificates repository you own.
Android
We enrol apps in Play App Signing so Google holds the app signing key, and the upload key lives in your CI secrets store with a documented backup. With Play App Signing, a lost upload key can be replaced through a request in Play Console rather than ending the app’s update path.
Every secret lives in your CI provider’s encrypted store, in your organisation, with access reviewed when people join or leave. See NDA and IP protection for how ownership is written into the contract.
Releases depend on one person’s laptop?
Tell us your stack and how you release today. Within one business day we reply with a pipeline recommendation, a plan to move signing into your accounts and a rough setup effort.
Our mobile CI/CD release flow
The pipeline behind our two-week sprints, from pull request to production.
Pull request checks
Lint, static analysis and unit tests on every pull request. Nothing merges with a red build. Our automated app testing service covers the test suite itself.
Build and sign on merge
Every merge to the main branch produces signed iOS and Android builds with an incremented build number and release notes generated from commits.
Internal testers
Builds go to TestFlight internal testers (up to 100 team members) and the Play internal testing track (up to 100 testers). Your team installs the sprint demo build from there.
Wider beta
Release candidates go to TestFlight external testers (up to 10,000; the first build in a group may need beta review) and Play closed testing lists. TestFlight builds expire after 90 days, so long betas need fresh builds.
Production with staged rollout
Submission to review, then a phased release on the App Store and a staged rollout on Google Play, watching crash-free rates before going to 100%.
Hotfix path
A release branch can be patched and shipped through the same pipeline without picking up unfinished work from main.
Release tracks and a rule new Android accounts must plan for
Google Play has internal, closed and open testing tracks. Closed testing uses email lists of up to 2,000 users each, and open testing can be unlimited. New personal Play developer accounts created after 13 November 2023 must run a closed test with at least 12 opted-in testers for 14 consecutive days before they can apply for production access, and opting out and back in restarts the count, per Google’s Play Console help. If your company publishes under a personal account, build those two weeks into the launch plan. Organisation accounts avoid this, and they suit businesses better anyway.
For launch-day steps beyond the pipeline, see our app launch checklist and app store submission services.
Hiring and maintenance implications
A pipeline is code and needs an owner. Xcode versions, runner images, fastlane and SDKs all move. Apple’s yearly Xcode requirement and Google Play’s target API deadline every 31 August both start in CI: if the build machine has the wrong toolchain, the release cannot happen. We keep pipeline configuration in your repository, document it, and update it as part of app maintenance and support.
When you hire in-house later, a working pipeline is one of the most useful things to hand over. New developers ship on their first day because building and signing are already solved.
Mobile CI/CD checklist
What a healthy pipeline looks like when we hand it over.
- Pipeline config versioned in your repository
- Builds run on hosted or owned runners, never a personal laptop
- Signing certificates, profiles and upload keys in your accounts
- App Store Connect API key used for uploads, not a personal Apple ID
- Play App Signing enabled, upload key backed up
- Unit tests and static analysis block merges on failure
- Build numbers incremented automatically
- Internal track builds every sprint; staged rollout for production
- Toolchain versions pinned and upgraded deliberately
- Crash reporting symbols uploaded for every release build
Mobile CI/CD: frequently asked questions
Do we need a Mac to build our iOS app in CI?
Yes, iOS builds require Xcode, which runs only on macOS. You do not have to buy Macs: Xcode Cloud, GitHub Actions macOS runners and Codemagic all provide hosted Apple silicon machines. Since 28 April 2026, App Store uploads must be built with Xcode 26 or later, so the build image must stay current.
Xcode Cloud, GitHub Actions or Codemagic: which should we use?
Xcode Cloud suits native iOS teams and includes 25 compute hours a month with the Apple Developer Program. GitHub Actions suits teams already on GitHub who want one CI for app and backend. Codemagic suits Flutter, React Native and Unity apps needing both platforms from one config. We use fastlane underneath so switching later is easy.
Is fastlane still needed if we use Xcode Cloud or Codemagic?
Not always, but often. Xcode Cloud handles signing and TestFlight uploads for Apple platforms itself. fastlane, which is open source under the MIT licence, adds portable lanes for screenshots, metadata, Play uploads and signing with match. It keeps your release process independent of any one CI vendor.
Who should own the signing keys?
Your company. iOS certificates and profiles belong in your Apple Developer account, and Android apps should use Play App Signing so Google holds the app signing key while the upload key sits in your CI secrets. A contractor holding the only key copy is a serious risk. We document every secret and its backup.
Why can’t our new Android app go straight to production?
If it is published from a personal Play developer account created after 13 November 2023, Google requires a closed test with at least 12 opted-in testers for 14 consecutive days before production access. Opting out and back in restarts the count. Plan it into the launch, or publish from an organisation account.
How long does it take to set up a mobile CI/CD pipeline?
For a new project, we set the pipeline up in the first sprint so the first demo build already comes out of it. For an existing app, the effort depends on the state of signing, tests and build scripts. Moving keys into your accounts usually comes first. We estimate it after reviewing your repository.
Ship every sprint without release-day drama
Book a 30-minute scoping call. We will review how you build and release today, where your signing keys live, and which pipeline fits your stack and team.