Mac Build Farm

What goes into a good Mac build farm

Adding machines is the easy part. The farms that stay fast get four things right: labels, caches, signing and parallel tests.

Prices in USD per month for each machine's starting configuration. More memory, storage or several machines? Ask us.

1. Runner labels

Labels let jobs ask for the kind of machine they need. Keep them few and meaningful:

• macos, arm64: every node.
• xcode-x.y: one label per installed Xcode version, so you can upgrade node by node.
• large: M5 Pro or Mac Studio nodes for big archives and Unity builds.
• signing: nodes trusted with release certificates.

jobs:
  archive:
    runs-on: [self-hosted, macos, arm64, xcode-x.y, signing]

This works the same way in GitHub Actions, GitLab runners (tags) and Jenkins (agent labels).

2. Cache strategy

Dedicated machines keep their disks between jobs, which is the biggest speed advantage over fresh hosted runners. Use it on purpose:

• Xcode: keep DerivedData per project and per runner with -derivedDataPath. Cache Swift Package Manager checkouts in a fixed directory.
• CocoaPods: keep the pods cache warm; only run pod install when the lockfile changes.
• Unity: keep the project's Library folder between builds. Re-importing assets is often the slowest step.
• Flutter: keep the pub cache and pin the Flutter SDK version per node.
• React Native: keep node_modules or the package manager cache, plus Pods for the iOS side.

Clean on a schedule, not on every job. A nightly script that removes caches older than a week keeps disks healthy. Choose 512GB nodes such as the 24GB Mac mini M6 when caches are large.

3. A signing keychain per node

Keep release signing separate from the login keychain on each node:

1. Create a dedicated keychain, for example with security create-keychain -p "$PASS" build.keychain.
2. Import the certificate during the job, unlock the keychain, and add it to the search list.
3. Delete or lock it when the job ends.

Tools such as fastlane match automate this. Only nodes with the signing label should hold release credentials. See Apple's distribution documentation for the signing details.

4. Parallel test destinations

Use both levels of parallelism:

• Within a node: -parallel-testing-enabled YES runs tests across simulator clones. Pass several -destination flags to test more than one device in a single run.
• Across nodes: split the suite into shards with test plans or -only-testing, one shard per node.

More memory means more simulator clones per node, which is why build farms often favour 24GB and larger machines.

Sizing: a rough starting point

Team	Suggested farm	Why
1–3 mobile developers	1 × Mac mini M6 24GB	Two runners on one machine
4–8 developers	2–3 × Mac mini M6 24GB	Builds and tests in parallel
9–20 developers	4–6 Mac minis, including 1–2 × M5 Pro	Large archives on Pro-class nodes
Game or multi-app studio	Mac minis plus 1 × Mac Studio M5 Max	Unity builds and heavy imports

Every codebase is different. Measure queue time for two weeks, then add nodes where jobs wait. For setup details, see iOS build server and Mac cluster hosting.

FAQ

Which CI systems work with a Mac build farm?

Any that support self-hosted agents on macOS, including GitHub Actions, GitLab, Jenkins and others. You install and register the runners yourself.

Do Flutter and React Native apps need a Mac build farm?

Their iOS builds do. Building, signing and uploading an iOS app requires macOS and Xcode.

How many machines does my build farm need?

Use the sizing table as a rough starting point, then measure queue times and add nodes where jobs wait.

Can I get a quote for a whole farm?

Yes. Tell us how many machines and which plans you need on the contact page.