Xcode 26 compile trop lentement : comment accélérer un Mac distant en 2026 ?

Une compilation Xcode 26 s’éternise, tandis qu’un simple changement de code déclenche plusieurs tâches sans rapport apparent.

Le gagnant dépend du goulot d’étranglement : mesurez d’abord avec Build Timing Summary, corrigez les dépendances et les scripts répétitifs, puis envisagez un Mac distant plus puissant uniquement si le processeur, la mémoire ou le stockage restent saturés.

Cette méthode s’adresse aux développeurs indépendants qui lancent de nombreuses compilations incrémentales et veulent raccourcir le délai entre une modification et son retour à l’écran. Elle concerne également les petites équipes qui exécutent des archives Release, des tests automatisés ou une intégration continue sur un Mac distant, mais hésitent encore à augmenter leur configuration.

Le diagnostic par scénario est plus fiable qu’un chronomètre unique

Dire que « Xcode 26 compile trop lentement » ne décrit pas encore un problème exploitable. Une première compilation après récupération du dépôt peut inclure la résolution et le téléchargement de dépendances. Une compilation incrémentale peut recompresser des ressources ou relancer un script. Une archive peut surtout attendre l’édition de liens, la génération de symboles ou la signature.

Ces situations ne doivent pas être mélangées. Le même projet peut être rapide après une modification locale, lent lors d’un premier passage sur un Mac distant et encore plus lent pendant une archive Release. Le remède n’est donc pas identique.

Scénario observé	Ce qu’il faut isoler	Première action raisonnable	Mauvaise conclusion à éviter
Première compilation après synchronisation	Dépendances Swift Package, scripts de préparation, téléchargement d’artefacts	Vérifier le dépôt et le fichier `Package.resolved`	Accuser immédiatement le processeur
Compilation incrémentale	Fichiers Swift recompilés, relations entre Targets, génération de code	Examiner Build Timing Summary et les dépendances de Target	Vider systématiquement `DerivedData`
Archive Release	Compilation, édition de liens, ressources, symboles, signature et scripts	Comparer chaque étape de l’archive	Comparer uniquement le temps total
Tests unitaires	Compilation de la cible de test et exécution des tests	Séparer build et exécution	Attribuer toute l’attente à Xcode
Tests d’interface	Lancement du simulateur, installation, scénarios et ressources	Ajuster progressivement le parallélisme	Croire que davantage de simulateurs accélère toujours le résultat

La documentation d’Apple sur l’amélioration de la vitesse des compilations incrémentales recommande précisément d’observer ce qui est recompilé, plutôt que de traiter chaque attente comme une limite matérielle.

Comment trouver la tâche qui ralentit réellement la compilation

Afficher Build Timing Summary au lieu de regarder seulement la barre de progression

Le Build Timing Summary sert à repérer les tâches qui occupent le plus de temps dans une compilation. Selon le mode utilisé, le résultat peut être consulté dans les rapports de compilation ou obtenu avec xcodebuild. L’objectif n’est pas de collecter une mesure isolée, mais d’identifier les mêmes tâches sur un commit, un Scheme et une configuration inchangés.

Pour une mesure en ligne de commande, utilisez des valeurs de remplacement explicites :

xcodebuild \
  -workspace "<CHEMIN_VERS_WORKSPACE>" \
  -scheme "<NOM_DU_SCHEME>" \
  -configuration "<CONFIGURATION>" \
  -destination 'platform=iOS Simulator,id=<IDENTIFIANT_SIMULATEUR>' \
  -showBuildTimingSummary \
  build

La sortie doit être conservée avec le commit testé. Un exemple de structure à archiver peut rester volontairement abstrait :

Build Timing Summary
CompileSwiftSources: <DUREE>
Linking: <DUREE>
PhaseScriptExecution <NOM_DU_SCRIPT>: <DUREE>
ProcessInfoPlistFile: <DUREE>

Les noms de tâches sont plus importants que le total. Une longue phase CompileSwiftSources oriente vers le code et les relations de compilation. Une phase PhaseScriptExecution répétée oriente vers un script. Une attente de téléchargement ou de résolution ne doit pas être classée comme compilation native.

La référence Apple consacrée aux bonnes pratiques de code pour améliorer l’efficacité des compilations constitue le point de départ pour examiner les fichiers Swift qui forcent trop souvent une recompilation.

Construire une base comparable

Pour obtenir une comparaison utile, conservez le même commit, le même Scheme, la même configuration et la même destination. Notez séparément :

