Test compilation Xcode : MacBook local vs nœud M4 dédié cloud

Pourquoi ce comparatif ?

Dans le monde du développement iOS, les compilations lentes sont un sujet quasi universel. L'analyse sémantique du frontend Swift, la construction du graphe de dépendances des modules, le traitement de binaires volumineux par le linker — chaque étape sollicite CPU et mémoire. Pour un développeur solo, la machine la plus courante reste le MacBook Air : léger, autonome, mais souvent limité par 8 Go de RAM et un refroidissement passif face à une compilation Xcode complète.

La location de Mac dans le cloud n'est pas nouvelle, mais beaucoup d'offres reposent sur de la virtualisation ou de l'hébergement partagé, avec un écart fréquent entre les promesses marketing et la réalité. ZilCloud propose un Mac mini M4 physique dédié — sans couche de virtualisation, sans survente — aux spécifications officielles : CPU 10 cœurs (4 performance + 6 efficacité), 16 Go de mémoire unifiée, SSD NVMe 256 Go, bande passante publique dédiée 1 Gbps.

La question que nous voulions trancher : si je ne change pas mon ordinateur local, combien de temps gagne-t-on en déléguant la compilation à un nœud M4 cloud ? La boucle de développement quotidienne devient-elle plus fluide ? Le coût et l'expérience en valent-ils la peine ? Toutes les données ci-dessous proviennent de la même machine de test, des mêmes scripts et de la même version de Xcode — reproductibles.

Projet de test et méthodologie

L'objet du test est une application SwiftUI de niveau commercial (nommée RetailApp), avec la volumétrie suivante :

environ 186 modules Swift (dont 3 Swift Packages locaux et 2 dépendances CocoaPods), plus de 1 240 fichiers sources, binaire lié d'environ 84 Mo en configuration Release. Le projet active la vérification stricte de concurrence Swift 6, ainsi que des scripts de build SwiftLint et SwiftFormat. Pour un développeur indépendant, c'est déjà un projet de taille moyenne à grande ; sur une machine 8 Go, la compilation à froid déclenche souvent une pression mémoire marquée.

Commande de compilation unifiée

Pour éviter les écarts liés à l'interface graphique, tous les chronométrages passent par xcodebuild en ligne de commande, avec /usr/bin/time -l pour le temps mur et le pic mémoire :

# Clean build folder first
xcodebuild -project RetailApp.xcodeproj \
  -scheme RetailApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  clean build \
  CODE_SIGNING_ALLOWED=NO \
  | tee /tmp/xcodebuild.log

# Wall-clock timing wrapper
/usr/bin/time -l xcodebuild -project RetailApp.xcodeproj \
  -scheme RetailApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  build CODE_SIGNING_ALLOWED=NO

Avant chaque série, nous exécutons sudo purge pour vider le cache fichiers ; trois compilations à froid consécutives, médiane retenue. Pour l'incrémentale, modification d'un seul fichier View (~120 lignes SwiftUI) puis build sans clean, également en médiane sur 3 runs. Spotlight et applications de fond sont désactivés ; mode économie d'énergie OFF sur le portable ; courbe ventilateur enregistrée via powermetrics.

Workflow de compilation distante

Sur le nœud cloud, le code est cloné via git clone (dépôt ~380 Mo), les dépendances installées avec pod install et swift package resolve — environnement identique des deux côtés. En développement, on peut lancer xcodebuild en SSH sur le cloud, ou éditer depuis le MacBook avec VS Code Remote SSH : la compilation tourne à distance, le portable ne fait qu'écrire du code et lire les logs.

Compilation à froid (Clean Build) : données mesurées

La compilation à froid est le scénario qui creuse le plus l'écart : pas de cache Derived Data, frontend Swift, backend Clang et linker à pleine charge. Voici les médianes (avec un groupe témoin local : MacBook Pro M3 Pro 18 Go d'un collègue, pour simuler un « upgrade matériel ») :

