M6 Mac mini vs. gehosteter macOS-Runner von GitHub: ein Xcode-Build-Benchmark

Wir wollten eine echte Zahl für eine Frage. Wie viel schneller ist ein dedizierter M6 Mac mini als der gehostete Standard-Runner für macOS von GitHub, bei einer echten iOS-App? Also haben wir die Open-Source-App Wikipedia für iOS auf beiden gebaut. Mit demselben Xcode und demselben Skript, je dreimal.

Dieser Beitrag ersetzt unseren früheren M4-Benchmark. Jede Zahl hier stammt aus Läufen vom 24. September 2026.

Ergebnisse

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%

Beim Kompilieren war der M6 etwa doppelt so schnell. Der Paket-Download lag nah beieinander. Beide Maschinen ziehen dieselben Pakete über schnelle Verbindungen von GitHub. Jeder Schritt lief auf beiden Maschinen in jedem Lauf erfolgreich.

Was ein normaler CI-Job an Zeit kostet

Die Tabelle vergleicht die Maschinen Schritt für Schritt. Ein echter CI-Job sieht auf beiden anders aus. Ein gehosteter Runner startet jeden Job leer. Er muss Pakete laden, sauber bauen und dann testen. Ein dedizierter Mac behält seinen Build-Ordner. Nach einer kleinen Änderung baut er nur neu, was sich geändert hat.

Das ist der Unterschied, den Ihr Team spürt. Ein Job, der viereinhalb Minuten dauerte, ist in unter dreißig Sekunden fertig. An einem Tag mit vielen Pushes summieren sich die gesparten Minuten zu Stunden.

Auf einem gehosteten Runner kostet derselbe Job auch Geld. GitHub rundet jeden Job auf die volle Minute auf. 269 Sekunden werden also als 5 Minuten berechnet. Bei $0.062 pro Minute sind das etwa 31 Cent pro Job. Auf einem dedizierten Mac kostet er nichts extra. Unser Kostenrechner macht aus Ihrer eigenen Jobanzahl einen Monatsbetrag.

Die zwei Maschinen

Die Hardware-Angaben stammen von den Maschinen selbst. Jeder Lauf gab vor dem Build Chip, Kernzahl und Arbeitsspeicher aus. GitHub verkauft auch größere macOS-Runner zu höheren Minutenpreisen. Wir haben den Standard-Runner getestet, weil ihn die meisten Teams nutzen.

Methode

• Projekt: wikimedia/wikipedia-ios bei Commit 8691a89, gebaut für den iOS-Simulator mit seinem Wikipedia-Scheme und seinen Swift-Paketen.
• Simulator: ein neues iPhone 17 mit iOS 26.5, auf beiden Maschinen gleich angelegt.
• Jeder Lauf beginnt mit gelöschtem Paket-Cache und gelöschten DerivedData. Signieren ist aus, wie meist bei Simulator-Builds in der CI.
• Paket-Download: xcodebuild -resolvePackageDependencies in einen leeren Ordner.
• Clean Build: xcodebuild build-for-testing mit leeren DerivedData und bereits geladenen Paketen.
• Inkrementeller Build: derselbe Befehl, nachdem eine Kommentarzeile in eine Swift-Datei der App eingefügt wurde.
• No-op-Build: derselbe Befehl noch einmal, ohne Änderung.
• Tests: die 220 Unit-Tests im Paket WMFData der App, ausgeführt mit test-without-building auf einem gebooteten Simulator.
• Drei vollständige Läufe pro Maschine. Wir nennen den Median.

Einschränkungen

Wir haben die Paket-Tests der App ausgeführt, nicht ihr Haupt-Testziel. Das Haupt-Testziel braucht signierte App-Group-Entitlements, und ein unsignierter CI-Build hat sie nicht. Sein Test-Host startete auf beiden Maschinen immer wieder neu. Ein fairer Vergleich war das nicht.

Der inkrementelle Build änderte eine kleine Datei. Die meisten seiner 10 Sekunden plant Xcode den Build. Deshalb gleicht er dem No-op-Build. Eine Änderung an einer viel genutzten Datei würde auf beiden Maschinen länger dauern.

Die zwei Maschinen liefen mit verschiedenen macOS-Versionen. Jede lief mit dem, was ihr Betreiber heute ausliefert. Ein gehosteter Job kann Swift-Pakete außerdem mit actions/cache zwischenspeichern. Das würde den Download verkürzen. Den Clean Build würde es nicht ersetzen, und der macht den Großteil der Zeit aus.

Wir verkaufen den M6-Runner. Gewichten Sie unsere Zahlen also entsprechend. Die Methode oben ist vollständig genug, um sie mit Ihrem eigenen Projekt zu wiederholen. Nur dieser Benchmark zählt für Sie wirklich.