la première compilation après ouverture du projet ;
la compilation incrémentale après une petite modification ;
l’exécution des tests ;
l’archive Release ;
la récupération ou la résolution des dépendances.

Il faut également noter si le dépôt vient d’être cloné, si les Swift Packages sont déjà présents et si le Mac distant est utilisé par une autre tâche. Une connexion lente peut allonger la préparation sans ralentir le compilateur lui-même.

Un résultat exploitable contient le nom de la tâche, sa durée, son contexte et son statut. Sans ces éléments, le « gain » observé après une modification peut simplement venir d’un cache déjà rempli.

Compilation incrémentale : corriger le projet avant de changer de machine

Un Target trop large déclenche des travaux inutiles

Une petite modification ne devrait pas entraîner la reconstruction d’une partie sans rapport de l’application. Il faut donc vérifier les relations entre Targets, les dépendances de compilation et les phases de copie ou de traitement des ressources. La documentation Apple sur la configuration d’un nouveau Target aide à contrôler cette organisation.

Les symptômes fréquents sont les suivants :

une cible de test reconstruite après chaque modification d’une ressource sans lien ;
une cible d’extension appelée par une relation de dépendance trop large ;
des fichiers générés relancés alors que leur entrée n’a pas changé ;
une phase de script configurée pour s’exécuter à chaque compilation ;
des symboles ou types trop largement exposés, qui augmentent la surface à analyser.

Chaque correction doit être validée par une nouvelle compilation incrémentale comparable. Il ne suffit pas de constater que la liste des tâches paraît plus courte.

Pourquoi vider DerivedData ne rend pas durablement la compilation plus rapide

DerivedData contient des résultats intermédiaires utiles aux compilations suivantes. Le supprimer peut résoudre un cache incohérent, un index endommagé ou un résultat obsolète. En revanche, cette suppression force souvent une reconstruction complète ou partielle. Elle peut donc rendre la prochaine compilation plus longue.

La règle opérationnelle est simple : ne supprimez DerivedData qu’après avoir identifié un comportement de cache anormal, puis mesurez la compilation suivante et celle qui suit. Si le projet est simplement lent à chaque modification, la cause est probablement à chercher dans les Targets, les fichiers Swift, les scripts ou les dépendances.

La séquence ci-dessous évite le nettoyage réflexe :

xcodebuild \
  -workspace "<CHEMIN_VERS_WORKSPACE>" \
  -scheme "<NOM_DU_SCHEME>" \
  -configuration "<CONFIGURATION>" \
  -destination 'platform=iOS Simulator,id=<IDENTIFIANT_SIMULATEUR>' \
  build \
  -showBuildTimingSummary

Conservez d’abord le résultat. Nettoyez ensuite uniquement si un cache corrompu est plausible. Une différence entre la première et la seconde exécution est souvent plus instructive qu’un seul chronomètre.

Archive Release : distinguer compilation, édition de liens et scripts

Une archive lente n’est pas nécessairement une compilation lente. Le parcours Release peut inclure la préparation des dépendances, la compilation des sources, l’édition de liens, le traitement des ressources, la génération des symboles, la signature et un script de distribution.

La documentation Apple sur la distribution des applications pour les tests bêta et les versions publiées rappelle que la production d’une version distribuable ne se limite pas à compiler les fichiers Swift.

Quand Debug est rapide mais Release reste lent

Cette différence doit orienter l’enquête vers les paramètres et les étapes propres à Release :

optimisation du code ;
nombre de Targets inclus ;
traitement des symboles ;
copie de ressources ;
scripts d’archive ou de distribution ;
signature et préparation des artefacts.

Il faut comparer les tâches, pas seulement les configurations. Si CompileSwiftSources reste stable mais qu’une phase de script augmente, changer de Mac ne supprimera pas la répétition du script. À l’inverse, si l’édition de liens ou la compilation monopolise durablement le processeur, une machine distante mieux dimensionnée peut devenir pertinente.

Pour un pipeline automatisé, stockez le journal d’archive avec le commit et le type de tâche. La comparaison entre deux archives construites avec les mêmes entrées permet de séparer une amélioration du projet d’un simple effet de cache.

Dépendances et nouvel environnement : rendre le build reproductible

Swift Package et résolution répétée

Sur un Mac distant ou dans une intégration continue, un environnement nouvellement préparé peut relancer la résolution des Swift Packages. Le fichier Package.resolved doit être versionné et contrôlé avec le projet. Il fixe les versions attendues ; il ne remplace toutefois pas l’accès réseau ni l’authentification des dépendances privées.