Le M4 cloud est environ 2,18× plus rapide que le MacBook Air M2, et même ~20 % devant un MacBook Pro M3 Pro 18 Go. L'écart ne vient pas seulement de la génération de puce : les 8 Go de l'Air déclenchent 4,2 Go de swap au pic ; powermetrics montre les cœurs performance passer de 3,4 GHz à ~2,6 GHz vers la 6e minute (mur thermique). Le Mac mini M4, refroidi en datacenter, maintient la fréquence ; les 10 cœurs tournent quasi à plein, sans swap sur 16 Go.

Côté ressenti : sur l'Air, le ventilateur monte au maximum en moins de 2 minutes, le clavier chauffe, difficile de continuer à coder confortablement. Sur le cloud, la compilation est entièrement distante : le portable reste silencieux et frais, on peut consulter la doc ou rejoindre une visio en parallèle.

Compilation incrémentale et boucle de développement

Au quotidien, l'incrémentale est bien plus fréquente que le clean build. Modifier une vue SwiftUI puis relancer un build mesure mieux si la boucle de dev reste fluide :

L'écart est un peu moindre qu'en clean build, mais le M4 cloud reste en tête sur chaque scénario. Les modifications de Bridging Header — typiques des migrations Objective-C — illustrent bien le cas : près de 13 minutes sur l'Air, 5 min 19 s sur le cloud.

Chaleur, bruit et stabilité

La performance ne se résume pas à « quelques secondes de gagnées » : la machine doit tenir la distance. Nous avons enchaîné 8 clean builds en 2 heures (un toutes les 15 minutes) :

L'Air subit un throttling thermique net : le 8e run est 21 % plus lent que le 1er, le swap passant de 4,2 Go à 6,1 Go. Le Mac mini M4 cloud varie de moins de 2 %, en ligne avec le SLA 99,9 % annoncé par ZilCloud — pour du CI long ou des Archives en série, la stabilité compte autant que la vitesse brute.

Simulateur et Archive

Outre le build classique, deux scénarios fréquents ont été testés :

Démarrage simulateur iOS + installation : sur le M4 cloud, lancer le simulateur iPhone 16 Pro et installer le binaire Release de RetailApp prend environ 38 secondes du xcrun simctl boot au premier écran ; sur l'Air M2, ~52 secondes, et le simulateur sature encore la RAM. Le VNC navigateur permet une validation UI rapide ; pour des animations fluides, un client VNC tiers est préférable.

Archive et export IPA : xcodebuild archive + -exportArchive sur le cloud en 14 min 22 s (signature incluse) ; sur l'Air M2, 28 min 51 s. Les certificats s'importent comme en local (export Keychain .p12 + provisioning profile). L'IPA repart en scp ou part directement vers TestFlight ; depuis Singapour, latence vers les serveurs Apple ~180 ms, upload 84 Mo en ~3 minutes.

Coûts et stratégies d'usage

Les chiffres de perf ne suffisent pas : le coût détermine l'adoption. ZilCloud facture à la journée : Mac mini M4 standard 20,9 $/jour, 103,9 $/mois, sans engagement. Quelques profils typiques issus de ce test :

Stratégie A — Nœud compilation (à la journée) : louer uniquement les jours de clean build, packaging ou tests d'intégration — par ex. 2 jours/semaine → ~20,9 $ × 8 ≈ 167 $/mois, avec plus de 11 minutes gagnées par clean build et un Air libéré.

Stratégie B — Nœud CI permanent (au mois) : Webhook Git déclenchant xcodebuild test à chaque push, 103,9 $/mois. Comparé à GitHub Actions macOS (~0,08 $/minute, un clean build 20 min ≈ 1,6 $), une équipe active amortit en une semaine.

Stratégie C — Sprint court (à la semaine) : 55,9 $/semaine avant une release, pour migrations, refactors massifs et soumission TestFlight ; libération du nœud ensuite, zéro coût d'inactivité.

Avec un M3 Pro local et ≥ 18 Go de RAM, l'avantage cloud se joue surtout sur la libération du poste et le CI parallèle. Pour les utilisateurs de MacBook Air 8 Go / 16 Go, le M4 cloud est souvent le meilleur rapport perf/prix — un Mac mini M4 neuf démarre à 599 $, sans écran ni maintenance.

GitHub Actions vs CI maison

