Xcode 27 compile plus lentement : Mac distant 2026

Au 24 août 2026, Apple classe encore Xcode 27 parmi les versions bêta dans ses notes de version officielles. Si Xcode 27 compile plus lentement sur votre poste ou votre Mac distant, ne supprimez donc pas immédiatement tout DerivedData et ne commandez pas encore une machine plus puissante : mesurez d’abord les compilations à froid et incrémentales, puis isolez le cache, les dépendances, les scripts, l’indexation et les ressources du nœud.

À qui s’adresse ce guide ?
Aux développeurs Apple qui constatent un changement après la mise à niveau vers Xcode 27, ainsi qu’aux ingénieurs DevOps responsables d’un Mac distant utilisé en continu.
Il concerne aussi les équipes qui doivent conserver Xcode 26.6 pour la production tout en validant la version bêta dans un environnement séparé.

Attention : une compilation lente observée une seule fois ne suffit pas à établir une régression de Xcode 27. Le même commit, le même schéma, la même cible et la même configuration doivent être comparés sur plusieurs exécutions.

Dernière mise à jour : 24 août 2026. Les informations de version et de diagnostic ont été vérifiées à partir des notes de version Xcode d’Apple et de sa documentation du système de compilation. L’état de Xcode 27 pourra changer avec une nouvelle bêta, une version candidate ou la version finale.

Commencez par séparer les types de compilation

Le mot « compilation » recouvre plusieurs charges différentes. Une première compilation après nettoyage n’a pas le même profil qu’une modification locale suivie d’une compilation incrémentale. Une archive de distribution, une suite de tests, l’indexation de l’éditeur et une prévisualisation peuvent également solliciter le même Mac distant au même moment.

Avant de chercher une cause, notez les éléments qui doivent rester identiques :

• le commit ou l’archive du projet ;
• le schéma Xcode et la cible compilée ;
• la plateforme et l’architecture visées ;
• la configuration de compilation ;
• l’état du cache au lancement ;
• les tâches concurrentes présentes sur le Mac distant.

Utilisez ensuite Build With Timing Summary dans Xcode, ou l’option de résumé chronométré de xcodebuild, afin d’obtenir une durée par tâche plutôt qu’une impression générale. Apple décrit cette méthode dans son guide consacré à l’amélioration de la vitesse des compilations incrémentales.

L’objectif n’est pas de produire un chiffre spectaculaire, mais de repérer l’étape qui a changé. Si la compilation à froid est longue mais que les compilations incrémentales restent régulières, le problème ne se traite pas comme une panne générale du Mac. À l’inverse, si chaque petite modification relance de nombreuses cibles inchangées, le projet ou sa configuration mérite un examen avant toute extension matérielle.

Lisez le résumé de temps avant de toucher à DerivedData

Pourquoi chaque modification de code peut-elle sembler déclencher une compilation complète ?
La cause est souvent une invalidation du graphe de dépendances, une cible trop largement reliée, un script déclaré sans entrées ni sorties précises, ou une configuration qui modifie constamment les paramètres d’entrée. La taille du dossier DerivedData ne permet pas, à elle seule, de distinguer ces situations.

Dans le résumé de temps et les journaux de construction, recherchez notamment :

• des cibles non modifiées qui sont recompilées ;
• une génération répétée de fichiers ou de modules ;
• une résolution de dépendances lancée à chaque exécution ;
• un script qui s’exécute même lorsque ses fichiers d’entrée n’ont pas changé ;
• une différence entre la compilation depuis Xcode et celle lancée par xcodebuild.

Vérifiez le graphe des cibles, les relations de dépendance et les réglages conditionnels. La documentation Apple sur le système de compilation explique le rôle de ces relations ; elle doit servir de référence lorsque vous cherchez pourquoi une cible est reconstruite.

Un cas fréquent concerne un fichier généré placé dans un emplacement instable. Si son chemin, son contenu ou sa date de génération change à chaque lancement, Xcode peut considérer que les entrées ne sont plus identiques. Le symptôme se confirme lorsque le journal montre la régénération avant la compilation de cibles qui n’ont pourtant pas été modifiées.

La suppression de DerivedData peut-elle résoudre une compilation lente ?
Oui, mais seulement si les données de compilation du projet sont effectivement incohérentes ou corrompues. Elle ne corrige ni un graphe de dépendances trop large, ni un script qui s’exécute toujours, ni une saturation du disque. Supprimez donc le dossier propre au projet concerné après avoir conservé les journaux, puis comparez une compilation à froid et des compilations incrémentales.

Évitez la commande ou l’action globale qui efface les données de tous les projets. Sur un Mac distant utilisé par plusieurs tâches, ce nettoyage peut supprimer des artefacts utiles à d’autres travaux et créer artificiellement une nouvelle compilation complète. Le bon test consiste à :