La documentation Apple sur les Swift Packages dans les flux d’intégration continue permet de vérifier la préparation du dépôt et les conditions nécessaires au build.

Avant de modifier la configuration du Mac, séparez trois erreurs :

la résolution échoue parce qu’une version n’est plus disponible ou n’est pas compatible ;
la résolution réussit mais le téléchargement est lent ;
les dépendances sont disponibles, mais leur compilation est longue.

Ces cas exigent des actions différentes. Pour le premier, contrôlez les versions et Package.resolved. Pour le second, vérifiez l’accès au dépôt, les dépendances privées et le réseau. Pour le troisième, mesurez la compilation des packages et leur réutilisation entre les tâches.

Un environnement propre ne doit pas être confondu avec un environnement sans cache. Les fichiers de résolution doivent être suivis dans le dépôt. Les caches peuvent être conservés s’ils sont reconstruisibles et liés à une version connue du projet. Les artefacts impossibles à retracer ne doivent pas masquer une dépendance manquante.

Tests et simulateur : plus de parallélisme ne signifie pas toujours plus de vitesse

Les tests unitaires, les tests d’interface, la compilation et le démarrage du simulateur consomment des ressources différentes. Il faut donc mesurer le build seul, puis l’exécution seule, avant de modifier le parallélisme.

La documentation Apple sur l’exécution d’une application sur des appareils simulés ou physiques aide à distinguer la destination, l’installation et l’exécution. Pour l’organisation des suites, consultez également les recommandations Apple sur les tests conçus pour améliorer le retour d’information.

Le parallélisme doit être ajusté contre la mémoire et les échecs

Lancer davantage de tests simultanément peut réduire le temps d’attente lorsque le processeur et la mémoire disposent encore d’une marge. Mais plusieurs simulateurs peuvent aussi provoquer une pression mémoire, des échanges avec le stockage, des démarrages plus lents ou des échecs intermittents.

Procédez par paliers :

exécutez une suite représentative avec le parallélisme actuel ;
augmentez progressivement le nombre de destinations ou de tests simultanés ;
mesurez le temps total, la stabilité et les échecs ;
revenez au niveau précédent si le temps global ou le taux d’échec se dégrade.

Pour le développement quotidien, privilégiez une suite courte donnant rapidement un retour sur les zones modifiées. Réservez la suite complète, l’archive et les scénarios d’interface à une tâche séparée lorsque leur coût perturbe le cycle de correction.

Point de contrôle : si le processeur reste peu utilisé mais que la mémoire est sous pression, augmenter la puissance de calcul ne résoudra pas le problème. Si les tests attendent surtout le réseau ou le lancement du simulateur, une meilleure organisation de la suite aura davantage d’effet qu’un changement de machine.

Mac distant : quand augmenter la configuration devient rationnel

Après les corrections du projet, exécutez le même commit sur le Mac local et sur le Mac distant. Lancez une compilation incrémentale, une archive propre et la suite de tests retenue. Les observations doivent couvrir le processeur, la pression mémoire, l’attente du stockage, le téléchargement des dépendances et l’impact d’une session distante VNC ou SSH.

Un Mac distant est un candidat crédible lorsque :

le compilateur sature régulièrement le processeur pendant une tâche reproductible ;
la mémoire disponible devient insuffisante pendant une archive ou des tests parallèles ;
le stockage attend alors que les scripts et les dépendances sont déjà maîtrisés ;
le poste local est occupé par le design, l’audio, la vidéo ou le développement quotidien ;
le build doit rester disponible pour une intégration continue sans monopoliser le poste principal.

Les activités créatives peuvent modifier la décision. Un développeur qui monte une vidéo de démonstration, prépare des visuels d’interface ou travaille sur une session audio peut préférer déplacer les archives et les tests vers une machine distante, même si le poste local reste suffisant pour les compilations courtes.

Checklist d’acceptation avant de louer ou d’étendre un environnement

[ ] Le commit testé, le Scheme, la configuration et la destination sont documentés.
[ ] La compilation incrémentale est mesurée après une modification limitée.
[ ] La première compilation est séparée du temps de résolution et de téléchargement des dépendances.
[ ] Build Timing Summary ou la sortie xcodebuild identifie les tâches dominantes.
[ ] Les relations entre Targets et les phases de script ont été vérifiées.
[ ] DerivedData n’est supprimé qu’en présence d’un problème de cache identifié.
[ ] L’archive Release est décomposée entre compilation, édition de liens, ressources, symboles et signature.
[ ] Les tests unitaires, les tests d’interface et le démarrage du simulateur sont mesurés séparément.
[ ] Le parallélisme est comparé avec le temps total et la stabilité des tests.
[ ] La pression mémoire, l’utilisation du processeur et l’attente du stockage sont observées sur le Mac distant.
[ ] Les résultats sont répétés avec le même commit avant toute décision d’extension.

