CI/CD on mobile is structurally harder than on web. On web, you push code, tests run in a browser, and the deploy is instant. On mobile, you push code, the build requires platform-specific toolchains (Xcode for iOS, Gradle for Android), code signing needs certificates and provisioning profiles, tests need real devices or emulators, and deployment means uploading to an app store and waiting for review.
CircleCI's mobile CI/CD guide puts it clearly: "Mobile CI/CD is significantly more complex than web or backend CI/CD." The reasons are specific: mobile requires macOS-based build environments for iOS, device fragmentation demands testing across dozens of configurations, and app store submission rules mean you can't just rollback a bad release the way you can on web.
This guide covers the 5 stages of a mobile CI/CD pipeline, what tests run at each stage, which tools handle which part, and where real-device testing fits in.
Why mobile CI/CD is different from web
Five things make mobile pipelines harder to build and maintain.
Platform-specific build environments. iOS builds require macOS with Xcode. Android builds require the Android SDK and Gradle. You can't build an iOS app on a Linux CI runner. If you use GitHub Actions, you need macos-latest runners for iOS (which are slower and more expensive than Linux runners). Bitrise and Appcircle exist specifically because generic CI tools handle mobile builds poorly.
Code signing. Every iOS build needs a signing certificate and provisioning profile. Every Android release build needs a keystore. Managing these credentials across a team and CI environment is where most first-time mobile CI setups fail. Fastlane's match solves iOS signing by storing certificates in a private Git repo, but it requires initial setup and certificate revocation.
Device fragmentation. On web, you test on 3-4 browsers. On mobile, you need to cover Samsung (One UI), Pixel (stock Android), budget devices (3-4 GB RAM), and iPhone. Emulators catch some bugs. OEM-specific issues only surface on real devices.
App store review gates. A web deploy goes live in seconds. A mobile deploy requires App Store Connect or Google Play Console submission, review (hours to days), and gradual rollout. You can't hotfix a production bug by pushing a commit. You submit a new build and wait.
Binary distribution. Web apps serve HTML/JS from a CDN. Mobile apps are compiled binaries (.ipa, .apk, .aab) that need to be installed on each device. Testing a new build means distributing it via TestFlight, Firebase App Distribution, Google Play internal testing, or sideloading.
The 5 stages of a mobile CI/CD pipeline
Stage 1: build
The CI server compiles the app. For iOS: xcodebuild or Fastlane's gym. For Android: ./gradlew assembleRelease or ./gradlew bundleRelease (for AAB). For Flutter: flutter build apk or flutter build ios. For React Native: the platform-specific build commands underneath.
Code signing happens here. iOS builds are signed with the distribution certificate. Android builds are signed with the release keystore. If signing fails, the entire pipeline stops.
What can go wrong: Xcode version mismatch (your CI uses Xcode 15, your project needs Xcode 16), missing provisioning profiles, expired certificates, Gradle dependency download failures, and Flutter version conflicts. These are the most common mobile CI failures and they have nothing to do with your app's code.
Stage 2: unit and lint tests
Immediately after the build compiles, run unit tests and static analysis. These are fast (seconds to minutes) and catch logic errors before anything heavier runs.
For iOS: fastlane scan or xcodebuild test. For Android: ./gradlew test. For Flutter: flutter test. For React Native: npx jest.
Lint and type checks (ESLint, TypeScript, SwiftLint, ktlint) also run here. These catch formatting errors, unused imports, and type mismatches before the team reviews the code.
Pipeline gate: If unit tests or lint fail, the build is rejected. No further stages run.
Stage 3: smoke and regression tests on emulators
Once unit tests pass, run smoke tests on an emulator or simulator. Smoke tests check that the app launches, login works, and the main screens load. This takes 2-3 minutes.
If smoke passes, run selective regression covering the modules affected by the current change. On Android, this might use Espresso with an emulator. On iOS, XCUITest with the iOS Simulator.
Pipeline gate: If smoke fails, the build is rejected immediately. If regression fails, the PR is blocked until the failure is investigated.
What this stage misses: OEM-specific bugs, real GPU rendering, manufacturer popups, budget-device performance. Emulators run stock Android and can't reproduce these. That's what Stage 4 is for.
Stage 4: real-device testing
This is the stage most mobile pipelines skip, and it's the stage that catches the bugs users actually report.
Upload the build artifact (.apk or .ipa) to a real-device testing platform. Run the full regression suite across the device matrix: Samsung, Pixel, Xiaomi, iPhone, budget device. Run performance benchmarks on the budget device (cold start time, memory usage).
Drizz fits here. The pipeline uploads the APK via Drizz's REST API (POST /apk/upload), triggers the test plan (POST /testplan/run), and waits for results. Tests are plain English, Vision AI executes them on real devices, and the popup agent handles OEM dialogs. Self-healing adapts to UI changes between builds.
Pipeline gate: If real-device tests fail, the build doesn't proceed to distribution. The developer gets screenshots and failure reasoning for every failing step, on every device.
Stage 5: distribution and deployment
Once all tests pass, distribute the build.
Beta distribution: Upload to TestFlight (iOS) or Google Play internal testing (Android) for human beta testers. Or use Firebase App Distribution for both platforms. For Fastlane setup, see our fastlane tutorial.
Production deployment: Promote the build from beta to production in App Store Connect or Google Play Console. Use staged rollouts (10% → 50% → 100%) to catch production issues early.
Post-deployment: Monitor crash-free rates with Crashlytics or Sentry. Set alerts for when the rate drops below 99.5%. If a regression surfaces in production, write a test for it and add it to the Stage 4 suite.
The complete pipeline flow
Code commit
CI tools for mobile: which one fits
GitHub Actions. Works for both platforms but iOS builds need macos-latest runners (2-3x slower than Linux). Good for teams already on GitHub who don't want a separate CI service. Free tier: 2,000 minutes/month (macOS minutes count at 10x).
Jenkins. Self-hosted, fully customizable, free. Requires you to provision and maintain your own macOS build agents for iOS. Best for teams with existing Jenkins infrastructure and a dedicated DevOps engineer.
Bitrise. Built specifically for mobile CI/CD. Native support for iOS and Android builds, code signing management, and device testing integrations. Free tier: 1 concurrent build, 30 min/build. Paid plans from $89/month.
Fastlane. Not a CI server. Fastlane is a build and deployment automation tool that runs inside any CI. It handles code signing (match), building (gym/gradle), testing (scan), and deploying (pilot/supply). Most mobile CI pipelines use Fastlane inside GitHub Actions, Jenkins, or Bitrise.
Appcircle. Mobile-specific CI/CD with drag-and-drop pipeline configuration. No YAML needed. Handles Apple certificate and profile management automatically. Growing adoption in enterprise mobile teams.
The CI tool handles Stages 1-3. For Stage 4 (real-device testing), integrate Drizz's API into whichever CI you use. The API accepts an APK upload, triggers a test plan, and returns structured pass/fail results that your pipeline can gate on. Casey Nguyen, an Engineering Manager, described the integration: "Drizz felt genuinely plug-and-play. We didn't have to fight setup or spend days wiring things together."
FAQ
What is mobile CI/CD?
It's the practice of automating mobile app builds, tests, and deployments through a pipeline. Code changes trigger automated builds, tests run across devices, and passing builds are distributed to testers or app stores without manual intervention.
Why is mobile CI/CD harder than web CI/CD?
Five reasons: iOS builds need macOS, code signing requires certificate management, device fragmentation demands multi-device testing, app stores impose review gates, and mobile apps are compiled binaries that need installation on each device.
Which CI tool is best for mobile?
Bitrise and Appcircle are built specifically for mobile. GitHub Actions works if your team is already on GitHub. Jenkins works if you have DevOps resources to maintain it. Most teams use Fastlane inside their CI for build/deploy automation.
How do I add real-device testing to my CI/CD pipeline?
Add a stage after emulator-based tests that uploads the build to a real-device platform (Drizz, BrowserStack) and triggers tests via API. Gate the pipeline on the results. If real-device tests fail, the build doesn't proceed to distribution.
How long should a mobile CI/CD pipeline take?
Build: 3-10 minutes. Unit tests: 1-3 minutes. Smoke on emulators: 2-3 minutes. Real-device regression: 15-30 minutes. Total: 20-45 minutes for a full pipeline. Smoke-only pipelines (no full regression) can run in under 10 minutes.
Can I use the same CI/CD pipeline for Android and iOS?
The build and signing stages differ (Xcode vs Gradle, certificates vs keystores). The testing and distribution stages can share logic if your tests are cross-platform (Drizz tests run the same plain-English steps on both Android and iOS).