• sauvegarder le résumé de temps initial ;
• supprimer uniquement les données du projet suspect ;
• relancer une compilation à froid ;
• effectuer plusieurs modifications limitées ;
• comparer les tâches réellement reconstruites.

Distinguez dépendances, scripts et attente réseau

Les phases de préparation peuvent donner l’impression que le compilateur est lent alors qu’il attend une dépendance ou un service distant. Cette distinction est particulièrement importante sur un Mac distant : une résolution de paquet, un téléchargement ou une génération d’artefact peut être limitée par le réseau du centre de données, le dépôt utilisé ou le cache partagé.

Pour les paquets Swift, comparez le premier lancement avec les suivants. Notez si les résolutions, téléchargements ou générations réapparaissent alors que le fichier de verrouillage et le commit n’ont pas changé. Les recommandations d’Apple concernant les paquets Swift dans les flux d’intégration continue sont utiles pour contrôler cette préparation.

Examinez aussi les phases Run Script. Un script devrait déclarer les fichiers qu’il lit et ceux qu’il produit, afin que le système puisse déterminer quand il doit réellement être exécuté. La documentation Apple sur les scripts personnalisés pendant une compilation détaille cette configuration.

Après chaque correction, ne vous contentez pas d’un lancement réussi. Faites une première compilation, modifiez un fichier sans rapport avec les scripts, puis relancez plusieurs compilations incrémentales. Le script doit être absent du chemin d’exécution lorsqu’aucune entrée pertinente n’a changé. Si le journal montre encore son exécution systématique, le réglage n’est pas suffisamment précis.

Lorsque le projet utilise des modules complexes, l’activation ou la vérification des dépendances explicites peut également aider à comprendre les reconstructions en cascade. Consultez les indications Apple sur la construction avec dépendances explicites de modules, sans transformer cette option en remède automatique.

Isolez l’indexation et les prévisualisations du travail de compilation

Que faire si l’indexation de Xcode ne se termine jamais sur un Mac distant ?
Commencez par vérifier si l’indexation est réellement bloquée ou si elle progresse en concurrence avec une compilation, une prévisualisation ou un simulateur. Lancez un test en ligne de commande sans session graphique, puis un test depuis Xcode avec les tâches visuelles non nécessaires fermées. La différence indique si le système de compilation est en cause ou si l’interface surcharge le même nœud.

Surveillez l’activité de l’indexeur, de SourceKit, du simulateur et des prévisualisations SwiftUI pendant le ralentissement. Dans un environnement de création audio, vidéo ou design, une prévisualisation lourde, un outil de rendu ou une importation de ressources peut partager le processeur, la mémoire et les entrées-sorties avec Xcode. Il serait alors trompeur d’attribuer toute l’attente à Xcode 27.

Ne désactivez pas durablement l’indexation pour faire disparaître le symptôme. Vous perdriez la navigation dans le code, les diagnostics et parfois une partie de l’assistance à la saisie, sans traiter la cause. Préférez une séparation des usages :

• compilation automatisée sans session graphique lorsque c’est possible ;
• prévisualisations fermées pendant les archives ;
• simulateur arrêté sur le nœud réservé à la CI ;
• session interactive dédiée au développement et à l’indexation ;
• absence de tâches de rendu ou de génération non nécessaires pendant la mesure.

Cette séparation permet également de comparer un scénario créatif et un scénario de construction sans confondre leurs besoins. Un Mac distant peut convenir à l’un et être mal dimensionné pour l’autre si plusieurs charges sont lancées en parallèle.

Vérifiez les ressources du Mac distant avant d’envisager une extension

Une machine peut compiler correctement seule et ralentir dès que plusieurs tâches partagent le même espace de travail. Examinez l’état de la mémoire, la pression mémoire, l’activité d’échange et les entrées-sorties du disque pendant les tests. Le guide Apple consacré à l’identification d’un besoin supplémentaire en mémoire explique comment interpréter la pression mémoire et l’utilisation de l’échange.

Les vérifications prioritaires sont les suivantes :

• espace libre réellement disponible sur le volume de compilation ;
• présence d’une activité d’échange lorsque le ralentissement apparaît ;
• temps d’attente du disque pendant la génération des modules ;
• concurrence entre plusieurs travaux dans le même répertoire ;
• réutilisation correcte des caches de paquets et de compilation ;
• différence entre une tâche seule et plusieurs tâches simultanées ;
• état du nœud après un redémarrage contrôlé.

Comment savoir si le ralentissement vient du projet ou d’une configuration Mac insuffisante ?
Lancez le même commit, avec le même schéma et la même configuration, d’abord seul puis avec la concurrence habituelle. Si le temps se dégrade uniquement lorsque plusieurs travaux s’exécutent, la capacité ou l’isolation du nœud est probablement en cause. Si une seule cible reproduit la lenteur avec une pression mémoire et une activité disque normales, recherchez plutôt une dépendance, un script ou une invalidation dans le projet.

