Pourquoi regarder le Clean Build plutôt que la compilation incrémentale
Au quotidien, une modification Swift ne recompile que les modules touchés — parfois une dizaine de secondes. Cette « compilation incrémentale » dépend fortement du cache ; les DerivedData d'une machine A ne servent pas sur B. Or plusieurs scénarios imposent un départ à zéro :
- Pipeline CI/CD vidant DerivedData à chaque job
- Changement de version Xcode ou upgrade macOS invalidant l'ancien cache
- Changement de poste de dev, aucun cache historique
- exécuter
xcodebuild clean buildouxcodebuild archiveun packaging Release
Le temps de clean build mesure donc vraiment si « cette machine tient une pipeline iOS ». La vitesse incrémentale reflète surtout habitudes de dev et fréquence de changements, pas le plafond matériel. Toutes les données ici viennent de clean build complets, même ligne de départ pour les trois machines.
Environnement de test et projet
Comparaison équitable : même projet, même Xcode, température ambiante proche ; trois tours par machine, médiane retenue.
Avant chaque tour : rm -rf ~/Library/Developer/Xcode/DerivedData
pour repartir de zéro.
Projet de test : app SwiftUI taille moyenne, ~92 000 lignes Swift, 2 Extension Targets (WidgetKit + Share Extension), ~5 800 fichiers Swift, ~12 Swift Packages locaux.
Version Xcode : Xcode 16.4, macOS 15.5 Sequoia (identique sur les trois machines).
Tours de test : 3 clean build + 3 Archive par machine, médiane. Clean build : xcodebuild clean build -scheme AppName -destination generic/platform=iOS ; Archive : xcodebuild clean archive -scheme AppName -archivePath /tmp/app.xcarchive.
Matériel : ① MacBook Air M2 (2022) · CPU 8 cœurs · 16 GB mémoire unifiée · 256 GB SSD ; ② MacBook Pro 14" M1 Pro (2021) · CPU 10 cœurs · 16 GB unifiée · 512 GB SSD ; ③ Mac mini M4 dédié VPSRox (2024) · CPU 10 cœurs (4 perf + 6 efficacité) · 16 GB unifiée · 256 GB NVMe · datacenter (nœud Hong Kong).
MacBook Air M2 en 8 cœurs (config la plus courante), pas la version 10 cœurs. MacBook Pro M1 Pro et VPSRox M4 Mini en 10 cœurs, pour comparer générations (M1 Pro vs M4) et impact thermique sur builds répétés.
Résultats chronométrés Clean Build intégral
Le tableau ci-dessous donne la médiane du temps réel (wall-clock) sur trois clean build, la pression mémoire maximale et le pic CPU rapporté par Xcode.
Les pics mémoire proviennent d'échantillons via memory_pressure et Activity Monitor pendant la compilation.
| Machine | CPU | Médiane Clean Build | Pic mémoire | Écart tour 3 vs tour 1 |
|---|---|---|---|---|
| MacBook Air M2 (8 cœurs) | M2 8 cœurs | 5m 42s | 11,8 GB (swap léger occasionnel) | +38 s (throttling thermique marqué) |
| MacBook Pro 14" M1 Pro (10 cœurs) | M1 Pro 10 cœurs | 4m 08s | 10,9 GB (sans swap) | +14 s (throttling thermique léger) |
| VPSRox Mac mini M4 (10 cœurs) | M4 10 cœurs | 3m 11s | 9,4 GB (sans swap) | +2 s (écart quasi nul) |
Colonne clé : « écart tour 3 vs tour 1 ». Sur Air M2, le 3e clean build est +38 s vs le 1er — dissipation passive sans ventilateur → throttling. MacBook Pro : +14 s. VPSRox M4 en rack : +2 s, bruit de mesure.
Pour un build isolé, le MacBook Pro M1 Pro est déjà très correct. En CI, ce qui compte n'est pas le premier chrono, mais la stabilité au 10e, au 50e build consécutif. L'écart de capacité thermique se multiplie alors.
Comparatif durée pipeline Archive
Archive se rapproche plus de la prod qu'un simple clean build : au-delà de la compilation, signature, bitcode (si activé), génération dSYM et empacotage des symboles. Sur le même projet, Archive prend en général 1,2–1,4× le temps d'un clean build.
| Machine | Médiane Archive | Surcoût vs Clean Build | Moyenne sur 5 exécutions (estimation) |
|---|---|---|---|
| MacBook Air M2 (8 cœurs) | 7m 18s | +1m 36s | env. 8 min 40 s (pénalisé par la chaleur) |
| MacBook Pro 14" M1 Pro (10 cœurs) | 5m 22s | +1m 14s | env. 5 min 45 s |
| VPSRox Mac mini M4 (10 cœurs) | 4m 06s | +55s | env. 4 min 10 s (très stable) |
Les données Archive montrent que le M4 accélère surtout dSYM et symboles, ~19 % de moins que M1 Pro, au-delà d'un simple gain linéaire de fréquence CPU. Lié à la bande passante mémoire et au Neural Engine sur l'architecture M4.
Avec Fastlane, chaque fastlane gym ≈ Archive + export complet :
~5 min 30 s sur M4 Mini, ~10 minutes sur Air M2 équivalent.
Plusieurs builds/jour (dev/staging/prod) : l'écart pèse sur le rythme de release.
Throttling thermique et pression mémoire : variables cachées du Mac local
Beaucoup de tests ne publient qu'un chrono à froid, en oubliant l'accumulation thermique. Apple Silicon réduit CPU/GPU quand la coque dépasse un seuil, jusqu'à ce que la dissipation suive. Impact maximal sur MacBook Air sans ventilateur.
Observation du throttling sur MacBook Air M2
Air M2 : dessous du châssis nettement chaud après le 2e clean build (~11 min).
pmset -g thermlog : CPU_Speed_Limit de 100 à ~78, 3e build +30 s vs le 1er.
CI en rafale sur Air : +15 %–30 % vs froid, difficile à prédire.
Limites du refroidissement actif du MacBook Pro M1 Pro
Le refroidissement actif du MacBook Pro aide beaucoup, sans immuniser totalement. Au-delà de ~28 °C intérieur, ou avec plusieurs Simulateurs ouverts, un léger throttling peut apparaître. Nos +14 s viennent surtout du tour 3 plus chaud ; à 22 °C contrôlé, l'écart tombe à ~8 s.
Stabilité thermique en datacenter
Nœud VPSRox en rack datacenter (18–22 °C) avec ventilateur actif sur Mac mini M4. Stabilité des durées bien supérieure à un portable : écart tour 1 vs 3 de 2 s seulement. Pour CI, prédire la fenêtre de build (p99) sans craindre un timeout surprise.
MacBook Air près d'une fenêtre, été >27 °C : le throttling arrive plus tôt et plus fort. En hiver, la même machine peut être 20 %–30 % plus rapide. Mesurez sur votre environnement réel, pas sur des chiffres de labo à température constante.
Impact du pic mémoire et des écritures swap sur la vitesse
Sur 16 GB unifiée, la pression mémoire est réelle sur de gros projets iOS.
Xcode lance plusieurs outils en link et signature ; le compilateur Swift est gourmand.
Validation croisée avec vm_stat et memory_pressure.
Air M2 : pic ~11,8 GB, swap bref (~200–400 MB) quand les 2 Extensions compilent en parallèle. M1 Pro : ~10,9 GB, pas de swap sur 3 tours. M4 Mini VPSRox : ~9,4 GB — M4 optimise copies et objets intermédiaires pour la même tâche.
| Machine | Pic mémoire | Swap déclenché ? | Pic CPU en phase de compilation | Volume écriture SSD (Clean Build) |
|---|---|---|---|---|
| MacBook Air M2 | 11.8 GB | Oui (~300 Mo) | env. 780 % (~8 cœurs saturés) | env. 4,2 Go |
| MacBook Pro M1 Pro | 10.9 GB | Non | env. 980 % (proche de 10 cœurs saturés) | env. 3,8 Go |
| VPSRox Mac mini M4 | 9.4 GB | Non | env. 960 % (proche de 10 cœurs saturés) | env. 3,5 Go |
Projets >200 000 lignes ou plus de Swift Packages : 16 GB sur Air M2 sature plus vite. VPSRox propose extension SSD (+1 TB $2.6/jour, +2 TB $5.2/jour), pas encore plus de 16 GB RAM — à anticiper au choix.
Quand un MacBook local reste suffisant
Toutes les équipes n'ont pas besoin d'un nœud cloud ; dans les cas suivants, votre MacBook suffit :
- Projet modeste (< 30 000 lignes Swift) : clean build en moins de 2 min sur tout MacBook Apple Silicon — pas de goulot.
- CI peu fréquente (< 5 builds/jour) : même à 7–8 min par clean build, le total journalier reste sous 40 min — acceptable.
- Indépendant solo, debug local principal : l'incrémental suffit le plus souvent ; clean build surtout en release — M1 Pro+ convient.
- Utilisateur MacBook Pro M3/M4 : MacBook Pro M4 Max récent ≈ Mac mini M4 en perf ; l'écart est surtout la stabilité en builds continus, pas un seul run.
Les cas où un nœud cloud mérite une analyse sérieuse : CI déclenchée plus de 20 fois/jour, environnement de build partagé (éviter le « ça marche sur ma machine »), MacBook Air avec projet qui grossit, ou plusieurs projets isolés en parallèle.
Synthèse : comment arbitrer coût et gain
Le coût d'un Mac cloud est évident : Mac mini M4 dédié VPSRox à $21.8/jour, ~$109.1/mois en usage continu, moins qu'un nouveau MacBook Pro, mais dépense récurrente. Mais que gagnez-vous en échange ?
Équipe iOS de 5 : ~30 clean build/Archive/jour. Air M2 : ~8 min/build (léger throttling) → 240 min. M4 Mini VPSRox : ~123 min. ~117 min économisées/jour ; en CI multi-branches, retour review et fenêtres de release plus rapides.
Coût caché : l'attention pendant l'attente. Sous 5 minutes, on regarde souvent la barre ; au-delà de 8 minutes, on bascule ailleurs. Reprendre le flow après interruption coûte ~20 minutes selon les études. ~$109/mois ressemble alors à un coût de focus, pas seulement à une location serveur.
Combinaison où le cloud vaut la peine : projet > 50 000 lignes + MacBook Air + CI > 15 builds/jour — les trois critères réunis.
Priorité upgrade Mac local : travail surtout en debug local (pas CI) + projet taille moyenne + budget serré — un MacBook Pro M4 peut être plus pertinent qu'une location cloud.
Combinaison complémentaire : MacBook local pour compilation incrémentale et debug, pipeline CI sur nœud cloud dédié — rôles distincts, sans interférence.
Remplacer un Mac local instable thermiquement par un M4 cloud
VPSRox propose des Mac mini M4 dédiés en datacenter, sans throttling thermique, machine physique exclusive, location à la journée sans engagement. Livraison automatique 1–5 minutes après paiement, cinq nœuds mondiaux.