Production-grade guide to mobile ci cd pipeline covering architecture patterns, implementation strategies, testing approaches, and operational best practices for enterprise engineering teams.
A Mobile CI/CD Pipeline automates building, testing, and deploying mobile applications across iOS and Android, ensuring every code change reaches users with consistent quality and minimal manual effort. It matters most when teams ship multiple times per day, maintain multiple app variants (e.g., free, pro, internal), and must validate across device types, OS versions, and build configurations.
The first step in any mobile CI/CD pipeline is building platform-specific binaries from source code. This includes compiling code, packaging assets, and producing deployable artifacts such as .ipa (iOS) and .apk (Android).
xcodebuild -workspace MyApp.xcworkspace \
-scheme Release \
-configuration Release \
-destination 'generic/platform=iOS' \
-archivePath ./build/MyApp.xcarchive \
-derivedDataPath ./build/derivedData \
-parallelizeTargets \
-enableCodeCoverage \
clean build archiveThis command produces a .xcarchive bundle containing the compiled app, symbol files, and documentation. The derivedDataPath ensures incremental builds are reused across runs. The parallelizeTargets flag reduces build time by executing independent build targets in parallel, but requires a sufficiently powerful CI runner.
To export the .ipa from the archive:
xcodebuild -exportArchive \
-archivePath ./build/MyApp.xcarchive \
-exportPath ./build/outputs \
-exportOptionsPlist ./exportOptions.plist \
-allowProvisioningUpdatesThe exportOptions.plist file must define the export method (development, app-store, ad-hoc, enterprise), team ID, provisioning profile, and signing identity:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>method</key>
<string>app-store</string>
<key>provisioningProfiles</key>
<dict>
<key>com.example.myapp</key>
<string>AppStore-MyApp</string>
</dict>
<key>signingIdentity</key>
<string>iPhone Distribution: Example Inc. (ABC123XYZ)</string>
<key>compileBitcode</key>
<true/>
<key>uploadBitcode</key>
<true/>
</dict>
</plist>Failure mode: missing or mismatched provisioningProfiles keys cause export to fail silently. The build succeeds but the .ipa is invalid on devices due to mismatched bundle IDs or expired certificates.
./gradlew assembleRelease \
-PbuildConfig=prod \
-PminifyEnabled=true \
-PshrinkResources=true \
--build-cache \
--configure-on-demand \
--parallelThis command assembles the release APK with ProGuard/R8 shrinking, minification, and build caching. The buildConfig property sets BuildConfig.DEBUG = false and injects production values.
In build.gradle (project-level), define the signing configuration:
android {
signingConfigs {
release {
storeFile file('keystore.jks')
storePassword 'strongPassword'
keyAlias 'myapp-release-key'
keyPassword 'strongKeyPassword'
}
}
buildTypes {
release {
signingConfig signingConfigs.release
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
versionNameSuffix '-release'
}
}
}The --build-cache flag stores compiled artifacts across runs, but fails silently if the cache is corrupted or the build-cache directory is not mounted in CI.
After building, the pipeline runs a suite of tests: unit, integration, and end-to-end, often on emulators and physical devices.
Run tests in a dedicated CI job:
./gradlew test \
--tests "com.example.myapp.*" \
--info \
--continue \
--parallelThe --continue flag ensures all test classes run even if one fails, and --parallel executes test suites concurrently.
For iOS, use xctest:
xctest --workDirectory ./build/xctest \
--testPlan TestPlan.xctestplan \
--resultsDirectory ./build/test-results \
--codeCoverage \
--testTimeout 60The TestPlan.xctestplan is a serialized .xctestplan file that defines which test classes to run, their order, and environment variables. Missing or malformed test plans result in a xctest failure with Test plan not found but no additional detail.
Appium runs tests against real or emulated devices using WebDriver protocol. The test suite is written in JavaScript, Python, or Java.
Example Appium test in Python:
from appium import webdriver
desired_caps = {
'platformName': 'iOS',
'platformVersion': '16.4',
'deviceName': 'iPhone 14',
'app': '/path/to/MyApp.ipa',
'automationName': 'XCUITest',
'newCommandTimeout': 300,
'autoAcceptAlerts': True,
}
driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)
try:
driver.find_element('id', 'login-button').click()
driver.find_element('id', 'username').send_keys('[email protected]')
driver.find_element('id', 'password').send_keys('password123')
driver.find_element('id', 'submit').click()
assert driver.find_element('id', 'welcome-message').text == 'Welcome, [email protected]'
finally:
driver.quit()The newCommandTimeout ensures the test process doesn’t time out during long operations. autoAcceptAlerts handles modal dialogs without explicit handling.
Failure mode: Could not start app: Failed to launch app when the .ipa path is incorrect or the app requires a specific provisioning profile not included in the .ipa.
Once builds and tests pass, the pipeline deploys to staging, beta, and production channels.
Use altool to upload .ipa files to App Store Connect:
altool --uploadApp \
--file ./build/outputs/MyApp.ipa \
--username '[email protected]' \
--password 'appstore-password' \
--outputPath ./build/upload-results.xmlThe --outputPath captures the response from App Store Connect. A common failure is Invalid or missing provisioning profile, which appears only in the XML output but is not echoed to stdout.
After upload, create a new version:
curl -X POST https://itunesconnect.apple.com/Services/WebService/1.0/ITCService.svc/submitVersion \
-H 'Content-Type: application/json' \
-d '{
"version": "1.2.3",
"buildNumber": "123",
"releaseNotes": "Fix crash on login.",
"appID": "123456789",
"submitter": "[email protected]"
}'The submitVersion endpoint requires appID (the app’s internal iTunes Connect ID) and buildNumber (the unique build number from Xcode). Incorrect buildNumber leads to version updates being applied to the wrong build.
Upload an APK or App Bundle to Google Play using gcloud CLI:
gcloud android app-bundle upload \
--app-bundle-path ./build/outputs/app-release.aab \
--track=beta \
--release-notes-file=./release-notes.txt \
--version-code=123 \
--package-name=com.example.myappThe --track can be internal, beta, alpha, or production. The --release-notes-file contains release notes that appear in the Play Store.
Failure mode: Version code 123 already exists in track beta — the pipeline uploaded a new build but failed to update the track because the version code was already present. The --version-code must be incremented on each release.
Mobile CI/CD pipelines rely on consistent configuration across environments. Artifacts are stored in artifact repositories, and configuration is managed through versioned files.
Build artifacts are stored in Amazon S3 using aws s3 cp:
aws s3 cp ./build/outputs/MyApp.ipa \
s3://artifacts.company.com/mobile/ios/MyApp/1.2.3/MyApp.ipa \
--cache-control 'max-age=31536000' \
--content-type 'application/octet-stream'The --cache-control header enables browser and CDN caching. The --content-type ensures proper MIME type handling on download.
Configuration for builds and deployments is stored in versioned JSON files:
{
"build": {
"ios": {
"scheme": "Release",
"configuration": "Release",
"destination": "generic/platform=iOS"
},
"android": {
"buildType": "release",
"minify": true,
"proguard": true
}
},
"test": {
"appium": {
"host": "localhost",
"port": 4723,
"timeout": 600
}
},
"deploy": {
"ios": {
"appStore": {
"track": "beta",
"releaseNotes": "Release notes for version 1.2.3"
}
},
"android": {
"playStore": {
"track": "beta",
"releaseNotesFile": "release-notes.txt"
}
}
}
}This config.json file is consumed by CI scripts via jq:
export VERSION=$(jq -r '.build.ios.version' config.json)
export BUILD_TYPE=$(jq -r '.build.android.buildType' config.json)
echo "Building version $VERSION with $BUILD_TYPE"Failure mode: jq: error: Could not open file config.json — the file is missing or the working directory is incorrect. The config.json must be checked into the repository and copied into the CI runner.
The full pipeline is orchestrated using GitHub Actions, defined in .github/workflows/build-deploy.yml.
name: Build and Deploy Mobile App
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build-ios:
runs-on: macos-latest
steps:
- uses: actions/checkout@v4
- name: Build iOS
run: |
xcodebuild -workspace MyApp.xcworkspace \
-scheme Release \
-configuration Release \
-destination 'generic/platform=iOS' \
-archivePath ./build/MyApp.xcarchive \
-derivedDataPath ./build/derivedData \
-parallelizeTargets \
clean build archive
xcodebuild -exportArchive \
-archivePath ./build/MyApp.xcarchive \
-exportPath ./build/outputs \
-exportOptionsPlist ./exportOptions.plist \
-allowProvisioningUpdates
- name: Upload iOS Artifact
uses: actions/upload-artifact@v3
with:
name: ios-build
path: build/outputs/MyApp.ipa
build-android:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Android
run: |
./gradlew assembleRelease \
-PbuildConfig=prod \
-PminifyEnabled=true \
--build-cache \
--configure-on-demand \
--parallel
- name: Upload Android Artifact
uses: actions/upload-artifact@v3
with:
name: android-build
path: app/build/outputs/apk/release/app-release.apk
test:
runs-on: ubuntu-latest
needs: [build-ios, build-android]
steps:
- uses: actions/checkout@v4
- name: Setup Appium
run: |
npm install -g appium
appium --port 4723 --log-level debug &
- name: Run E2E Tests
run: |
python tests/e2e/test_login.py
- name: Upload Test Results
uses: actions/upload-artifact@v3
with:
name: test-results
path: test-results/
deploy:
runs-on: ubuntu-latest
needs: [test]
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- name: Download iOS Artifact
uses: actions/download-artifact@v3
with:
name: ios-build
path: build/ios
- name: Upload to App Store
run: |
altool --uploadApp \
--file build/ios/MyApp.ipa \
--username '[email protected]' \
--password 'appstore-password'
- name: Download Android Artifact
uses: actions/download-artifact@v3
with:
name: android-build
path: build/android
- name: Upload to Play Store
run: |
gcloud android app-bundle upload \
--app-bundle-path build/android/app-release.aab \
--track=beta \
--version-code=123 \
--package-name=com.example.myappThe needs and if conditions ensure that deployment only runs on main branch pushes. The download-artifact step pulls the .ipa and .apk from earlier jobs.
Failure mode: Error: No such file or directory: build/ios/MyApp.ipa — the artifact was not uploaded in the correct path. The pipeline assumes the upload path is build/outputs/MyApp.ipa, but the upload-artifact step expects MyApp.ipa at the root of the artifact.
exportOptions.plist: App Store exports fail silently if provisioningProfiles keys don’t match the app’s bundle ID.--build-cache does not speed up builds due to stale or corrupted cache files.Could not start app due to missing app directory in the .ipa bundle.versionCode is not incremented correctly.jq fails to parse config.json because the file is not in the expected directory.altool command outputs XML but the CI logs only show Upload succeeded with no details.These patterns, commands, and configurations define a Mobile CI/CD Pipeline: a repeatable, automated, and testable flow from code commit to user delivery.
This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy