Claude Code Mobile CI/CD GitHub Actions Workflow Guide

Mobile app development demands reliable CI/CD pipelines to ensure consistent builds, comprehensive testing, and smooth deployments to app stores. This guide shows you how to build production-ready mobile CI/CD workflows using GitHub Actions with Claude Code to automate repetitive tasks and catch issues early. Whether you’re building iOS apps with Xcode, Android apps with Gradle, or cross-platform apps with React Native or Flutter, these patterns will help you ship faster with confidence.

Why Mobile CI/CD Needs Special Attention

Mobile development introduces unique challenges that general-purpose CI/CD workflows don’t address. You need to manage platform-specific build tools, handle code signing certificates and secrets securely, test on multiple device configurations, and navigate app store submission requirements. GitHub Actions provides the flexibility to handle these scenarios, while Claude Code can help you generate workflow configurations, debug failures, and maintain your pipelines over time.

Unlike web applications where you can often deploy continuously, mobile apps require careful coordination between builds, tests, and releases. A single workflow that tries to do everything often becomes fragile. Instead, consider separating your pipelines into distinct stages: continuous integration for every pull request, build pipelines for release candidates, and deployment pipelines for app store submissions.

Setting Up Your First Mobile CI Workflow

The foundation of any mobile CI/CD setup starts with a solid continuous integration workflow that runs on every pull request. This workflow should validate code quickly, catch obvious issues, and provide fast feedback to developers. For mobile projects, this typically means running linters, unit tests, and building a debug APK or IPA file to verify the project compiles.

Create a workflow file at .github/workflows/ci.yml in your repository:

name: Mobile CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run linter
        run: npm run lint
      
      - name: Run unit tests
        run: npm run test

  build-android:
    needs: lint-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      
      - name: Setup Android SDK
        uses: android-actions/setup-android@v2
      
      - name: Build Android Debug APK
        run: ./gradlew assembleDebug
      
      - name: Upload APK
        uses: actions/upload-artifact@v4
        with:
          name: android-debug
          path: app/build/outputs/apk/debug/*.apk

This workflow runs linting and tests on every push and pull request. The Android build only runs after tests pass, ensuring you never merge code that breaks the build. The artifact upload lets you download and test the APK directly from GitHub.

For iOS projects, you’ll need to use macOS runners since Xcode only runs on Apple hardware. GitHub provides macOS runners in their hosted runners, though you’ll need to account for minute limits on free accounts:

  build-ios:
    needs: lint-and-test
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Xcode
        uses: maxim-lobanov/setup-xcode@v1
        with:
          xcode-version: '15.0'
      
      - name: Install CocoaPods dependencies
        run: pod install
      
      - name: Build iOS Debug
        run: xcodebuild -workspace MyApp.xcworkspace -scheme Debug -configuration Debug build
      
      - name: Upload IPA
        uses: actions/upload-artifact@v4
        with:
          name: ios-debug
          path: build/*.ipa

Managing Code Signing and Secrets Securely

Code signing represents one of the most challenging aspects of mobile CI/CD. You need to store certificates and provisioning profiles securely, make them available during builds, and manage their expiration dates. GitHub Secrets provide encrypted storage for sensitive values, while the keychain and signing actions handle the complexity of configuring iOS code signing on macOS runners.

For Android, you need to set up a signing key and configure Gradle to use it:

  build-android-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      
      - name: Setup Android SDK
        uses: android-actions/setup-android@v2
      
      - name: Decode signing key
        run: echo "${{ secrets.ANDROID_SIGNING_KEY }}" | base64 -d > app/signing-key.jks
      
      - name: Build Android Release
        run: ./gradlew assembleRelease
        env:
          KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
          KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
          KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}

Store these secrets in your repository settings under “Secrets and variables, Actions.” Never commit signing keys to your repository, and rotate them periodically, especially when team members who had access leave the project.

iOS code signing requires more setup because you need to create a signing certificate and provisioning profile, then import them into the macOS keychain during the workflow:

  build-ios-release:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      
      - name: Import Code Signing Certificate
        uses: apple-actions/import-codesign@v1
        with:
          p12-file-base64: ${{ secrets.CERTIFICATES_P12 }}
          p12-password: ${{ secrets.CERTIFICATES_PASSWORD }}
      
      - name: Download Provisioning Profile
        uses: apple-actions/download-provisioning-profile@v1
        with:
          profile: ${{ secrets.PROVISIONING_PROFILE }}
      
      - name: Build iOS Release
        run: xcodebuild -workspace MyApp.xcworkspace -scheme Release -configuration Release build CODE_SIGN_IDENTITY="${{ secrets.CERTIFICATE_NAME }}" PROVISIONING_PROFILE="${{ secrets.PROVISIONING_PROFILE_NAME }}"

Automating App Store Deployments

Once your CI pipeline works reliably, you can extend it to handle app store submissions. Both Apple and Google provide actions that integrate with their respective submission APIs. For Play Store deployments, the r0adkll/upload-google-play action handles the upload process:

  deploy-android:
    needs: build-android-release
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      
      - name: Install Google Play Publisher
        run: pip install google-api-python-client google-auth-httplib2 google-auth-oauthlib
        
      - name: Deploy to Play Store
        run: |
          python scripts/upload_to_playstore.py
        env:
          SERVICE_ACCOUNT_JSON: ${{ secrets.GOOGLE_PLAY_SERVICE_ACCOUNT }}

For iOS App Store deployments, the deliver action from fastlane remains the industry standard:

  deploy-ios:
    needs: build-ios-release
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      
      - name: Import Code Signing Certificate
        uses: apple-actions/import-codesign@v1
        with:
          p12-file-base64: ${{ secrets.CERTIFICATES_P12 }}
          p12-password: ${{ secrets.CERTIFICATES_PASSWORD }}
      
      - name: Download Provisioning Profile
        uses: apple-actions/download-provisioning-profile@v1
        with:
          profile: ${{ secrets.PROVISIONING_PROFILE }}
      
      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.0'
      
      - name: Install Fastlane
        run: bundle install
      
      - name: Deploy to App Store
        run: bundle exec fastlane deliver
        env:
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_PASSWORD }}
          DELIVER_USER: ${{ secrets.DELIVER_USER }}

Optimizing Mobile Workflow Performance

Mobile builds can be slow, so optimizing your workflows saves significant time and CI runner minutes. The most effective optimization is caching dependencies and build outputs. Both Android’s Gradle and iOS’s CocoaPods support dependency caching:

  build-android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      
      - name: Setup Android SDK
        uses: android-actions/setup-android@v2
      
      - name: Cache Gradle packages
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      
      - name: Build Android APK
        run: ./gradlew assembleDebug

The cache action stores Gradle’s download directory and wrapper files, skipping downloads on subsequent builds when nothing changed. For iOS, use the caching action similarly with CocoaPods:

      - name: Cache CocoaPods
        uses: actions/cache@v4
        with:
          path: Pods
          key: ${{ runner.os }}-pods-${{ hashFiles('**/Podfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-pods-

