Clean build Xcode en conditions réelles : MacBook local ou nœud M4 cloud dédié — lequel gagne ?

Pourquoi les builds sur MacBook local ralentissent

Beaucoup d'indés et de petites équipes travaillent sur MacBook Air ou MacBook Pro d'entrée de gamme — portable et sobre en énergie, mais souvent limité à 8 ou 16 Go de RAM. Avec Xcode, le Simulator, une douzaine d'onglets Chrome, Slack et Preview ouverts, il reste peu de mémoire physique pour swift-frontend et ld. macOS commence à évacuer DerivedData et les caches d'index vers le SSD. On a l'impression d'« attendre quelques minutes de plus », mais en réalité la bande passante mémoire est absorbée par le swap, et chaque build incrémental suivant s'alourdit un peu.

Un facteur souvent ignoré : la limitation thermique. Le refroidissement d'un portable a des limites ; après 8 à 15 minutes de build complet, la fréquence CPU peut chuter de 15 à 25 %, et le bruit des ventilateurs perturbe les visioconférences. Un Mac mini en baie de datacenter refroidit de façon stable — idéal comme machine de build dédiée, pendant que le portable reste libre pour l'édition et les réunions.

Cet article répond à une question précise : à l'échelle d'un projet réaliste, combien gagne-t-on en déplaçant la compilation sur un nœud M4 SpinMac dédié ? Quel coût ? Dans quels cas le cloud n'en vaut pas la peine ?

Environnement de test et méthodologie

Pour la reproductibilité : même version de Xcode, même procédure de purge DerivedData, chronométrage via xcodebuild et /usr/bin/time -l afin d'écarter l'indexation GUI et les tâches de fond. Avant chaque série : rm -rf ~/Library/Developer/Xcode/DerivedData/*, applications non essentielles fermées.

Application test : « PulseTrack », app SwiftUI interne — environ 82 000 lignes Swift, quatre targets (app principale, Share Extension, Widget Extension, Watch App), six dépendances SPM (dont Alamofire, Kingfisher). Taille moyenne pour l'App Store — pas un monorepo géant, mais assez pour stresser une machine 8 Go.

Trois scénarios de build et commandes

Trois situations quotidiennes, de l'itération au déploiement sur l'App Store.

Scénario 1 : clean build complet (Debug)

Simule le premier checkout CI ou un démarrage à froid après changement de branche :

xcodebuild -scheme PulseTrack -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 16 Pro' clean build CODE_SIGNING_ALLOWED=NO

Signature désactivée pour isoler la compilation. Trois exécutions par machine, médiane retenue.

Scénario 2 : build incrémental sur un seul fichier

Modification d'un fichier Swift (~40 lignes de logique UI), puis build sans clean. Action la plus fréquente au quotidien, très sensible à la RAM libre et à l'état de l'index.

Scénario 3 : Release Archive

Archive complète avec certificat Distribution, optimisation (-O) et retrait du bitcode. Charge CPU la plus longue — scénario typique de throttling sur portable.

Comparaison des durées : données clés

Médiane sur trois séries ci-dessous. Le M4 cloud mène dans les trois cas ; l'écart est maximal sur l'Archive — les passes d'optimisation exigent une charge soutenue, et le refroidissement en rack maintient les fréquences.

Sur l'Air M2, un swap marqué apparaît vers la sixième minute du clean build (system-wide memory free percentage à 4 % dans memory_pressure). L'utilisation CPU agrégée de swift-frontend passe d'environ 680 % à 420 % — ce n'est pas Xcode qui ralentit, c'est le noyau qui pagine. Le M4 cloud a conservé les dix cœurs entre 85 et 92 % sans throttling enregistré.

Le M1 Pro 16 Go local n'était que ~34 % plus lent que le M4 cloud en clean build — bien moins que le facteur 2,2 de l'Air 8 Go. La capacité mémoire devient souvent le goulot avant la génération de puce. Avec 16 Go en local, l'intérêt du cloud se déplace de la « vitesse brute » vers « build dédié, zéro interférence au quotidien ».

Charge parallèle : Simulator ouvert pendant le build

Le tableau précédent décrit un bureau « propre ». En pratique : Simulator pour prévisualiser l'UI pendant un rebuild complet (changement de configuration, purge DerivedData, etc.).

Sous cette charge combinée, le Simulator Air M2 descend souvent sous 20 ips, et le clean build passe de 11′42″ à 14′28″. M1 Pro : 8′45″ — acceptable. M4 cloud avec prévisualisation Simulator en VNC : seulement ~40 s de plus (5′58″), car les deux charges disposent de RAM et CPU sans se disputer 8 Go.

Après trois clean builds, DerivedData sur l'Air atteint 4,7 Go — acceptable sur SSD 256 Go, mais avec 8 Go RAM le cache d'index rivalise avec les artefacts de build. Les nœuds cloud proposent une extension SSD +1 To (à partir de 2,5 $/jour) pour les équipes qui gardent plusieurs caches de branches.

Pièges qui invalident une comparaison

Si ces détails divergent, les résultats peuvent varier de 30 % ou plus :

1. 01
   Builder avant la fin de l'indexation

   À la première ouverture, l'indexation en arrière-plan peut consommer 2 à 4 Go. Attendre la fin ou utiliser xcodebuild pour éviter le bruit GUI.

2. 02
   Paramètres Build System différents

   Des deux côtés : New Build System et même COMPILER_INDEX_STORE_ENABLE, sinon les durées incrémentales ne sont pas comparables.

3. 03
   Synchronisation des sources vers le cloud

   rsync --delete pour un workspace cohérent. Ne pas compiler depuis un disque cloud monté en FUSE — l'I/O réseau devient un goulot invisible.

4. 04
   Architecture du simulateur

   Simulateur Apple Silicon en arm64 par défaut. Construire aussi en x86_64 sur une seule machine peut presque doubler le temps.

Workflow de build à distance : développer en local, compiler dans le cloud

Avec 8 Go ou un portable 16 Go entre réunions et développement, inutile de vendre la machine pour un Mac Studio. Approche pragmatique : déporter compilation Xcode et charge Simulator vers le cloud, garder éditeur et Git en local.

Scénario classique : démo à 15 h, un collègue pousse une branche nécessitant un rebuild complet, ventilateurs à fond, Zoom saccadé — ce n'est pas un problème de compétence, mais de ressources partagées. Nœud M4 cloud à partir de 21,2 $/jour : activé la semaine de release, éteint sinon — souvent moins cher qu'un upgrade matériel.

1. 01
   Provisionner un nœud SpinMac

   Choisir la région (Singapour / Japon Tokyo / Corée Séoul / Hong Kong / États-Unis Est). SSH et VNC en 1 à 5 minutes. Voir le centre d'aide.

2. 02
   Synchroniser code et dépendances

   Premier envoi : rsync -avz --exclude DerivedData ./ user@host:~/PulseTrack/. Résoudre SPM sur le nœud avec xcodebuild -resolvePackageDependencies.

3. 03
   Éditer en local ou en SSH, builder à distance

   VS Code Remote SSH ou Cursor Remote ; commandes de build en session SSH. Aperçu UI via VNC navigateur et Simulator si besoin.

4. 04
   Attacher comme runner CI (optionnel)

   Même nœud en GitHub Actions self-hosted runner. Étapes dans le guide CI/CD Xcode sur Mac cloud.

Les cinq régions offrent 1 Gbps dédié et IPv4 publique. Depuis un bureau en France vers Singapour : rsync incrémental d'environ 120 fichiers modifiés en 4 à 8 secondes — négligeable pour les workflows incrémentaux. Public APAC : Singapour ou Japon ; marché US : États-Unis Est.

Coût et pertinence : quand le cloud vaut le coup

Calcul rapide : un clean build de 12 à 5 minutes, six builds par jour → ~42 minutes gagnées. Au tarif horaire d'un développeur, une demi-journée peut couvrir 21,2 $ de nœud — sans compter ventilateurs, qualité d'appel et batterie. Le cloud ne remplace pas le portable : il donne aux builds une machine physique dédiée, sans interruption.

Pour automatiser le pipeline, voir le guide GitHub Actions et Jenkins. Archives parallèles sur plusieurs machines : benchmark cluster Thunderbolt 5.