Beaucoup d'équipes utilisent déjà le runner macos-latest de GitHub Actions. Nous avons poussé le même projet sur un dépôt privé pour comparer :

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Install deps
        run: pod install --repo-update
      - name: Build
        run: xcodebuild ... clean build

Le pipeline Actions a totalisé 34 min 20 s (file d'attente + deps + compilation) : ~8 min d'attente, 6 min de pod install, un peu plus de 20 min de build. Sur ZilCloud, Derived Data et cache CocoaPods persistent sur le disque local : à partir du 2e run, le pipeline descend sous 12 minutes, sans file.

Actions excelle dans l'intégration GitHub et l'absence d'ops ; en revanche, performances variables sur runners partagés, démarrage à froid lent, cache limité, files longues aux heures de pointe. Les deux approches coexistent souvent : Actions pour lint et tests unitaires, Archive Release sur un nœud ZilCloud dédié.

Développement distant : retours et pièges

Déporter la compilation change le workflow. Voici ce que nous en retenons :

Édition SSH + build cloud (recommandé) : VS Code ou Cursor en Remote SSH, LSP côté distant, xcodebuild dans le terminal après sauvegarde. La latence réseau est imperceptible à la frappe (Singapour depuis la France ~200–250 ms en jeu réel, depuis l'Asie du Sud-Est ~40 ms) ; pour les gros binaires Git, préférez git-lfs.

VNC navigateur : ouverture en un clic depuis la console ZilCloud, pratique pour l'UI Xcode ou le simulateur. Suffisant pour des écrans statiques ; pour le debug d'animations, RealVNC ou équivalent.

Piège 1 — Certificats Keychain : à la première signature cloud, importer .p12 et provisioning profile ; autoriser codesign sur la clé privée, sinon errSecInternalComponent.

Piège 2 — Chemin des outils Xcode : sur un nœud neuf, parfois sudo xcode-select -s /Applications/Xcode.app est nécessaire, sinon xcodebuild pointe vers les Command Line Tools et le SDK manque.

Piège 3 — Fuseau horaire : le nœud est souvent en UTC ; pour des logs CI alignés avec l'équipe, sudo systemsetup -settimezone Europe/Paris (ou le fuseau de votre région).

Un MacBook local suffit-il encore ?

Après ces chiffres, une question légitime : ne peut-on pas rester sur le portable en optimisant le projet ou en montant en gamme ?

Un MacBook Pro M4 Pro 36 Go règle fondamentalement mémoire et thermique — mais à partir d'environ 2 499 $, et une compilation complète monopolise quand même la machine ; difficile d'enchaîner Figma, Slack et Zoom confortablement. Pour un solo ou une petite équipe, l'investissement n'est pas évident.

AWS EC2 Mac propose du matériel Apple officiel, mais à ~1,083 $/heure et un minimum de 24 h (~26 $/jour), plus cher que les 20,9 $/jour ZilCloud, sans flexibilité journalière ni extension Thunderbolt 5. La mise en service et les quotas pèsent aussi : ZilCloud s'active en 1 à 5 minutes après paiement, mieux adapté aux projets ponctuels.

GitHub Actions, Bitrise et CI mutualisés conviennent aux pipelines standardisés, mais moins au contrôle fin (clean build, cache persistant, simulateur interactif) ; 10 à 20 minutes de file aux heures de release ne sont pas rares — un coût réel le jour J.

Le Mac mini M4 cloud ZilCloud se positionne clairement : garder son poste local, obtenir à la demande une machine de compilation toujours à plein régime. CPU 10 cœurs dédié, 16 Go unifiés, 1 Gbps dédié, cinq nœuds (Singapour / Tokyo / Séoul / Hong Kong / États-Unis Est), à partir de 20,9 $/jour, sans survente ni voisin bruyant. Louer une semaine de sprint ou un mois de CI, puis libérer — une flexibilité qu'un nouvel achat Mac ou un contrat cloud long n'offrent pas.

Le MacBook Air peut toujours développer iOS ; quand le projet grossit, déléguer la compilation au M4 cloud et garder silence et autonomie sur le portable est souvent le meilleur compromis coût/efficacité aujourd'hui.