Beyond caching, consider splitting your workflow into parallel jobs for independent tasks. If your project has both Android and iOS components, build them in separate jobs that run simultaneously rather than sequentially.

Testing Mobile Apps in CI

Unit tests verify your business logic, but mobile apps also need UI and integration tests. For Android, Espresso tests run on Android emulators. For iOS, you can use XCTest. Both require emulator or simulator setup in your workflow:

  android-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      
      - name: Setup Android SDK
        uses: android-actions/setup-android@v2
      
      - name: Create Emulator
        uses: android-actions/create-android-emulator@v2
        with:
          api-level: 34
          target: google_apis
          arch: x86_64
          profile: Nexus 6
      
      - name: Run Espresso Tests
        run: ./gradlew connectedAndroidTest
      
      - name: Upload Test Reports
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: android-test-reports
          path: app/build/reports/androidTests/connected/

For React Native and Flutter projects, you can use Expo and Flutter’s built-in testing commands respectively, following similar patterns of setup, test execution, and artifact collection.

Best Practices for Mobile CI/CD

Building reliable mobile CI/CD workflows requires attention to several key practices. First, keep your workflows as simple as possible while still catching issues. Start with basic lint and test runs, then add complexity as needed. Second, use matrix strategies to test on multiple Android API levels or iOS versions if your app supports older platforms. Third, always upload build artifacts even for failed builds—debugging a CI failure without the artifact that caused it is unnecessarily difficult.

Fourth, implement proper branch protection rules that require CI to pass before merging. GitHub’s branch protection settings let you require status checks before merging, ensuring no code reaches your main branch without passing your CI pipeline.

Finally, document your workflow configuration and team conventions. Use Claude Code to generate documentation explaining what each job does, what secrets it requires, and how to troubleshoot common failures. This documentation pays dividends when team members need to modify the workflow months later.

Mobile CI/CD doesn’t have to be complicated. Start with the patterns in this guide, adapt them to your project’s specific needs, and iterate as you discover what works best for your team.

Built by theluckystrike — More at zovo.one