Ne partagez pas automatiquement DerivedData, les paquets téléchargés et les répertoires de travail entre des tâches incompatibles. Un cache partagé mal isolé peut provoquer des invalidations, des collisions de fichiers ou des reconstructions difficiles à reproduire. À l’inverse, recréer tous les caches à chaque tâche transforme chaque exécution en compilation à froid et augmente inutilement l’attente.

La checklist de décision avant retour de version ou changement de nœud

Utilisez cette liste après avoir conservé les journaux initiaux. Chaque case doit correspondre à une observation vérifiable, pas à une supposition.

• [ ] Le commit, le schéma, la cible, la plateforme et la configuration sont identiques entre les comparaisons.
• [ ] Une compilation à froid et une compilation incrémentale disposent chacune d’un résumé de temps.
• [ ] Les tâches les plus longues sont identifiées dans le journal, au lieu d’être déduites de la taille de DerivedData.
• [ ] Les cibles inchangées ne sont pas recompilées sans raison documentée.
• [ ] Les scripts déclarent leurs fichiers d’entrée et de sortie, puis sont vérifiés sur une modification sans rapport.
• [ ] La résolution des dépendances et les téléchargements sont comparés entre le premier lancement et les suivants.
• [ ] Un test en ligne de commande est comparé à un test depuis la session graphique Xcode.
• [ ] L’indexation, le simulateur, les prévisualisations et les tâches de rendu non indispensables sont isolés.
• [ ] La pression mémoire, l’échange et l’activité disque sont relevés pendant une tâche seule puis pendant la concurrence habituelle.
• [ ] Le répertoire de travail et les caches sont vérifiés après un redémarrage du Mac distant.
• [ ] La décision de revenir à Xcode 26.6 ou de maintenir Xcode 27 est documentée avec des journaux reproductibles.

La décision peut alors suivre une règle simple. Si les journaux montrent une invalidation causée par le projet, corrigez d’abord les dépendances ou les scripts. Si le ralentissement apparaît seulement avec l’indexation ou une prévisualisation, séparez la charge interactive de la CI. Si la compilation reste normale mais que la mémoire ou le disque saturent sur un nœud partagé, évaluez l’isolation ou l’extension de capacité.

Si le même projet ne se dégrade qu’avec Xcode 27 bêta, conservez Xcode 26.6 pour la chaîne de production et utilisez un nœud isolé pour la validation. Cette approche à deux voies évite de transformer une hypothèse sur une version en incident de livraison. Les notes de version officielles doivent être relues à chaque nouvelle version, car les problèmes connus et les exigences système peuvent évoluer.

Quand un Mac distant séparé devient le choix rationnel

Un environnement séparé est particulièrement pertinent lorsque vous devez conserver deux versions de Xcode, reproduire un ralentissement sans perturber la production ou comparer un projet identique avec des caches contrôlés. Il vous permet de réserver un espace de travail à la mesure, puis de supprimer une variable à la fois : outil, cache, dépendance, concurrence ou ressource.

Pour un usage de développement ponctuel, de validation audio ou vidéo, de génération d’archives et de tests d’une chaîne Apple sans achat de matériel, vous pouvez consulter les cas d’usage d’un Mac distant. Si vous devez également comparer les conditions d’accès et la durée de mise à disposition, les formules de location Mac donnent le cadre commercial à examiner, sans remplacer vos mesures techniques.

Un Mac distant ne résout toutefois pas un projet mal configuré. Il ne rendra pas déterministe un script sans entrées-sorties, ne réparera pas une dépendance cyclique et ne supprimera pas l’attente réseau d’un service externe. Son intérêt apparaît lorsque vous avez besoin d’un environnement Apple indépendant, accessible à distance, avec suffisamment d’isolement pour reproduire les résultats et maintenir une chaîne de production stable.

Si votre solution actuelle repose sur le partage d’un poste de développeur, elle expose généralement la CI à l’indexation, aux prévisualisations, aux sessions ouvertes et aux caches modifiés par une autre personne. Si vous utilisez uniquement une machine Linux ou une virtualisation non équivalente, vous ajoutez des limites pour les outils Apple, l’architecture cible et les tests graphiques. Enfin, acheter un Mac dédié reste cohérent pour une charge lourde, stable et permanente, mais immobilise du capital et ne facilite pas toujours la comparaison rapide de deux chaînes d’outils.

Pour une vérification temporaire de Xcode 27, une reproduction indépendante du projet ou un nœud réservé à la double validation, louer un Mac auprès de KVMFLUX peut donc offrir une voie plus maîtrisable que de modifier immédiatement votre poste de production. Commencez par transférer le même commit et les mêmes paramètres, répétez les mesures, puis décidez seulement à partir des journaux si le problème justifie un retour vers Xcode 26.6, une correction du projet ou une extension durable de l’infrastructure.