Setting Up CI/CD for iOS with GitHub Actions

Why CI/CD Matters for Mobile

Mobile app releases have a unique challenge: you can't just deploy a fix to production in minutes like you would with a web app. Every release goes through App Store review, which means bugs that slip through can take days to reach users as a fix. A solid CI/CD pipeline is your safety net.

Before we set up proper automation, our release process was painful. Manual builds, manual testing checklists, manual code signing headaches. A single release could take an entire day of an engineer's time. After implementing our pipeline, that dropped to a single button press.

The Pipeline Architecture

Our CI/CD pipeline has three main stages, each triggered by different events:

• PR Validation - Runs on every pull request to catch issues early
• Nightly Builds - Scheduled builds that run the full test suite and produce TestFlight builds
• Release Pipeline - Triggered manually or by a tag, handles App Store submission

Stage 1: PR Validation

Every pull request triggers a workflow that builds the project, runs unit tests, and performs static analysis. This gives reviewers confidence that the code compiles and passes tests before they even start reviewing.

# .github/workflows/pr-validation.yml
name: PR Validation
on:
  pull_request:
    branches: [develop, main]

jobs:
  build-and-test:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4

      - name: Select Xcode version
        run: sudo xcode-select -s /Applications/Xcode_15.2.app

      - name: Cache SPM packages
        uses: actions/cache@v4
        with:
          path: .build
          key: ${{ runner.os }}-spm-${{ hashFiles('**/Package.resolved') }}

      - name: Build
        run: |
          xcodebuild build-for-testing \
            -scheme MyApp \
            -destination 'platform=iOS Simulator,name=iPhone 15' \
            -skipPackagePluginValidation

      - name: Run unit tests
        run: |
          xcodebuild test \
            -scheme MyApp \
            -destination 'platform=iOS Simulator,name=iPhone 15' \
            -resultBundlePath TestResults.xcresult

      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: TestResults.xcresult

Stage 2: Code Signing with Fastlane Match

Code signing is historically the most painful part of iOS CI/CD. We use Fastlane Match to manage certificates and provisioning profiles in a private Git repository, which all CI machines can access.

# Fastfile
platform :ios do
  lane :sync_certificates do
    match(
      type: "appstore",
      app_identifier: "com.company.app",
      readonly: true,
      git_url: "https://github.com/org/certificates.git"
    )
  end

  lane :build_for_testflight do
    sync_certificates
    increment_build_number(
      build_number: ENV["GITHUB_RUN_NUMBER"]
    )
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      output_directory: "./build"
    )
  end
end

Stage 3: Automated TestFlight & App Store Deployment

Once a build passes all checks, deploying to TestFlight is a single command. For App Store releases, we use a tag-based trigger that builds, signs, and uploads to App Store Connect.

# .github/workflows/release.yml
name: Release to App Store
on:
  push:
    tags: ['v*']

jobs:
  release:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4

      - name: Install Fastlane
        run: bundle install

      - name: Build and upload to TestFlight
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          APP_STORE_CONNECT_API_KEY: ${{ secrets.ASC_API_KEY }}
        run: bundle exec fastlane build_for_testflight

      - name: Upload to App Store Connect
        run: bundle exec fastlane upload_to_testflight

      - name: Notify team on Slack
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {"text": "New build uploaded to TestFlight: ${{ github.ref_name }}"}

Key Optimizations

Caching for Speed

iOS builds are slow. Caching Swift Package Manager dependencies and derived data cut our build times significantly. SPM resolution alone was taking 3-5 minutes on every build before we added caching.

Parallel Testing

We split our test suite across multiple simulator instances to run tests in parallel. This reduced our test execution time from 15 minutes to about 5 minutes.

Selective Testing

Not every PR needs the full test suite. We implemented path-based filtering so that changes to documentation or non-code files skip the build entirely, and changes to specific modules only run relevant tests.

Managing Secrets

Security is critical in CI/CD. We store all sensitive data - API keys, certificates passwords, App Store Connect credentials - as GitHub encrypted secrets. These are never logged and are only available to workflows running on protected branches.

A good CI/CD pipeline should be invisible to engineers during normal development but invaluable when things go wrong.

Results

• Release frequency increased by 40% - What used to take a full day now takes minutes.
• Zero manual code signing issues - Fastlane Match eliminated the "works on my machine" problem entirely.
• Bugs caught earlier - Automated testing on every PR catches regressions before they reach the main branch.
• Team confidence improved - Engineers ship with confidence knowing the pipeline validates their work.

Tips for Getting Started

1. Start simple. Begin with just building and running tests on PRs. Add complexity incrementally.
2. Solve code signing first. This is the biggest blocker. Invest time in Fastlane Match setup early.
3. Cache aggressively. SPM dependencies, derived data, and Ruby gems all benefit from caching.
4. Monitor build times. Track how long builds take and set alerts for regressions. Slow CI slows down the whole team.
5. Use macOS runners wisely. They're expensive. Offload non-build tasks (linting, checks) to Linux runners where possible.