Mac mini M6 vs runner macOS in hosting di GitHub: un benchmark di build Xcode

Volevamo un numero reale per una domanda. Quanto è più veloce un Mac mini M6 dedicato rispetto al runner macOS standard in hosting di GitHub, su una vera app iOS? Così abbiamo compilato l’app iOS open source di Wikipedia su entrambi. Stesso Xcode, stesso script, tre volte ciascuno.

Questo articolo sostituisce il nostro precedente benchmark sull’M4. Ogni numero qui viene da esecuzioni fatte il 24 settembre 2026.

Risultati

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%

L’M6 ha compilato circa due volte più veloce. Il download dei pacchetti è stato simile, perché entrambe le macchine scaricano gli stessi pacchetti da GitHub con connessioni veloci. Ogni passaggio è riuscito su entrambe le macchine in ogni esecuzione.

Quanto tempo costa un normale job di CI

La tabella confronta le macchine passaggio per passaggio. Un vero job di CI è diverso su ciascuna. Un runner in hosting inizia ogni job vuoto. Deve scaricare i pacchetti, compilare da zero e poi testare. Un Mac dedicato conserva la cartella di build. Dopo una piccola modifica ricompila solo ciò che è cambiato.

È questa la differenza che il tuo team percepisce. Un job che richiedeva quattro minuti e mezzo finisce in meno di trenta secondi. In una giornata piena di push, i minuti risparmiati diventano ore.

Sullo stesso runner in hosting quel job costa anche soldi. GitHub arrotonda ogni job al minuto superiore, quindi 269 secondi vengono fatturati come 5 minuti. A $0.062 al minuto sono circa 31 centesimi a job. Su un Mac dedicato non costa nulla in più. Il nostro calcolatore dei costi trasforma il tuo numero di job in una cifra mensile.

Le due macchine

I dettagli hardware vengono dalle macchine stesse. Ogni esecuzione ha stampato chip, numero di core e memoria prima della build. GitHub vende anche runner macOS più grandi a prezzi al minuto più alti. Noi abbiamo testato quello standard, perché è quello che usa la maggior parte dei team.

Metodo

• Progetto: wikimedia/wikipedia-ios al commit 8691a89, compilato per il simulatore iOS con lo schema Wikipedia e i suoi pacchetti Swift.
• Simulatore: un nuovo iPhone 17 con iOS 26.5, creato nello stesso modo su entrambe le macchine.
• Ogni esecuzione parte con la cache dei pacchetti e DerivedData cancellati. La firma è disattivata, come di solito avviene per le build di CI per il simulatore.
• Download dei pacchetti: xcodebuild -resolvePackageDependencies in una cartella vuota.
• Build pulita: xcodebuild build-for-testing con DerivedData vuoto e pacchetti già scaricati.
• Build incrementale: lo stesso comando dopo aver aggiunto una riga di commento a un file Swift dell’app.
• Build no-op: di nuovo lo stesso comando, senza alcuna modifica.
• Test: i 220 test unitari del pacchetto WMFData dell’app, eseguiti con test-without-building su un simulatore avviato.
• Tre esecuzioni complete su ogni macchina. Riportiamo la mediana.

Limiti

Abbiamo eseguito i test dei pacchetti dell’app, non il suo target di test principale. Il target principale richiede entitlement di app group firmati, e una build di CI senza firma non li ha. Il suo test host continuava a riavviarsi su entrambe le macchine, quindi non era una misura equa.

La build incrementale ha toccato un solo file piccolo. La maggior parte dei suoi 10 secondi è Xcode che pianifica la build, ed è per questo che coincide con la build no-op. Una modifica a un file usato ovunque richiederebbe più tempo su entrambe le macchine.

Le due macchine usavano versioni diverse di macOS, perché ciascuna usava ciò che il suo proprietario distribuisce oggi. Un job in hosting può anche mettere in cache i pacchetti Swift con actions/cache. Accorcerebbe il download. Non eliminerebbe la build pulita, che è la maggior parte del tempo.

Noi vendiamo il runner M6, quindi valuta i nostri numeri tenendone conto. Il metodo qui sopra è abbastanza completo da rifarlo sul tuo progetto. È l’unico benchmark che conta davvero per te.