Le guide de validation d’un environnement Xcode 26 sur Mac distant peut servir de support pour reproduire ces contrôles dans une machine accessible à distance.

Choisir entre optimisation, extension et séparation des tâches

Le choix ne se résume pas à « puce plus rapide ou mémoire supplémentaire ». Une dépendance qui se résout à chaque exécution, un script sans condition ou une cible trop couplée restera problématique sur une machine plus chère.

Signal mesuré	Optimisation du projet	Mac distant mieux dimensionné	Séparation des tâches
Tâches Swift dominantes et processeur saturé	Réduire les recompilations et découpler les modules	À envisager après validation	Réserver l’archive et les tests à une file distincte
Pression mémoire avec tests parallèles	Réduire le parallélisme et les destinations simultanées	Ajouter de la mémoire peut être pertinent	Isoler les tests d’interface
Scripts répétés à chaque build	Corriger les entrées et conditions du script	Peu d’effet attendu	Déplacer les scripts lourds hors du feedback local
Téléchargements ou résolution lents	Stabiliser `Package.resolved` et l’accès privé	Vérifier l’accès réseau du Mac distant	Préparer les dépendances avant le build
Poste local occupé par audio, vidéo ou design	Limiter les tâches locales	Utiliser le Mac distant pour les tâches longues	Programmer les archives hors des heures de création
Archive lente mais compilation stable	Examiner symboles, signature et scripts Release	Utile seulement si la ressource est réellement saturée	Dédier l’archive au pipeline

Pour les équipes qui comparent un poste local à un environnement loué, le comparatif des formules de location de Mac doit être consulté après la mesure, et non comme première étape. Les besoins de durée, d’accès distant et de disponibilité comptent autant que la puissance brute.

Besoin réel	Option la plus cohérente	Conditions de validation	Limite à accepter
Retours rapides après chaque petite modification	Optimiser le graphe de compilation local	Les tâches inutiles diminuent dans les rapports	Une machine distante ne corrige pas un projet mal découpé
Archives Release régulières	Mac distant réservé au build	CPU, mémoire et stockage restent stables pendant l’archive	La session et les artefacts dépendent de l’accès réseau
Tests d’interface lourds	Séparer les tests de la boucle courte	Le temps global et les échecs sont suivis ensemble	Le retour complet n’est pas instantané
Première construction d’un dépôt	Préparer les dépendances et l’authentification	`Package.resolved` et accès privé sont vérifiés	Le premier téléchargement reste distinct du build
Besoin temporaire de validation	Location courte d’un Mac	Le même commit passe les trois scénarios	Moins intéressant pour une charge lourde permanente
Charge stable et continue	Achat ou location longue selon les contraintes	Les mesures couvrent une période représentative	Une machine dédiée immobilise un budget récurrent

Un poste local reste préférable si l’équipe doit utiliser des interfaces physiques particulières, si la latence rend le débogage inconfortable ou si la charge est durable et parfaitement prévisible. La location n’est pas une réponse universelle.

En revanche, conserver uniquement le poste de développement actuel peut cumuler trois défauts : les compilations occupent la machine pendant les tâches créatives, les archives entrent en concurrence avec l’usage interactif et les tests lourds restent difficiles à planifier. Après un diagnostic montrant une limite matérielle réelle, louer un Mac via SFTPMAC permet de vérifier le gain sur le projet réel avant de financer un achat définitif. Le test doit porter sur la compilation incrémentale, l’archive et les tests, avec les mêmes entrées et les mêmes critères d’acceptation.

La documentation officielle des notes de version de Xcode 26 doit enfin être contrôlée lorsque le comportement d’une version mineure, une exigence système ou un problème corrigé peut modifier le résultat. Une mesure ancienne ne doit pas être présentée comme une règle générale.

Si les rapports montrent seulement des dépendances instables ou des scripts redondants, corrigez le projet. S’ils montrent une saturation persistante du processeur, de la mémoire ou du stockage, essayez le même dépôt sur un Mac distant SFTPMAC et comparez les résultats avant de prolonger la location ou de changer définitivement d’architecture.