Comparaison de compilation Xcode complète : MacBook local vs nœud M4 cloud dédié

Pourquoi le build complet révèle mieux les limites matérielles que l'incrémental

Au quotidien, le build incrémental de Xcode masque une grande partie des écarts hardware : un fichier touché, quelques targets recompilés — un MacBook Air 8 Go et un Pro 16 Go semblent tous deux « suffisants ». Dès qu'un merge sur main déclenche un Clean Build en CI, ou qu'un xcodebuild clean build valide la config Release en local, le compilateur charge tous les modules Swift, lance la vérification de types complète et lie chaque extension. C'est le vrai test de mémoire, de refroidissement et de charge CPU soutenue.

Beaucoup de développeurs indépendants disent : « à mi-build le ventilateur hurle, le simulateur freeze, Slack ne répond plus ». La cause est rarement la version de Xcode : c'est que le build complet maintient la machine en charge élevée pendant 5 à 10 minutes. Refroidissement et mémoire unifiée sont pensés pour la mobilité, pas pour une compilation continue. Cet article compare « même projet, même commande, machines différentes » pour décider : upgrader le Mac local ou déporter les builds lourds vers un nœud cloud dédié ?

Méthode unifiée : éviter le « chacun compile à sa façon »

L'erreur classique en comparant des temps de build : des états machine différents — Chrome avec 40 onglets, reboot récent, DerivedData de la semaine dernière. Nous avons fixé cette baseline :

1. 01
   Même commit Git

   Les trois machines : git checkout v2.4.0-buildbench, Package.resolved verrouillé pour exclure le temps de résolution SPM.

2. 02
   Build en CLI, GUI fermée

   Pas de Product → Build dans Xcode : uniquement xcodebuild avec /usr/bin/time -l pour temps réel et pic mémoire.

3. 03
   Charge « bureau réaliste »

   MacBooks locaux : Slack + Chrome (8 onglets), simulateur arrêté. M4 cloud : session SSH + script de build — environnement CI sans surveillance.

4. 04
   Deux types de build

   Debug clean build (développement) et Release archive (release), durée et pages swap enregistrées séparément.

Exemple Debug : xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Debug clean build -destination 'generic/platform=iOS' -jobs 10. Chronométrage de l'entrée jusqu'à ** BUILD SUCCEEDED **, hors pod install et import de certificats.

Clean Build : temps réel M4 vs deux générations de MacBook

Médiane du build complet Debug ci-dessous. Le M4 cloud est ~15 % plus rapide que le M1 Pro local et plus du double du M2 Air — surtout parce que l'Air déclenche compression mémoire et swap vers la 3e minute, avec passage du CPU de ~3,4 GHz à ~2,6 GHz par surchauffe.

L'écart est plus marqué en Release Archive : optimisation plus agressive, phase de link plus gourmande. Le M2 Air atteint 4,1 Go de swap et près de 9 minutes ; sur le M4, tout reste sous 16 Go physiques — pas de ralentissement brutal en fin de build. Si vous faites au moins un Archive complet par semaine, l'écart se traduit en temps d'attente et en indisponibilité du portable.

Build incrémental : pourquoi le ressenti quotidien diffère du build complet

Nous avons aussi mesuré « un fichier Swift modifié, build incrémental » — le Cmd+B habituel. Les écarts se réduisent : M4 cloud 17 s, M1 Pro 22 s, M2 Air 38 s (Chrome en arrière-plan). Seuls les modules touchés sont recompilés ; le pic RAM reste sous 5 Go, pas de swap sur l'Air.

Conclusion : si 90 % du temps c'est de petites itérations, un Air 8 Go local suffit souvent. La douleur arrive en semaine de release, grosses mises à jour de dépendances ou premier build après changement de branche. Beaucoup d'équipes séparent « code local, build complet en CI » — mais les runners hébergés GitHub peuvent ajouter 20+ minutes de file d'attente aux heures de pointe, pire qu'un Air local. Un M4 cloud dédié pour les builds complets est une troisième voie entre « tenir sur le portable » et « file publique ».

Chauffe, ventilateur et travail en parallèle pendant la compilation

Compiler n'est pas qu'une question de chronomètre — cela impacte le workflow parallèle. Pendant le build complet : température et RPM ventilateur (sonde externe sur M4 mini, capteurs internes sur portables) :

