Mac mini M6 contre le runner macOS hébergé de GitHub : un benchmark de build Xcode

Nous voulions un vrai chiffre pour une seule question. De combien un Mac mini M6 dédié est-il plus rapide que le runner macOS hébergé standard de GitHub, sur une vraie app iOS ? Nous avons donc compilé l’app iOS open source de Wikipédia sur les deux, avec le même Xcode et le même script, trois fois chacun.

Cet article remplace notre ancien benchmark sur le M4. Chaque chiffre ici vient d’exécutions faites le 24 septembre 2026.

Résultats

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%

Le M6 compilait environ deux fois plus vite. Le téléchargement des paquets était proche, car les deux machines récupèrent les mêmes paquets depuis GitHub avec des connexions rapides. Chaque étape a réussi sur les deux machines, à chaque exécution.

Ce qu’un job de CI normal coûte en temps

Le tableau compare les machines étape par étape. Un vrai job de CI se déroule différemment sur chacune. Un runner hébergé démarre chaque job à vide. Il doit télécharger les paquets, compiler à partir de zéro, puis tester. Un Mac dédié garde son dossier de build. Après une petite modification, il ne recompile que ce qui a changé.

C’est l’écart que votre équipe ressent. Un job qui prenait quatre minutes et demie se termine en moins de trente secondes. Sur une journée chargée en pushs, les minutes gagnées font des heures.

Ce même job coûte de l’argent sur un runner hébergé. GitHub arrondit chaque job à la minute supérieure, donc 269 secondes sont facturées 5 minutes. À $0.062 la minute, cela fait environ 31 cents par job. Sur un Mac dédié, il ne coûte rien de plus. Notre calculateur de coûts transforme votre propre nombre de jobs en montant mensuel.

Les deux machines

Les détails matériels viennent des machines elles-mêmes. Chaque exécution affichait sa puce, son nombre de cœurs et sa mémoire avant de compiler. GitHub vend aussi des runners macOS plus gros, plus chers à la minute. Nous avons testé le runner standard, parce que c’est celui qu’utilisent la plupart des équipes.

Méthode

• Projet : wikimedia/wikipedia-ios au commit 8691a89, compilé pour l’iOS Simulator avec son scheme Wikipedia et ses paquets Swift.
• Simulateur : un iPhone 17 neuf sous iOS 26.5, créé de la même façon sur les deux machines.
• Chaque exécution commence avec le cache des paquets et DerivedData supprimés. La signature est désactivée, comme d’habitude pour les builds de CI sur simulateur.
• Téléchargement des paquets : xcodebuild -resolvePackageDependencies dans un dossier vide.
• Build propre : xcodebuild build-for-testing avec un DerivedData vide et les paquets déjà téléchargés.
• Build incrémental : la même commande après l’ajout d’une ligne de commentaire dans un fichier Swift de l’app.
• Build à vide : la même commande, relancée sans aucun changement.
• Tests : les 220 tests unitaires du paquet WMFData de l’app, lancés avec test-without-building sur un simulateur démarré.
• Trois exécutions complètes sur chaque machine. Nous donnons la médiane.

Réserves

Nous avons lancé les tests des paquets de l’app, pas sa cible de test principale. La cible principale exige des entitlements d’app group signés, et un build de CI non signé ne les a pas. Son hôte de test se relançait sans cesse sur les deux machines. Ce n’était donc pas une mesure équitable.

Le build incrémental touchait un seul petit fichier. L’essentiel de ses 10 secondes, c’est Xcode qui planifie le build. C’est pourquoi il égale le build à vide. Une modification d’un fichier très utilisé prendrait plus de temps sur les deux machines.

Les deux machines tournaient sous des versions différentes de macOS, car chacune avait ce que son propriétaire livre aujourd’hui. Un job hébergé peut aussi mettre en cache les paquets Swift avec actions/cache. Cela réduirait l’étape de téléchargement. Cela ne supprimerait pas le build propre, qui prend l’essentiel du temps.

Nous vendons le runner M6, pesez donc nos chiffres en gardant cela en tête. La méthode ci-dessus est assez complète pour être relancée sur votre propre projet. C’est le seul benchmark qui compte vraiment pour vous.