M6 Mac mini vs GitHub's hosted macOS runner: an Xcode build benchmark

We wanted a real number for one question. How much faster is a dedicated M6 Mac mini than GitHub's standard hosted macOS runner, on a real iOS app? So we built the open-source Wikipedia iOS app on both, with the same Xcode and the same script, three times each.

This post replaces our earlier M4 benchmark post. Every number here comes from runs made on September 24, 2026.

Results

Median of 3 runs, in seconds. Lower is better.

                      GitHub-hosted   MacRun M6   change
                      macos-26
package download            43            39       -8%
clean build                183            86      -53%
incremental build           21            10      -51%
no-op build                 20            10      -50%
220 unit tests              44            17      -61%

The M6 was about twice as fast at compiling. The package download was close, because both machines pull the same packages from GitHub over fast connections. Every step succeeded on both machines in every run.

What a normal CI job costs in time

The table compares the machines step by step. A real CI job is different on each. A hosted runner starts every job empty. It has to download packages, build from clean, and then test. A dedicated Mac keeps its build folder, so after a small change it only rebuilds what changed.

That is the gap your team feels. A job that took four and a half minutes finishes in under thirty seconds. On a busy day of pushes, the saved minutes add up to hours.

The same job costs money on a hosted runner. GitHub rounds each job up to the minute, so 269 seconds bills as 5 minutes. At $0.062 a minute that is about 31 cents a job. On a dedicated Mac it costs nothing extra. Our cost calculator turns your own job count into a monthly figure.

The two machines

The hardware details come from the machines themselves. Each run printed its chip, core count and memory before building. GitHub also sells larger macOS runners at higher per-minute prices. We tested the standard one because it is what most teams use.

Method

• Project: wikimedia/wikipedia-ios at commit 8691a89, built for the iOS Simulator with its Wikipedia scheme and Swift packages.
• Simulator: a new iPhone 17 on iOS 26.5, created the same way on both machines.
• Every run starts with the package cache and DerivedData deleted. Signing is off, as it usually is for CI simulator builds.
• Package download: xcodebuild -resolvePackageDependencies into an empty folder.
• Clean build: xcodebuild build-for-testing with empty DerivedData and packages already downloaded.
• Incremental build: the same command after adding one comment line to one Swift file in the app.
• No-op build: the same command again with nothing changed.
• Tests: the 220 unit tests in the app's WMFData package, run with test-without-building on a booted simulator.
• Three full runs on each machine. We report the median.

Caveats

We ran the app's package tests, not its main test target. The main target needs signed app-group entitlements, and an unsigned CI build does not have them. Its test host kept relaunching on both machines, so it was no fair measure.

The incremental build touched one small file. Most of its 10 seconds is Xcode planning the build, which is why it matches the no-op build. A change to a widely used file would take longer on both machines.

The two machines ran different macOS versions, because each ran what its owner ships today. A hosted job can also cache Swift packages with actions/cache. That would cut the download step. It would not remove the clean build, which is most of the time.

We sell the M6 runner, so weigh our numbers with that in mind. The method above is complete enough to rerun on your own project, which is the only benchmark that really matters to you.