CI/CD for Mobile Apps with GitLab CI – Setup & Automation

CI/CD for Mobile Apps with GitLab CI – Build, Test & Deploy Automatically

Manual builds and deployments are a constant source of errors and wasted time. Statistics show up to 30% of development time goes into manual build and deploy operations. GitLab CI automates everything: every commit triggers a build, tests, and delivery to the stores. We've been setting up CI/CD end-to-end for over 5 years, ensuring stability and ongoing support. We'll assess your project in one day—just contact us.

GitLab CI is the optimal choice for teams already hosting their repository on GitLab (self-hosted or cloud). Configuration lives in .gitlab-ci.yml, and runners can be GitLab-managed or your own. For iOS builds you need a registered macOS self-hosted runner: standard GitLab SaaS plans only provide Linux/Windows runners. Compared to Jenkins, GitLab CI is simpler to set up—no separate server required—and comes with built-in registry, artifacts, and environments.

Problems Solved by GitLab CI

• Manual builds and signing lead to errors from mismatched profiles or forgotten certificates.
• No automated tests mean regressions slip into production.
• Slow store delivery—each release takes hours of manual work.
• Builds are not reproducible—local environments differ.
• Missing version control on artifacts makes rollbacks difficult.

GitLab CI solves all of these: builds are repeatable, tests run on every MR, and artifacts are tied to commits. In our experience, automation cuts release time by 40%.

Why a Self-Hosted macOS Runner Is Critical for iOS

Standard GitLab SaaS runners don't provide macOS, so iOS builds must use your own Mac. Registering a runner:

# On a Mac mini or MacBook that will be the CI machine brew install gitlab-runner gitlab-runner register \ --url https://gitlab.com \ --registration-token $RUNNER_TOKEN \ --executor shell \ --description "macos-m2-runner" gitlab-runner start 

executor shell – the runner executes commands directly in the shell, without a Docker container. For iOS this is the only realistic option because Xcode doesn't work inside Docker.

Important: the runner must run as a LaunchDaemon, not as a user process, otherwise CI stops after a reboot. Configure it with sudo gitlab-runner install --user runner. We use a Mac Mini M2 with 16 GB RAM—enough for parallel builds of two configurations. We guarantee 99.9% uptime.

Sample .gitlab-ci.yml for iOS + Android

stages: - test - build - distribute variables: FASTLANE_SKIP_UPDATE_CHECK: "true" BUNDLE_PATH: vendor/bundle .ios_job: tags: - macos-m2 before_script: - bundle install --path $BUNDLE_PATH .android_job: image: androidsdk/android-34 tags: - linux-docker ios:test: extends: .ios_job stage: test script: - bundle exec fastlane test artifacts: reports: junit: fastlane/test_output/report.junit paths: - fastlane/test_output/ expire_in: 1 week rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - if: $CI_COMMIT_BRANCH == "main" ios:beta: extends: .ios_job stage: distribute script: - bundle exec fastlane beta environment: name: beta rules: - if: $CI_COMMIT_BRANCH == "main" needs: [ios:test] android:build: extends: .android_job stage: build script: - ./gradlew test assembleRelease cache: key: $CI_COMMIT_REF_SLUG paths: - .gradle/ - vendor/bundle artifacts: paths: - app/build/outputs/apk/release/ expire_in: 3 days 

Comparison of iOS and Android stages:

Code Signing Without Key Leakage

GitLab stores secrets in Settings → CI/CD → Variables. For iOS code signing we use:

before_script: - echo "$MATCH_KEYSTORE" | base64 -d > /tmp/match.keystore - bundle exec fastlane match adhoc --readonly true - echo "$ASC_API_KEY" > /tmp/AuthKey.p8 - export APP_STORE_CONNECT_API_KEY_PATH=/tmp/AuthKey.p8 

MATCH_KEYSTORE and MATCH_PASSWORD are masked variables in GitLab. Masked variables won't appear in logs even with echo. According to GitLab documentation, this approach prevents leakage.

For App Store Connect API Key—use a File-type variable with the .p8 file. With Fastlane match you can automatically update provisioning profiles when devices change or new developers are added.

Caching to Speed Up Builds

GitLab CI cache is key-bound. For CocoaPods:

cache: key: files: - Podfile.lock paths: - Pods/ - vendor/bundle 

Cache key based on Podfile.lock automatically invalidates when dependencies change. For Gradle use *.gradle* keys. This reduces build time by 40–60%.

Environments and Branch-Based Deployment

ios:staging: stage: distribute script: - bundle exec fastlane beta environment: name: staging rules: - if: $CI_COMMIT_BRANCH == "develop" ios:production: stage: distribute script: - bundle exec fastlane release environment: name: production rules: - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/ when: manual # Requires manual approval in UI 

when: manual for production creates a button in the GitLab UI as a gate before release. Useful when QA must approve before submitting to App Store. Production release is blocked until manual approval—standard practice for quality control.

What's Included in the Turnkey CI/CD Setup

When you order CI/CD setup, you get:

• A .gitlab-ci.yml file with test, build, and distribute stages for both iOS and Android.
• A configured self-hosted runner (macOS for iOS, Linux/Windows for Android).
• Integration with Fastlane for code signing and deployment to TestFlight / Google Play.
• Caching configuration for artifacts and dependencies.
• Environment definitions and rules for different branches and tags.
• Pipeline documentation and a 1-hour team training session.
• 2 weeks of post-launch support—we fix any issues that arise.

Timeline and Pricing

Basic setup (macOS runner, test + beta lanes): 3–5 days. Full configuration with environments, Android pipeline, caching, and review apps: 1.5–2 weeks. Pricing is individual.

Order your mobile app CI/CD setup today. We'll assess your project in one day—just contact us.