GitHub Actions — what it is, CI/CD pipelines and automation

What is GitHub Actions?

GitHub Actions is a workflow automation platform built into GitHub and launched in 2019. It allows you to define CI/CD pipelines in YAML files stored directly in the repository. Each workflow is triggered by an event: push, pull request, tag creation, or on a schedule. Unlike Jenkins or TeamCity, no separate infrastructure is required to host a CI server.

In the context of mobile development, GitHub Actions automates APK and IPA building, running unit tests and UI tests on emulators, code linting, signing and publishing to Google Play and App Store. The platform provides free minutes for public repositories and for private ones depending on the pricing plan. For open-source mobile projects, this is a full-fledged CI/CD solution at no cost.

GitHub Actions Architecture: Workflows, Jobs and Steps

The GitHub Actions architecture consists of four levels. Workflow is the root YAML file that defines automation. A Workflow consists of Jobs, each Job runs on a separate Runner. Inside a Job, Steps are executed — sequential commands or external actions. Events define the triggers: push, pull_request, schedule, workflow_dispatch. A workflow can also be triggered manually through the Actions tab in the GitHub interface.

GitHub provides hosted runners with pre-installed OS: Ubuntu, macOS and Windows. For iOS builds, a macOS runner is mandatory, for Android — Linux or macOS. Self-hosted runners allow you to run jobs on your own servers with a custom environment, which is useful for large projects with special hardware requirements. GitHub also supports self-hosted runner groups for organizing job execution queues.

Workflow File Structure

A basic workflow file contains sections: name, on (triggers), jobs. Each job specifies runs-on (runner type), strategy (matrix), steps (list of actions). Steps can be shell commands or ready-made actions from the marketplace, connected using the owner/repo@version syntax.

Building Mobile Applications in GitHub Actions

For Android builds, a workflow typically includes steps: checkout repository, install JDK, configure Gradle cache, run assembleRelease. For iOS, a macOS runner is required, Xcode installation via xcode-select, provisioning profile resolution and running xcodebuild. The complexity of iOS builds lies in code signing and certificate management. Apple-specific settings include provisioning profile management through apple-actions/import-codesign-certs.

Matrix strategy allows running builds on multiple versions simultaneously. For example: matrix with iOS versions (15.0, 16.0, 17.0) and Xcode (14, 15). This accelerates verification of application compatibility with different OS versions, although it increases runner minutes consumption. For projects with a limited CI budget, the matrix can be restricted to main configurations only.

Setting Up Environment for Android

GitHub Actions provides the setup-java action for JDK installation and caching for Gradle caching. Android SDK is already pre-installed on Ubuntu runners. For custom API levels, sdkmanager is used in a separate step. It is recommended to create separate workflows for Android and iOS builds, as they use different runners and build tools.

GitHub Marketplace and Ready-Made Actions

GitHub Marketplace contains over 15,000 actions created by the community and official developers. For mobile development, key categories include: Code signing (apple-actions/import-codesign-certs), testing (react-native-community/action), deployment (google-github-actions/release-google-play), notifications (slackapi/slack-github-action). Actions for Firebase App Distribution, TestFlight upload and Fastlane are also available. Each action has a compatibility label for a specific runner OS.

Each action has a version, description, README and license. When choosing an action, preference should be given to official ones from vendors (Google, Apple, Microsoft) and verified through Verified Badge. It is important to specify a fixed major version (actions/checkout@v4), not @main, to avoid unexpected changes. If the required action is not in the Marketplace, you can create a custom action — locally in the repository (Docker action or JavaScript action) or publish it to the Marketplace.

Popular Actions for Mobile CI/CD

• actions/checkout — clones the repository to the runner
• actions/setup-java — installs JDK for Android builds
• gradle/actions/setup-gradle — configures and caches Gradle
• apple-actions/import-codesign-certs — imports certificates for iOS
• google-github-actions/submit-release — publishes to Google Play Console

Example Workflow for iOS Project

When developing iOS applications, it is important to set up correct work with simulators and devices. macOS-14 runner provides an environment with Rosetta 2 for running Intel builds on ARM architecture. A workflow can include multiple build schemes — Debug for pull requests and Release for tags. GitHub Actions supports xcresult parsing through the xcparse/sonarqube action for displaying test results. To send build status notifications, you can add a Slack or Telegram action.

Code signing for iOS requires importing certificates and provisioning profiles. Apple-actions provide a step for importing a P12 certificate and installing a provisioning profile. Certificates are stored as GitHub Actions secrets and are decrypted only at the build stage. For signing automation, Fastlane match is used, which can be called as a separate step in the workflow.

Let’s consider a workflow for an iOS app on Swift that builds the project, runs tests, and creates an archived build. The workflow uses macOS-14 runner, Xcode 15.4 and actions for certificate management.

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

Caching Dependencies in GitHub Actions

Caching reduces build time by preserving dependencies between workflow runs. GitHub provides built-in caching through actions/cache. For Gradle, ~/.gradle is cached, for CocoaPods — Pods/, for SPM — .build/. The cache key includes a hash of the dependency list file — when dependencies change, the cache is automatically invalidated.

Special attention should be given to the cache restore strategy (restore-keys). If the exact key is not found, GitHub Actions tries partial matching by restore-keys. This is useful when only one dependency changes — the cache remains partially usable. For Gradle, it is additionally recommended to enable Gradle Build Cache, which caches build results between different project modules.

Gradle Caching Example

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

Cache efficiency for Android projects: first build without cache — 8–12 minutes, subsequent build with cache — 2–4 minutes. For iOS with CocoaPods, the savings are similar. It is recommended to combine actions/cache with the setup-gradle action from Gradle for optimal cache management. For npm dependencies in React Native, actions/cache is used with package-lock.json hashing. With proper cache configuration, build time can be reduced by up to 70%.

GitHub Actions supports environment variables at workflow, job and step levels. Environment variables can be overridden: step-level has the highest priority. For confidential data, always use secrets — they are encrypted with AES-256 and are not displayed in logs. Environment protection rules are also available — mandatory manual approval before deployment. For additional security, you can configure mandatory approval from specific users or teams.

GitHub Actions also supports Reusable Workflows — reusable pipelines that can be called from other workflows. This allows creating a centralized build workflow and reusing it across all organization repositories. A reusable workflow is called with a single line and can accept input parameters and secrets. This is especially useful for standardizing CI/CD practices in large teams.

Security and Best Practices

When configuring GitHub Actions for mobile projects, it is important to follow security principles. OIDC (OpenID Connect) allows you to eliminate long-lived credentials and obtain temporary tokens for cloud providers. Never use plain-text secrets in scripts — GitHub Actions automatically masks secrets in logs.

For mobile projects, it is critical to restrict workflow access for third-party forks. Use the pull_request_target setting with caution — it executes code from the base branch, not from the fork. For iOS code signing, it is recommended to store certificates encrypted and decrypt them only at the build stage using gpg or openssl.