Une information confirmée dans les notes de version de Xcode 27 Beta 6 change la décision : les documents UIKit d’Interface Builder peuvent utiliser par défaut le mode de compilation « toolchain » sans télécharger Simulator. Cela ne transforme pas pour autant tout le pipeline en tâche sans environnement d’exécution.
La décision opérationnelle est donc la suivante : ne supprimez pas Simulator de tous les nœuds. Déplacez la compilation pure, les contrôles statiques et la préparation des artefacts vers un nœud Mac léger, mais conservez un nœud complet pour les tests avec hôte, les tests d’interface et les validations qui dépendent du comportement d’iOS. Faites d’abord tourner les deux chemins en parallèle sur le même projet.
Cet article s’adresse aux ingénieurs de compilation qui cherchent à réduire les dépendances d’un serveur CI. Il concerne aussi les équipes de test qui doivent délimiter précisément le rôle de Simulator, ainsi que les responsables DevOps et plateforme qui préparent une nouvelle répartition des nœuds Mac, des caches et des procédures de reprise.
Dernière mise à jour : 8 septembre 2026. Les informations de version et de comportement ont été vérifiées à partir des notes Xcode 27, de la documentation de test et des références de réglages Apple citées dans cet article. Xcode 27 et iOS 27 restent traités comme des versions bêta à cette date.
[ SECTION_01 ] La première séparation à faire : compiler n’est pas exécuter
Dans un pipeline iOS, « ne pas avoir besoin de Simulator pour compiler » et « ne pas avoir besoin de Simulator » désignent deux réalités différentes. Le SDK fournit les interfaces et les bibliothèques nécessaires à la compilation. Le runtime Simulator fournit, lui, un environnement dans lequel une application peut être lancée. Le périphérique simulé ajoute encore une destination concrète.
Cette distinction répond directement à la question « Xcode 27 permet-il de construire un projet iOS sans télécharger Simulator ? » : pour certains documents UIKit d’Interface Builder, le mode toolchain confirmé dans Xcode 27 permet de compiler sans ce runtime. La portée est toutefois limitée à cette étape et à ces documents. Elle ne dispense pas de tester l’application dans un environnement iOS.
Le pipeline doit donc enregistrer séparément :
- le SDK utilisé par la commande de compilation ;
- le runtime Simulator installé sur le nœud ;
- le périphérique simulé choisi comme destination ;
- le mode de compilation des fichiers Storyboard et XIB ;
- la destination utilisée par chaque cible de test ;
- la présence éventuelle d’un Test Host ou d’un processus d’application à lancer.
Les exigences générales de version et de matériel doivent également être contrôlées dans la table des exigences système de Xcode. La documentation Apple confirme que Xcode 27 fonctionne sur Mac Apple Silicon ; le choix du nœud ne peut donc pas être traité comme une simple question de stockage du runtime.
Matrice de décision pour le pool CI
| Charge exécutée | Mode recommandé | Simulator requis sur le nœud | Décision de migration |
|---|---|---|---|
| Analyse statique, génération de code et vérification des dépendances | Nœud de compilation léger | Non, sauf outil explicitement dépendant d’un runtime | Migrer en priorité |
| Compilation d’une application sans lancement | Nœud de compilation léger | Pas nécessairement | Vérifier les journaux et les fichiers UIKit |
| Compilation de Storyboard ou XIB avec le mode toolchain | Nœud de compilation léger | Non selon le comportement confirmé de Xcode 27 | Tester projet par projet |
| Test Swift sans hôte et sans appel au comportement d’iOS | Nœud de compilation ou de test léger | Souvent non, à confirmer par la destination | Migrer seulement après vérification |
| Test avec Test Host ou application à lancer | Nœud de test complet | Oui, ou appareil physique | Conserver un environnement d’exécution |
| XCTest UI Tests | Nœud de test complet | Oui, ou appareil physique | Ne pas supprimer le runtime |
| Validation de compatibilité, rendu, audio ou vidéo | Nœud de test complet | Oui selon le scénario | Garder une chaîne de validation dédiée |
| Archivage et export vers App Store Connect | Nœud de compilation signé | Pas automatiquement pour l’archivage | Séparer l’export de la validation fonctionnelle |
Cette matrice ne remplace pas les essais. Elle indique seulement où commencer. La documentation de la référence des outils en ligne de commande Xcode doit être utilisée pour vérifier les commandes réellement exécutées par le pipeline, plutôt que de déduire le comportement à partir du nom de l’étape.
[ SECTION_02 ] Les mainteneurs de Storyboard et de XIB doivent valider le mode toolchain
Le changement le plus visible concerne les projets qui contiennent des documents UIKit compilés par Interface Builder. Le mode toolchain peut réduire la dépendance au runtime Simulator pendant la compilation. Il ne faut cependant pas considérer cette possibilité comme une conversion automatique de tous les projets existants.
Un projet ancien peut comporter des réglages personnalisés. Une cible peut appeler directement ibtool. Un script peut imposer un chemin de SDK ou une destination. Une phase de construction peut également vérifier indirectement la présence de ressources liées à Simulator. Ces cas doivent être distingués de la configuration par défaut de Xcode 27.
La vérification commence par le réglage IBC_COCOATOUCH_COMPILER_MODE. La définition et les valeurs applicables doivent être comparées à la référence officielle des réglages de compilation. La documentation sur la configuration des réglages d’une cible permet ensuite de déterminer si la valeur est héritée, écrasée par la cible ou injectée par un fichier de configuration.
Pour chaque projet, l’équipe chargée des ressources d’interface doit examiner :
- le journal complet de compilation, notamment les appels à
ibtool; - les réglages effectifs de la cible, et non seulement ceux visibles dans le projet ;
- les fichiers Storyboard et XIB réellement traités ;
- les ressources produites dans le dossier de construction ;
- les erreurs de classe, de module ou de contrainte qui apparaissent après le changement ;
- la commande exacte qui provoque une demande de runtime Simulator.
Un build vert ne suffit pas. Une ressource peut être compilée correctement puis échouer au lancement, au chargement d’un contrôleur ou pendant un test d’interface. La validation doit donc comparer le résultat du nœud historique et celui du nœud candidat.
Si le projet doit revenir au mode Simulator, le pipeline doit documenter le déclencheur. Il peut s’agir d’un fichier précis, d’un réglage personnalisé, d’une commande directe ou d’une erreur de chargement. Le retour doit être accessible par une modification de configuration versionnée, pas par une intervention manuelle sur le serveur.
Attention : l’absence d’un téléchargement de runtime dans les journaux ne prouve pas que toute la chaîne est indépendante de Simulator. Il faut aussi vérifier la destination, le Test Host et les processus lancés après la compilation.
[ SECTION_03 ] Les équipes de test doivent classer les tests par dépendance réelle
Le terme « test unitaire » recouvre plusieurs charges. Un test Swift qui manipule uniquement des structures, des algorithmes ou une couche de données ne présente pas le même besoin qu’un test chargé dans le processus de l’application. Le nom de la cible n’est donc pas un critère suffisant.
Tests Swift sans hôte
Un ensemble de tests qui ne lance pas l’application et n’appelle pas de comportement dépendant d’iOS peut parfois être exécuté sur un nœud allégé. Cette décision doit être confirmée dans la configuration de la cible et dans le résultat produit par xcodebuild.
Le contrôle porte sur le SDK, la destination, le produit de test et les dépendances importées. Une bibliothèque apparemment indépendante peut encore utiliser des API dont le comportement n’est observable qu’avec un environnement iOS. Dans le doute, le test reste dans le pool complet jusqu’à ce qu’un cas représentatif démontre le contraire.
Tests avec hôte et intégration
Dès qu’un test charge l’application, une extension ou un composant système, la question devient celle de l’exécution. Le Test Host, la destination et le schéma doivent être lus dans le plan de test et non déduits du nom « UnitTests ».
La page Apple consacrée à l’exécution des tests et à l’interprétation des résultats fournit le cadre pour examiner les résultats. L’équipe doit conserver le bundle de résultats, le journal de lancement et les erreurs de destination. Un résultat indiquant que la compilation est terminée ne prouve pas que le test a exécuté le code attendu.
Cette distinction répond à une autre recherche fréquente : quelles tâches CI iOS ont réellement besoin du runtime Simulator ? Toute tâche qui doit démarrer une application iOS, observer son comportement, charger une interface, vérifier une intégration système ou reproduire un parcours utilisateur doit rester liée à un environnement d’exécution, Simulator ou appareil physique.
[ SECTION_04 ] Les tests d’interface doivent rester sur un nœud complet
Les XCTest UI Tests ne se limitent pas à compiler des fichiers de test. Ils doivent lancer l’application, trouver des éléments d’interface, effectuer des actions et vérifier des états visibles. Le mode toolchain d’Interface Builder ne fournit aucune de ces capacités.
Le plan de test doit préciser la destination autorisée, le schéma et les configurations concernées. La documentation Apple sur l’exécution d’une application sur un appareil simulé ou physique sert de référence pour cette partie du contrôle.
La validation doit confirmer :
- que l’application a réellement été installée dans le périphérique simulé ;
- que le processus a démarré ;
- que les actions d’interface ont été exécutées ;
- que le résultat de test contient les étapes attendues ;
- que les captures, journaux ou médias d’échec sont récupérables ;
- que le périphérique et le runtime utilisés correspondent au plan de test.
Les scénarios audio, vidéo et design méritent une attention particulière. Un projet qui compile des écrans peut encore dépendre d’un rendu, d’une permission, d’un flux média ou d’un comportement de rotation observable uniquement pendant l’exécution. Le nœud allégé convient à la production d’un artefact, pas à la validation de cette expérience.
Lorsqu’une exécution parallèle est activée, le responsable de plateforme doit observer les clones de périphériques simulés, les files d’attente, les échecs de démarrage et la récupération des médias. Aucune capacité chiffrée de parallélisation ne doit être promise sans mesure officielle ou test réel de l’infrastructure concernée.
La documentation sur l’organisation des tests avec Test Plan aide à séparer les contrôles rapides des suites fonctionnelles complètes. Cette séparation permet d’éviter de réserver un nœud avec runtime lourd pour chaque commit lorsque seule une partie des tests en a besoin.
[ SECTION_05 ] La plateforme CI doit séparer les pools sans perdre la reproductibilité
La séparation recommandée n’est pas une division arbitraire entre « serveur rapide » et « serveur lent ». Elle repose sur les artefacts, la destination et la capacité à reprendre une tâche après redémarrage.
Le pool de compilation peut recevoir :
- l’analyse statique ;
- la résolution et la vérification des dépendances ;
- la compilation sans lancement ;
- la génération d’artefacts ;
- les archives préparatoires lorsque la signature et la destination sont maîtrisées.
Le pool de test conserve :
- les tests avec application hôte ;
- les XCTest UI Tests ;
- les tests de compatibilité iOS ;
- les validations de rendu, d’audio et de vidéo ;
- les étapes nécessitant un périphérique simulé ou une interaction système.
La paire build-for-testing et test-without-building est utile pour matérialiser cette frontière. La note technique Apple consacrée à Build For Testing et Test Without Building décrit le principe : produire les éléments de test dans une étape, puis les exécuter dans un environnement approprié.
Avant de déplacer une tâche, le pipeline doit comparer le commit, le SDK, la version de Xcode, les réglages de compilation, les produits de test et la destination. Si le nœud de test reconstruit silencieusement une partie du projet, la séparation est imparfaite et le gain attendu devient difficile à attribuer.
Trois topologies sont raisonnables :
- Pool unique : adapté à une petite équipe, à une faible fréquence de test ou à un projet encore instable. La maintenance est plus simple, mais toutes les tâches héritent des dépendances du nœud complet.
- Deux pools : adapté à une équipe qui distingue clairement compilation et validation. Le nœud léger produit les artefacts ; le nœud complet exécute les tests nécessaires.
- Migration différée : préférable lorsque les scripts sont anciens, que les destinations sont implicites ou que le projet mélange plusieurs versions de Xcode. Le pipeline historique reste la référence jusqu’à la fin de l’audit.
Dans les trois cas, le cache doit être lié à la version de l’outil et au SDK. Un cache partagé entre deux environnements différents peut produire un résultat apparemment reproductible tout en masquant une dépendance à Simulator.
[ SECTION_06 ] Le responsable de publication doit exiger une double preuve
La dernière décision ne doit pas reposer sur un build réussi une seule fois. Le responsable de publication doit choisir un projet représentatif : présence éventuelle de Storyboard ou XIB, tests avec hôte, tests d’interface, signature et export.
Le même commit doit passer sur le nœud historique et sur le nœud candidat. La comparaison doit couvrir :
- le succès de la compilation ;
- les produits générés ;
- les résultats de
build-for-testing; - l’exécution de
test-without-building; - les tests d’interface ;
- les destinations réellement sélectionnées ;
- le comportement après redémarrage ;
- la capacité à revenir au nœud historique ;
- la publication de l’artefact, si elle fait partie du flux.
Pour l’étape de livraison, les règles de gestion des builds dans App Store Connect doivent être vérifiées séparément. L’acceptation d’un fichier par App Store Connect ne remplace pas les tests d’exécution.
Un nœud peut être allégé uniquement lorsque la compilation pure passe de façon répétée, qu’aucun runtime n’est téléchargé implicitement, qu’aucune destination Simulator n’est appelée et que les artefacts sont identiques selon les critères définis par l’équipe. Dans le cas contraire, le nœud reste dans le pool complet.
[ SECTION_07 ] Choisir un nœud Mac distant sans modifier la production trop tôt
Un serveur Linux existant peut continuer à prendre en charge les contrôles indépendants de macOS. Il ne remplace toutefois pas un environnement Mac lorsqu’il faut utiliser Xcode, valider une application iOS ou exécuter un outil Apple. La solution actuelle présente souvent trois limites : elle sépare les outils entre plusieurs systèmes, elle rend les journaux de reprise moins homogènes et elle ne permet pas de reproduire les problèmes liés à la destination iOS.
Un Mac local ajouté à l’équipe évite certains délais réseau, mais il immobilise du matériel, impose une maintenance physique et devient moins flexible lorsque la demande de compilation varie. Un Mac distant loué par NOVAKVM permet de créer un nœud temporaire pour une campagne de validation, puis de le conserver pendant la durée nécessaire au pool de compilation ou de test. Les équipes peuvent examiner les possibilités de location d’un Mac distant avec NOVAKVM sans modifier immédiatement leur nœud de production.
Pour un essai contrôlé, le chemin le plus sûr consiste à :
- cloner le dépôt sur un nœud distant réversible ;
- installer la même version de Xcode et les mêmes dépendances ;
- exécuter la compilation sans destination d’exécution ;
- exécuter
build-for-testing; - transférer les produits vers le nœud complet ;
- lancer
test-without-buildingpuis les UI Tests ; - conserver les journaux et comparer les destinations ;
- répéter après un redémarrage ;
- décider ensuite si le nœud rejoint le pool léger ou le pool complet.
Cette approche permet aussi d’examiner un Mac distant destiné aux usages de développement sans confondre un besoin de compilation ponctuel avec une capacité permanente de test.
La conclusion est volontairement prudente : Xcode 27 réduit la dépendance à Simulator pour une partie de la compilation UIKit, mais il ne supprime pas le besoin d’un environnement d’exécution. Le choix pertinent en 2026 consiste à conserver un pool de test complet, à déplacer progressivement les tâches réellement autonomes et à documenter chaque condition de retour arrière.
Pour une équipe qui utilise encore uniquement un serveur Linux, les limites sont concrètes : pas de chaîne Xcode native, pas de validation fidèle des UI Tests et davantage de contournements pour isoler les artefacts. Pour une équipe qui ajoute directement un Mac physique, le coût matériel et la maintenance réduisent la souplesse des essais. La location d’un Mac auprès de NOVAKVM offre un compromis adapté lorsqu’il faut un nœud distant temporaire, un environnement de secours ou une capacité de test pendant une migration, sans remplacer l’analyse préalable du volume et de la stabilité des charges.