Xcode 27 : faut-il installer le simulateur ? Solution allégée 2026

Le build réussit, mais votre machine distante conserve plusieurs Runtime de simulateur jamais utilisés.

La solution la plus rapide est de garder Xcode, le SDK iOS et les outils de signature, puis de retirer le Runtime du simulateur si votre chaîne se limite à la compilation, à l’Archive et à la publication. Avec Xcode 27 Beta, les documents Storyboard et XIB UIKit utilisent par défaut le mode Interface Builder toolchain ; leur compilation ne force donc plus, à elle seule, l’installation d’un Runtime. En revanche, les tests sur iOS Simulator, SwiftUI Preview et la validation de plusieurs versions d’iOS nécessitent toujours un environnement simulé correspondant.

Dernière mise à jour : 5 septembre 2026. Les informations de version et de comportement de Xcode 27 ont été vérifiées dans les notes de version et la page de configuration système officielles d’Apple.

Cet article s’adresse aux développeurs indépendants qui veulent limiter une machine distante à l’Archive Release, à la signature et à l’envoi, aux mainteneurs de projets UIKit qui utilisent Storyboard ou XIB, ainsi qu’aux petites équipes qui doivent séparer publication stable et tests avec simulateur.

Décidez d’abord selon la tâche exécutée

La question « Xcode 27 faut-il installer le simulateur sur la machine de build ? » ne se résout pas en regardant uniquement la plateforme ciblée par le projet. iOS SDK, Runtime du simulateur, appareil simulé et outil de compilation répondent à des besoins différents.

Tâche exécutée sur la machine	Runtime iOS Simulator requis ?	Décision de configuration
Compilation Swift ou Objective-C et Archive Release	Non, en principe	Conserver Xcode et le SDK de plateforme
Signature, validation et préparation d’un envoi	Non, en principe	Vérifier les certificats, profils et scripts de distribution
Compilation de Storyboard ou XIB avec le mode Interface Builder toolchain	Non, avec le comportement confirmé de Xcode 27 Beta	Tester un véritable projet UIKit avant retrait
Tests unitaires exécutés sur macOS uniquement	Non	Contrôler la destination choisie par le Scheme
XCTest sur une destination iOS simulée	Oui	Installer le Runtime correspondant à la destination
XCTest UI Tests	Oui	Prévoir un appareil simulé et un Runtime compatibles
SwiftUI Preview, débogage interactif et validation multi-version	Oui	Utiliser une station ou une machine de test séparée