Le M2 Air sans ventilateur réduit la fréquence sous charge prolongée — les 2 premières minutes proches du M1 Pro, puis la dérive vers 7 minutes au total. Le Mac mini cloud a une dissipation bureau : les 10 cœurs M4 tiennent haute fréquence plus longtemps. En pratique : lancer le build complet en SSH en arrière-plan, continuer à coder sur Windows/Linux, réunions, docs — sans se battre pour les ressources du portable.

16 Go de mémoire unifiée : la frontière entre confort et limite

Pic du build complet Debug ici ~12,4 Go — zone confortable sur 16 Go. Au-delà de ~200 000 lignes, ou avec Xcode + simulateur + Instruments ouverts, même 16 Go local devient juste : sur le même M1 Pro avec tests UI sur simulateur iOS 17 : pic 15,6 Go, 800 Mo swap, build de 4m 18s à 5m 44s.

Le M2 Air 8 Go touche le plafond vers 90 secondes — compression et pagination. Les logs memory_pressure regorgent d'événements vm_compressor ; les threads de compilation attendent la libération mémoire, le temps réel presque double. Ce n'est pas « Xcode mal optimisé », c'est la RAM physique — 16 Go sur le M4 cloud est le minimum sans swap pour beaucoup de projets iOS moyens, pas du surdimensionnement.

Reproduire le benchmark : script et pièges

Script minimal à exécuter en local et sur le nœud cloud, résultats en CSV pour comparaison. À la racine du projet, scripts/bench_clean_build.sh :

#!/bin/bash
set -euo pipefail
SCHEME="MyApp"
WORKSPACE="MyApp.xcworkspace"
rm -rf ~/Library/Developer/Xcode/DerivedData/*
/usr/bin/time -l xcodebuild -workspace "$WORKSPACE" -scheme "$SCHEME" -configuration Debug clean build -destination 'generic/platform=iOS' -jobs "$(sysctl -n hw.ncpu)" 2>&1 | tee /tmp/xcode_bench.log
grep -E 'real|maximum resident set size' /tmp/xcode_bench.log

Avant la première mesure sur une nouvelle machine : xcodebuild -runFirstLaunch ; vérifier xcode-select -p ; ne pas ouvrir l'interface Xcode pendant le chrono (SourceKit/indexation) ; sur le cloud, SSH + caffeinate -dims contre la veille (idem sur portable local). VNC pour observer uniquement — ne pas lancer Xcode GUI en VNC pendant un build CLI (+1–2 Go RAM).

Quand déporter le build complet vers le M4 cloud

Passer à un M4 Pro 32 Go coûte plusieurs milliers de dollars ; les pics de release ne représentent peut-être que quelques dizaines de jours par an. Si le problème est « un ou deux Archive par semaine rendent le portable brûlant sur les genoux », pas « 30 secondes à chaque sauvegarde », la location journalière d'un M4 dédié est souvent plus rationnelle : $21,1/jour, $57,1/semaine, $105,7/mois, sans engagement, mise en service 1–5 minutes, accès SSH et VNC navigateur.

Cinq nœuds PixVPS — Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, États-Unis (Est) — même tarif hardware. Depuis l'Europe, Singapour ou Hong Kong réduisent souvent la latence VNC ; collaboration US : Est américain. En SSH, le temps réel du build reste comparable au local — chaleur et bruit restent au datacenter. Intégration GitHub Actions self-hosted ou Fastlane : push local, xcodebuild archive cloud, récupération du .ipa ou envoi TestFlight (voir le guide pratique Xcode CI/CD sur Mac cloud).

Autre cas : PC Windows principal, missions iOS ponctuelles — pas besoin d'acheter un MacBook ; louer un M4 cloud deux jours en semaine de release, installer Xcode et certificats, libérer ensuite. 16 Go mémoire unifiée, 1 Gbps dédié, SLA 99,9 %, support humain 7×24, tickets ~1 h. Gros caches : SSD +1 To ($2,9/jour). Matrices multi-apps nocturnes : Thunderbolt 5 parallèle ($1,9/jour, 80 Gbps) — voir le test de cluster TB5.

Un build complet ne mesure pas « qui a le meilleur benchmark », mais qui livre en ~5 minutes de façon stable sans sacrifier le travail parallèle. Le MacBook reste le meilleur terminal de codage quotidien ; le nœud M4 cloud dédié décharge les pics de compilation — à la journée, sans acheter du hardware de pointe pour quelques dizaines de jours par an.