CI/CD for Mobile Testing (Android + iOS, 2026)

Mobile CI/CD looks like web CI/CD at a distance and nothing like it up close. Builds are slower. Emulators are flakier. Signing is specific. Distribution pipelines are bespoke. This guide covers the m

Mobile CI/CD looks like web CI/CD at a distance and nothing like it up close. Builds are slower. Emulators are flakier. Signing is specific. Distribution pipelines are bespoke. This guide covers the mobile CI/CD patterns that work at scale and the pitfalls to avoid.

The mobile CI pipeline

Typical stages for a release build:

1. Lint (code style, a11y, security)
2. Unit tests
3. Build (debug + release)
4. Instrumented tests (emulator or device farm)
5. UI tests (same)
6. Security scan (APK / IPA static analysis)
7. Distribute to internal testers (Firebase App Distribution, TestFlight)
8. Ship to store (Play Console, App Store Connect)

Each stage can be 30 seconds to 30 minutes. Total: 45 minutes to 2 hours for a full pipeline.

Runners

GitHub Actions

• macos-latest — required for iOS; slow, expensive
• ubuntu-latest — fine for Android
• android-emulator-runner — reusable action for spinning emulators

Bitrise

Mobile-specific, good UX, good iOS support. Pricier per minute.

CircleCI

General-purpose, decent mobile support via macOS runners.

Self-hosted

Mac minis in a rack, Android emulators on Linux servers. Cheaper long-term, operational overhead.

Caching

Mobile builds benefit hugely from caching:

• Gradle cache (Android)
• Cocoapods cache (iOS)
• Swift Package Manager cache
• NDK / SDK downloads
• Emulator AVD snapshot

A cold build takes 10+ minutes. Cached, 2-3 minutes. Cache hit ratio is the difference between a tolerable pipeline and an intolerable one.

Emulator vs device

Emulator

• Cheaper
• Faster startup (with snapshots)
• Reproducible
• Missing real-world conditions (GPS, battery, sensors)
• Different from real devices in subtle ways

Real devices via cloud (Sauce, BrowserStack, Firebase Test Lab, SUSA with remote agent)

• Representative
• More expensive
• Slower
• Can test hardware (biometric, camera, GPS)

Use emulators for per-PR fast checks, real devices for release candidate validation.

Signing

Android

• Upload keystore handled by Play App Signing (recommended) — store upload key in CI
• Keystore in encrypted file in repo or CI secret store
• Gradle signingConfig pulls from env

iOS

• Provisioning profiles, distribution certs
• Fastlane match is the canonical approach — profiles stored in a private git repo, decrypted in CI
• Apple notarization for macOS apps

Flakiness management

Flaky mobile tests are the norm. Strategies:

• Retry failed tests once (not more; encourages real fixes)
• Quarantine flaky tests in a separate job
• Dashboard tracking flake rate over time
• Block merges on net-new flaky tests

Build variants

Most apps have: debug, staging, release (or more). Each variant:

• Different backend URLs
• Different API keys
• Different feature flags
• Different signing configs

Wire these into gradle flavors / Xcode schemes. Do not branch the codebase per environment.

Release pipeline

Play Console (Android)

• Internal testing track for employees (minutes to go live)
• Closed alpha / beta for external testers (hours to go live)
• Open beta for public opt-in
• Production with staged rollout (1% → 5% → 25% → 100%)

Rollback = halt staged rollout, ship a new version.

App Store Connect (iOS)

• TestFlight internal (up to 100 testers, immediate)
• TestFlight external (up to 10,000, review required)
• Production release (review required, 24-48 hours typical)
• Phased release (7-day automatic ramp)

Rollback = new version with the revert; no native revert.

SUSA in the pipeline

SUSA runs on every PR (quick exploration, basic issues) and every release candidate (full exploration, all personas).

Per-PR (quick)

- run: susatest-agent test app.apk --persona curious --steps 50 --format junit-xml
- uses: actions/upload-artifact@v3
  with: {name: susa-junit, path: results/junit.xml}

JUnit output lets GitHub show per-test status.

Per-release (full)

- run: susatest-agent test app.apk --persona curious --steps 200
- run: susatest-agent test app.apk --persona impatient --steps 200
- run: susatest-agent test app.apk --persona accessibility_user --steps 200
- run: susatest-agent test app.apk --persona adversarial --steps 200 --security-depth full

Four personas catch different bug classes. Total time with parallel runners: 30-40 minutes.

Regression from generated scripts

SUSA exports Appium and Playwright scripts from each exploration. Commit them. Run them in CI via appium-test.yml (Android) or playwright-test.yml (web) on every PR:

- run: pytest results/scripts/ --maxfail=5

The regression suite grows organically as SUSA discovers more surface.

Distribution automation

Fastlane is the standard:

• fastlane match — signing
• fastlane deliver — App Store metadata
• fastlane supply — Play Store metadata
• fastlane pilot — TestFlight
• fastlane screengrab — screenshot automation

A release becomes: tag → CI builds → tests pass → fastlane uploads → fastlane promotes.

Common failures

1. Emulator hangs — retry, bump timeout. If persistent, different emulator image.
2. Signing mismatch — ensure keystore / profile versions match build
3. Flaky test blocking merge — quarantine, fix separately, unblock team
4. Slow pipeline — audit cache hit rates, parallelize independent stages
5. No feedback on failure — pipeline should post specific error to PR, not "failed"

Mobile CI/CD pays off steeply. A team that ships daily and catches bugs pre-production is fundamentally different from one shipping monthly and catching bugs post. Invest the time — it compounds.