Cette distinction est cohérente avec la documentation Apple sur l’exécution d’une application sur des appareils simulés ou physiques : le Runtime devient une dépendance lorsque Xcode doit démarrer une cible simulée, pas simplement lorsqu’il compile une application iOS. La [documentation officielle sur les appareils simulés et physiques](https://developer.apple.com/documentation/Xcode/running-your-app-on-simulated-or-physical-devices) décrit cette relation entre destination d’exécution et environnement disponible.

Ce qui est confirmé, et ce qui reste lié à la bêta

Au 5 septembre 2026, la page officielle des exigences système de Xcode liste Xcode 27 Beta 4. Les notes de version de Xcode 27 Beta confirment que le mode Interface Builder toolchain est le mode par défaut pour la compilation des documents UIKit, avec une possibilité de retour au mode simulator.

Cela ne constitue pas une garantie permanente pour une future Release Candidate ou une version finale. Vous devez donc enregistrer la version exacte de Xcode, le résultat de l’Archive et la configuration de compilation dans votre procédure d’exploitation. Ne transformez pas un comportement observé dans une bêta en promesse générale pour toutes les versions à venir.

Première étape : construire une machine de publication minimale

Pour un serveur qui ne fait que compiler et publier, commencez par dresser l’inventaire des actions réellement appelées. Une application qui prend en charge iOS n’implique pas automatiquement que le serveur doive lancer iOS Simulator.

Composant	Rôle dans une chaîne d’Archive	Peut-il être absent d’une machine de publication ?
Xcode	Compilation, Archive, signature et distribution	Non
SDK iOS utilisé par la cible	Compilation contre les API et bibliothèques de la cible	Non
Outils de ligne de commande	Appels automatisés, notamment xcodebuild	Non si la chaîne est automatisée
Runtime iOS Simulator	Exécution d’une application dans un appareil simulé	Oui, si aucun test ou script ne l’appelle
Appareil simulé créé dans Xcode	Destination concrète d’exécution	Oui pour une chaîne d’Archive seule
Certificats et profils de provisionnement	Signature et distribution	Non pour une publication signée

Apple décrit l’installation des composants additionnels dans sa [documentation de gestion des composants Xcode](https://developer.apple.com/documentation/Xcode/downloading-and-installing-additional-xcode-components?changes=la_4_5_9&language=objc). Utilisez cette méthode officielle pour ajouter un Runtime lorsque la charge de test le justifie ; ne téléchargez pas toutes les plateformes simplement parce qu’elles apparaissent dans l’interface.

Sur une machine distante, vérifiez notamment les éléments suivants :

le Scheme utilisé par l’automatisation ;
le Test Plan sélectionné, s’il existe ;
la destination transmise à xcodebuild ;
les scripts qui invoquent simctl, une destination simulée ou une commande de lancement ;
les phases qui exécutent build-for-testing ou test-without-building ;
les étapes de signature, de validation et de transfert vers App Store Connect.

Les options et les paramètres de compilation doivent être contrôlés dans le [Build Settings Reference d’Apple](https://developer.apple.com/documentation/xcode/build-settings-reference), en particulier si votre projet modifie le mode de compilation des ressources Interface Builder.

Le critère de réussite n’est pas seulement le code retour

Un xcodebuild terminé avec succès ne suffit pas à prouver que la chaîne de livraison est correcte. Pour un projet réel, votre preuve minimale doit inclure :

l’Archive .xcarchive produite par le même commit que celui destiné à la publication ;
la présence de l’application et de ses ressources UIKit dans l’Archive ;
l’état de signature et de provisionnement ;
la validation avant envoi ;
le résultat de l’envoi ou, si vous vous arrêtez avant, le journal de la commande correspondante.

La procédure de [distribution d’une application pour les tests bêta et les versions publiées](https://developer.apple.com/documentation/xcode/distributing-your-app-for-beta-testing-and-releases?changes=_7) permet de replacer l’Archive dans la chaîne complète. Cela évite de déclarer la machine « prête » uniquement parce qu’un projet vide a été compilé.

Deuxième étape : valider le mode Interface Builder des projets UIKit

Les projets contenant Storyboard ou XIB sont souvent les premiers à soulever une inquiétude : si l’éditeur d’interface appartient à Xcode, faut-il aussi installer l’environnement d’exécution iOS ? Avec le comportement documenté de Xcode 27 Beta, la réponse est généralement non pour la compilation des documents eux-mêmes.

Le point important est la différence entre compiler les ressources et les afficher ou les tester. Le mode Interface Builder toolchain peut produire les artefacts nécessaires à l’application sans démarrer un appareil simulé. En revanche, une étape de test qui charge l’interface, vérifie une contrainte ou automatise un parcours utilisateur bascule dans une autre catégorie de dépendance.

Vérifiez donc le paramètre IBC_COCOATOUCH_COMPILER_MODE. Si le projet ou un script impose le mode simulator, ne supprimez pas le Runtime en vous fondant sur le comportement par défaut. Cherchez également les réglages injectés par une configuration de CI/CD, un fichier .xcconfig ou une commande d’Archive différente de celle utilisée localement.

Procédez ainsi :

sélectionnez le Scheme de publication ;
confirmez la configuration Release réellement utilisée ;
repérez les fichiers Storyboard et XIB du produit ;
contrôlez IBC_COCOATOUCH_COMPILER_MODE dans les réglages effectifs ;
lancez une Archive avec le projet réel ;
examinez les journaux de compilation des ressources ;
comparez le résultat avec l’Archive obtenue avant la réduction des composants.

**Attention :** l’absence d’erreur pendant la compilation des Storyboard ne valide pas le rendu visuel, l’accessibilité, les contraintes d’Auto Layout ni le comportement des contrôles. Ces vérifications doivent rester dans une tâche de test disposant d’un environnement d’exécution approprié.

Troisième étape : affecter les tests au bon environnement

Les tâches automatisées sont la frontière la plus importante. La question n’est pas « le projet contient-il des tests ? », mais « où ces tests doivent-ils s’exécuter ? ».

Un test de logique pure peut être configuré pour une cible macOS ou être exécuté dans un contexte qui ne démarre pas de simulateur iOS. À l’inverse, un test XCTest associé à une application iOS, un XCTest UI Test ou un scénario qui manipule une destination simulée nécessite un Runtime compatible avec la plateforme et la version choisies.

La documentation Apple consacrée à l’ajout de tests et celle qui explique l’exécution et l’interprétation des résultats doivent servir de référence pour votre Scheme et votre Test Plan.

Comprendre les actions xcodebuild

xcodebuild peut compiler une cible sans l’exécuter, préparer des tests ou les lancer réellement. Ces actions n’ont donc pas toutes la même dépendance :

build ou une Archive peuvent rester limités au SDK et aux outils de compilation ;
build-for-testing prépare des produits destinés à être exécutés ultérieurement ;
test-without-building dépend de la destination choisie au moment de l’exécution ;
test peut nécessiter un Runtime si le Scheme vise un appareil iOS simulé ;
une commande qui spécifie une destination de type simulateur doit être traitée comme une dépendance explicite.

Conservez le fichier xcresult pour chaque exécution de test significative. Il documente la destination, les tests exécutés et les éventuelles erreurs. Il est préférable d’avoir une Archive sans Runtime et un rapport de publication vérifiable qu’un serveur chargé de composants dont personne ne sait s’ils sont utilisés.

Quatrième étape : isoler SwiftUI Preview et la compatibilité multi-version

SwiftUI Preview, le débogage interactif et la vérification de plusieurs tailles d’écran ne sont pas des extensions de l’Archive. Ils appartiennent à un flux de travail de développement et de validation visuelle. Les projets audio, vidéo et design sont particulièrement concernés : une interface peut compiler correctement tout en présentant un problème de mise en page, de rendu ou de comportement qui n’apparaît qu’en exécution.

De même, une équipe qui vérifie plusieurs versions d’iOS ou plusieurs appareils simulés ne doit pas déduire ses besoins de la seule version utilisée pour publier. La documentation Apple sur l’installation d’une application dans plusieurs plateformes et versions de Simulator confirme que chaque combinaison testée doit être disponible dans l’environnement concerné.

Le choix le plus stable consiste à séparer :

une machine de publication peu variable, dédiée à l’Archive, à la signature et à l’envoi ;
une machine de test qui reçoit les Runtime nécessaires aux Plans de test ;
éventuellement un poste de développement pour Preview, inspection visuelle et débogage interactif.

Cette séparation évite qu’une mise à jour de Runtime, une suppression de composant ou un changement de destination perturbe une publication proche. Elle permet aussi de faire évoluer l’environnement de test sans modifier la chaîne qui produit les binaires distribués.

Comparez les trois stratégies avant de louer ou de maintenir une machine

La réduction du nombre de composants n’est pas toujours le meilleur choix. Elle dépend de la fréquence des tests, de la criticité de la publication et de la capacité de votre équipe à restaurer un Runtime manquant.

Stratégie	Pour quel profil ?	Avantage principal	Limite à accepter
Machine de publication allégée	Archive et TestFlight sans test simulé	Moins de composants à maintenir	Aucun test iOS local sur cette machine
Machine unique complète	Petite équipe qui compile et teste au même endroit	Administration plus simple	Les changements de Runtime affectent aussi la publication
Publication et test séparés	Tests UI, Preview ou compatibilité fréquents	Environnement de livraison plus stable	Deux environnements et une procédure de transfert à documenter

Pour un besoin intermittent, l’installation à la demande peut être rationnelle. Pour une publication fréquente, une machine allégée et stable est généralement plus simple à auditer. Pour des tests de régression quotidiens, séparez les rôles au lieu de transformer la machine de livraison en poste de développement généraliste.

Utilisez cette checklist d’acceptation avant de retirer le Runtime

Cochez chaque point sur un projet réel, avec le commit qui doit être livré :

[ ] Le Scheme de publication n’appelle pas simctl et ne sélectionne pas de destination simulée.
[ ] Le Test Plan a été inspecté et ses destinations sont documentées.
[ ] Le projet compile ses fichiers Storyboard et XIB avec le mode attendu.
[ ] IBC_COCOATOUCH_COMPILER_MODE ne force pas involontairement le mode simulator.
[ ] Une Archive Release complète est produite après un démarrage propre de la machine.
[ ] L’Archive contient les ressources, les symboles et les produits attendus.
[ ] La signature et les profils de provisionnement sont valides.
[ ] La validation précédant l’envoi est enregistrée.
[ ] La procédure de publication fonctionne avec xcodebuild sans dépendance cachée.
[ ] Les tests iOS, s’ils existent, sont explicitement déplacés vers une machine disposant du Runtime.
[ ] Un fichier xcresult est conservé pour les tests exécutés dans l’environnement séparé.
[ ] La procédure de restauration indique quel Runtime installer et pour quelle destination.
[ ] La version exacte de Xcode 27 Beta ou de la version finale est inscrite dans la documentation interne.

Si un seul point lié à une destination simulée reste ambigu, ne supprimez pas le Runtime de la machine concernée. Déplacez d’abord cette tâche vers l’environnement de test ou rendez sa dépendance explicite.

Évaluez la configuration distante avec un vrai cycle de livraison

Un Mac distant n’est pas utile uniquement parce qu’il ouvre Xcode. Il doit conserver vos outils, accepter une connexion d’administration, exécuter les scripts avec les bonnes autorisations et rester accessible pendant la durée du cycle de publication. Pour une équipe qui ne veut pas acheter une machine dédiée à chaque rôle, vous pouvez commencer par une période courte sur MACGPU, puis reproduire la checklist avec votre dépôt réel.

Choisissez l’environnement en fonction des actions documentées :

pour Archive, signature et publication, demandez d’abord une configuration minimale ;
pour XCTest UI Tests ou plusieurs destinations, prévoyez un Runtime correspondant ;
pour Preview et validation visuelle, utilisez une machine de test distincte ;
pour une chaîne qui évolue encore, conservez une procédure d’ajout et de retrait des composants plutôt qu’une image figée non documentée.

Si vous recherchez une configuration Apple Silicon distante pour un essai de compilation, la page [des configurations Mac disponibles](https://macgpu.com/fr/m4-commander.html) peut servir de point de départ ; la décision finale doit toutefois venir de la liste de tâches et non d’un simple inventaire matériel.

Questions fréquentes

Une machine équipée de Xcode 27 peut-elle créer une Archive sans iOS Simulator installé ?

Oui, si la machine exécute uniquement la compilation, l’Archive Release, la signature et les contrôles précédant l’envoi. Le SDK de plateforme fourni avec Xcode reste nécessaire, mais le Runtime du simulateur n’est pas automatiquement requis. Vérifiez toutefois les scripts, la destination et les phases de test afin qu’aucun appel à simctl ou à un appareil simulé ne soit déclenché.

Un projet Storyboard doit-il conserver un Runtime Simulator pour compiler ?

Pas nécessairement avec Xcode 27 Beta : le mode Interface Builder toolchain est désormais le mode de compilation par défaut pour les documents UIKit et peut fonctionner sans Runtime de simulateur. Cette règle ne couvre pas les tests d’interface, Preview ou un projet qui force explicitement le mode simulator. Archivez un projet contenant ses vrais fichiers Storyboard et XIB avant de retirer le Runtime.

Quels composants Xcode faut-il installer sur une machine distante de publication iOS ?

Installez Xcode, le SDK iOS correspondant à la cible de compilation, les outils de ligne de commande et les éléments nécessaires à la signature et à la distribution. Ajoutez un Runtime Simulator uniquement pour les tests ou scripts qui lancent réellement une cible simulée. La liste doit venir du Scheme, du Test Plan, de la destination xcodebuild et des scripts du dépôt.

Peut-on supprimer le simulateur si l’on envoie seulement des builds à TestFlight ?

Oui, pour une chaîne limitée à l’Archive Release, à la signature, à la validation et à l’envoi, sous réserve qu’aucune étape ne lance de test sur simulateur. Conservez une procédure de restauration documentée et vérifiez un vrai projet après chaque mise à jour de Xcode. L’absence de Runtime prouve seulement que la publication fonctionne ; elle ne prouve pas que l’application a passé des tests d’interface.

Quelles tâches xcodebuild dépendent obligatoirement d’un simulateur ?

Les actions qui exécutent effectivement des tests iOS sur une destination simulée, notamment les XCTest UI Tests et les scénarios test-without-building ou build-for-testing destinés à cette destination, ont besoin d’un Runtime compatible. Une simple compilation ou une Archive n’a pas la même dépendance. Examinez la destination, le Scheme et le Test Plan, puis conservez le fichier xcresult.

Choisissez l’environnement selon votre responsabilité

Pour un serveur de publication, installer chaque Runtime disponible donne une impression de sécurité, mais ne remplace pas une cartographie des tâches. Si vous ne faites que compiler, archiver, signer et envoyer, la machine allégée est le choix le plus cohérent. Si vous devez exécuter XCTest UI Tests, SwiftUI Preview ou des contrôles de compatibilité, le Runtime devient une dépendance opérationnelle et mérite un environnement séparé.

Un poste local Windows ou Linux peut rester pratique pour le code, la documentation et une partie des outils multiplateformes, mais il ne remplace pas la chaîne macOS nécessaire à Xcode, à la signature et à la publication iOS. Acheter un Mac dédié n’est pas toujours pertinent pour un besoin ponctuel ; à l’inverse, une location n’est pas idéale pour une charge lourde constante ou pour un usage nécessitant des périphériques physiques. Pour valider votre cas sans immobiliser immédiatement un matériel permanent, louez auprès de MACGPU une période courte, commencez par la configuration de publication minimale, puis ajoutez un environnement Simulator uniquement si votre journal de tâches le justifie.