Quick answer
Mobile CI/CD is the practice of automatically checking every code change and turning it into a signed iOS or Android build that testers or the app stores can receive. Continuous integration (CI) runs the checks; continuous delivery (CD) keeps a tested build ready to release. App Store and Google Play review still sit between a finished pipeline run and your users.
What do CI and CD mean for a mobile app?
The only working iOS signing setup lives on Marco's laptop, and Marco is on vacation the week a crash fix has to ship. Anyone can write the fix. Nobody else can produce a build Apple will accept. Mobile CI/CD moves the checks and the signed build onto machines the whole team can trigger.
Continuous integration (CI) checks each change as it merges: lint, type checks, unit tests in Jest, XCTest or JUnit, and sometimes a native compile to catch a broken Podfile or Gradle file. A useful CI failure points at one change you can fix.
Continuous delivery (CD) means you can produce a tested, signed build and send it to its destination the same way every time. A person can still decide when users get it.
Continuous deployment goes further and releases every passing change automatically. On mobile the term needs care, because App Store review and the user's choice to install sit outside your pipeline. Name jobs after what they do ("build the store build") instead of calling everything a deploy.
What does a mobile pipeline do, step by step?
A mobile pipeline is a chain of jobs, each using what an earlier job produced. Most commits only need the first two or three stages.
| Stage | Question it answers | What it produces |
|---|---|---|
| Source checks | Does the change pass lint, type checks and unit tests? | Test results and diagnostics |
| Native build | Does this commit compile into an installable iOS or Android build? | An identified build with logs |
| App testing | Does the installed build do what it should? (Detox, Espresso, Maestro or XCUITest flows) | Test results tied to that build |
| Distribution | Can testers or the store receive the build? | An upload to TestFlight, a Play Console testing track or internal distribution |
| Release | Has someone approved this exact build for users? | An approval and release record |
| Production monitoring | Is the release behaving for real users? | Crash and performance data per release |
Run cheap checks first. Lint and unit tests finish fast on Linux, while iOS builds and device tests tie up slower, scarcer machines.
Keep one build moving through every stage. If your test job checks build 412 and the release job grabs the newest build, the green test says nothing about what shipped. Pass the build ID from job to job.
Some stages need a different build of the same commit. An iOS Simulator build will not install on an iPhone. Record that your simulator build and your App Store build share a commit and configuration, then test the device build on real hardware before release.
How is mobile CI/CD different from web CI/CD?
A web team can point traffic at a new server, and the old version is gone. A mobile app stays on phones you do not control, at whatever version the user last accepted.
Code signing ties each build to your app's identity: certificates and provisioning profiles on iOS, an upload keystore on Android. Store them in CI secrets or a managed credentials service, not on one person's laptop.
A store upload is not a store approval. Apple's submission process sends the build you select to App Review. Google Play uses internal, closed, open and production tracks, and an internal testing release reaches up to 100 chosen testers. TestFlight lets you invite up to 10,000 external iOS testers before the App Store release.
Older app versions stay in production. Users update on their own schedule, so your backend has to keep serving every version still installed.
Recovery differs too. Halting a staged rollout stops new installs of a bad version, but phones that already have it keep it. Plan the replacement release and any server-side kill switch before you need them.
Do you need a Mac for iOS CI?
Yes. iOS builds need Xcode, and Xcode only runs on macOS, so any pipeline that builds an iOS app needs a Mac somewhere. It does not have to be yours. Android builds run on Linux.
Bitrise, EAS Workflows, GitHub Actions and Apple's own Xcode Cloud all run iOS builds on hosted macOS machines. A Mac mini under a desk also works, if you will keep Xcode and the signing setup current yourself.
Which CI service fits a mobile app?
The real choice is how much of the mobile toolchain you want to maintain. General-purpose CI such as GitHub Actions or CircleCI means more control and more upkeep; mobile-focused services such as Codemagic arrive with the iOS and Android setup done. fastlane scripts signing and uploads inside any of them.
| Service | What it is | Best for |
|---|---|---|
| Bitrise | Mobile-focused CI/CD on dedicated Apple silicon machines | Teams that want a hosted CI built around iOS and Android |
| CircleCI | General-purpose CI/CD | Teams that already run CircleCI for their backend |
| Codemagic | Mobile CI/CD for Flutter, React Native, native iOS and Android, Ionic and Unity | Teams shipping apps in more than one framework, Flutter included |
| EAS Workflows | CI/CD for Expo and React Native apps, with ready-made build, submit, update and Maestro test jobs (Maestro jobs are in alpha) | React Native and Expo projects that want builds, store submissions and OTA updates in one pipeline |
| GitHub Actions | General-purpose CI built into GitHub, with hosted macOS runners | Teams that want CI next to their code and can maintain the Xcode and Android setup |
| Xcode Cloud | Apple's CI/CD service built into Xcode, works with TestFlight | Native apps that only target Apple platforms |
What should run automatically, and what needs a person?
Automating a task and approving it for production are separate decisions. Keep the release destination explicit in each workflow file, and do not hand production credentials to a pull request job because its tests need network access.
An approval should name a build the reviewer can identify, such as build 412 from commit a1b2c3d. If a later job rebuilds or swaps the build, the approval no longer covers what ships.
Review workflow changes like code. An AI coding agent such as Claude Code, Codex, Cursor or GitHub Copilot that edits a feature and the CI config in one pull request can change what the pipeline checks.
Judge the pipeline itself by the time from push to the first failure you can act on, and by how often runs fail for infrastructure reasons such as an expired certificate. A fast green run that checks little is worth little.
Where Expo fits
EAS Workflows is Expo's CI/CD service for React Native and Expo apps. Jobs live in YAML files under .eas/workflows/ and run on EAS-hosted macOS and Linux workers, so you never install Xcode on a CI machine. Pre-packaged jobs cover EAS Build, store submission, TestFlight, EAS Update and Maestro tests (the Maestro job is in alpha).
For a project already configured with a production build profile and signing credentials, a manually started build-only workflow looks like this:
Save it as .eas/workflows/build-candidate.yml and run:
The getting-started guide lists the prerequisites. To send that same build to Google Play once your store credentials are set up, add a submit job that takes the build's build_id output:
You can also keep your current CI, such as GitHub Actions or CircleCI, and trigger EAS Build from it with eas build --non-interactive and an EXPO_TOKEN secret.
Limitations
A workflow only proves what you configured it to check, and it cannot guarantee store approval. JavaScript updates shipped with EAS Update need their own compatibility checks and release policy.
EAS Workflows does not support matrix builds or shared workflow configuration yet. Pipelines that depend on Docker, custom runners or other non-EAS services are a case where Expo's docs point you to a general-purpose CI such as GitHub Actions or CircleCI.
Next step
Follow the EAS Workflows getting-started guide to make one build you already run by hand repeatable, before you automate the path to the public stores.
Verified on 12 September 2026.