How to reduce Github Actions runtime for an iOS project

When we started building our compute platform, we built for Linux first. As we started onboarding our early customers, they communicated to us iOS CI was a major pain point for them. It requires Apple hardware, a specific version of Xcode, and commonly they needed to boot a simulator (or five). So we designed and built our macOS offering specifically for those types of workloads.

In this post we will walk through migrating the PR workflows for wikimedia/wikipedia-ios, the Wikipedia app for iOS, to our GitHub Action Runners and Cache Volumes. This cut run time by roughly 3.5x. Wikipedia iOS is a public GitHub repository, so its Actions minutes are already free; modeled as if it were a private, metered repo, the same change would cut the cost of running these workflows by about 70%.

The baseline

Wikipedia iOS gates every pull request on three required workflows: run_unit_tests.yml (a three-scheme matrix: Wikipedia, WMFComponents, WMFData), run_e2e_ui_tests.yml (a UI smoke suite in a booted simulator), and strict_concurrency_check.yml (a from-scratch, warnings-as-errors build of two schemes). All three run on GitHub's hosted macos-26 runners with no dependency caching.

To create a baseline, we pulled recent successful pull_request-triggered runs of each workflow from the upstream repo and measured run time: from when a job starts executing to when it finishes, excluding time spent queued waiting for a runner. Here is what we observed:

Step 1: Use Namespace macOS runners

The first change points the three workflows at a Namespace Mac profile, with caching not enabled:

 jobs:   run-unit-tests:-    runs-on: macos-26+    runs-on: namespace-profile-wikipedia-ios-mac

One environment gap surfaced while migrating, worth calling out for any iOS project making the same move: GitHub's macos-26 image ships xcpretty preinstalled, and ours doesn't, so anything that pipes xcodebuild through it needs an explicit install step:

     name: Test ${{ matrix.scheme }}     steps:+      - name: Install xcpretty+        run: |+          gem install xcpretty+        - uses: actions/checkout@v7

With that fixed, all three workflows were green. Here's the result, averaged across several runs with no caching enabled yet:

Dedicated hardware alone accounts for a 68-74% cut in run time, before caching enters the picture.

Step 2: Enable caching

The second change adds a nscloud-cache-action step to each workflow, caching SwiftPM packages, CocoaPods, and Xcode's derived data:

       - name: Select Xcode         run: |           sudo xcode-select -switch "/Applications/Xcode_${XCODE_VERSION}.app"  +      - name: Cache+        uses: namespacelabs/nscloud-cache-action@v1+        with:+          cache: |+            swiftpm+            xcode+            cocoapods+        - name: Prepare simulator         id: simulator         uses: ./.github/actions/prepare-simulator

Here is what we observed when enabling cache in each workflow:

Those workflow totals still include fixed overhead caching can't touch: checkout, selecting Xcode, booting the simulator. Isolating just the xcodebuild step per scheme shows caching's effect more clearly: 10-22% across every scheme, largest on Strict Concurrency's from-scratch SwiftPM builds (18-21%) and present too on the smaller unit test targets, WMFComponents and WMFData (10-14%). The cache restore itself never showed measurable time across any of the runs, consistent with a mounted volume rather than an upload-and-download cycle.

Final results

Putting both changes together, and looking at the slowest of the three required checks on a given PR (the long pole of run time, not counting queue wait), E2E Tests' run time drops from an 18m 38s mean on GitHub-hosted runners to a 5m 26s mean on Namespace with caching.

Wikipedia iOS is a public repository, so its GitHub Actions minutes come at no cost. The cost column below models what these workflows would cost on a private, metered repo, using each side's own published list price: GitHub's standard macOS rate ($0.062/min), and Namespace's 6 vCPU / 14 GB shape at its prepaid rate ($0.060/min):

At $0.060/min, our shape is already slightly cheaper per minute than GitHub's rate, so the 3.25x fewer billed minutes measured here is pure upside: there's no per-minute premium to make up for.

Scaled to Wikipedia iOS's actual traffic, about 185 runs of each workflow per month, modeled monthly cost (still assuming a private, metered repo) drops from $574.65 on GitHub-hosted runners to $171.27 on Namespace, a savings of roughly $403 a month.

Why Namespace's Mac runners and Cache Volumes are different

GitHub's default hosted macOS runner, the macos-26 label used by these workflows, provides 3 CPU cores and 7 GB of RAM on Apple M1 hardware. The Mac profile used in this migration, namespace-profile-wikipedia-ios-mac, is built on our standard 6 vCPU / 14 GB shape, running on Apple M4 or M5 Max hardware. This gives you more cores, more memory, and the latest silicon at a lower price per minute. We also design how we rack Mac hardware in our datacenters specifically for workloads like CI builds and tests.

Caching benefits from the same design philosophy. Our Cache Volumes run on fully local NVMe storage with high IOPS and no upload or download time, and they persist data across GitHub Actions runs instead of being fetched fresh from remote storage the way actions/cache works. That gives a runner instant access to cached data through guaranteed cache locality. Cache Volumes also support high concurrency through automatic forking and scale up to hundreds of GB.

Try it yourself

Wikipedia iOS is a representative mid-size iOS project: a multi-scheme test matrix, a UI test suite that boots a simulator, and a strict-concurrency build with SwiftPM dependency resolution. The main variables are how much of your workflow is compilation versus fixed overhead, and how often it runs. Get started today.