Le 15 octobre 2026, GitHub a annoncé la disponibilité générale de ses images Runner Xcode 27, exécutées sous macOS 27 et proposées avec les étiquettes xcode-27 et xcode-27-xlarge ; ces Runner sont exclusivement Apple Silicon (annonce officielle). Si xcodebuild ne trouve pas votre simulateur, vérifiez d’abord l’image réellement attribuée au job et le Xcode actif, puis les runtimes et la destination du scheme. Ne réinstallez pas Xcode et ne modifiez pas le projet avant d’avoir identifié la couche en échec.

Ce guide s’adresse aux ingénieurs CI qui viennent d’adopter le Runner Xcode 27 de GitHub Actions pour tester avec iOS Simulator.
Il est aussi destiné aux développeurs confrontés à une destination ou à un Runtime indisponible.
Les ingénieurs DevOps y trouveront des critères pour décider si un test doit être rejoué sur un environnement Mac distinct.

Dernière vérification : 17 octobre 2026, à partir de l’annonce GitHub, du README de l’image macOS Xcode 27 et de la documentation Apple citée ci-dessous. Le contenu des images hébergées évolue : la liste disponible à cette date ne constitue pas une garantie pour les exécutions futures.

Image et exécution réelles du Runner

Une étiquette dans le fichier workflow exprime une demande ; elle ne remplace pas les preuves du job exécuté. Pour comprendre pourquoi le Runner Xcode 27 de GitHub Actions ne trouve pas iOS Simulator, commencez par relever, dans le journal du job concerné, l’étiquette demandée, l’image ou la version de l’image annoncée et l’étape qui échoue. GitHub explique comment consulter les journaux d’exécution dans son guide des logs de workflow.

Recherchez ensuite la partie du workflow qui sélectionne le Runner, puis comparez-la aux premières lignes de diagnostic enregistrées par le job. Si l’échec survient avant le lancement de xcodebuild, ce n’est pas encore un problème de destination. Si le build aboutit mais que les tests ne démarrent pas, examinez plutôt la résolution de la destination ou le démarrage du simulateur.

L’annonce du 15 octobre confirme les étiquettes xcode-27 et xcode-27-xlarge, macOS 27, la chaîne d’outils Xcode 27 et les SDK Apple, ainsi que l’utilisation exclusive de Runner Apple Silicon. Elle ne garantit pas que chaque Runtime, type d’appareil ou version du système demandé sera présent dans chaque version future de l’image. Pour le contenu précis, vérifiez le README de l’image Xcode 27, puis conservez la version d’image observée avec les logs.

Indice observé Ce qu’il permet de conclure Contrôle suivant
Le job n’atteint pas l’étape de compilation L’erreur peut précéder Xcode et la résolution des simulateurs Lire les événements de sélection du Runner et les premières erreurs
xcodebuild démarre, mais échoue avant le build La chaîne d’outils ou les paramètres de commande peuvent être en cause Vérifier le Xcode actif et les arguments transmis
Le build réussit, mais aucune destination ne correspond L’échec porte probablement sur le scheme, la plateforme ou la destination Comparer -showdestinations et la destination demandée
Le simulateur est choisi, puis le test échoue La correspondance a abouti ; rechercher un problème de démarrage ou de test Conserver le journal complet et les résultats de test

Scheme et plateforme visés

Le message « Unable to find a destination matching the provided destination specifier » indique que la destination demandée ne correspond pas à une destination reconnue pour cette commande. Il ne prouve pas, à lui seul, que le Runtime est absent. Vérifiez ensemble le scheme, la cible de test, la plateforme demandée et les filtres appliqués par le workflow.

Que vérifier avant de modifier xcodebuild ?

Sur le Runner, demandez à Xcode d’afficher les destinations connues pour le scheme utilisé :

xcodebuild -showdestinations -scheme "NomDuScheme"

Remplacez le nom par celui du scheme réellement sélectionné dans la commande de test. Dans la sortie, relevez les destinations disponibles et celles indiquées comme inéligibles. Comparez ces informations avec les arguments -destination ou les réglages que votre action de test transmet à xcodebuild.

Une destination peut être inéligible pour des raisons différentes : plateforme qui ne correspond pas à la cible, version du système demandée absente, nom d’appareil qui ne correspond à aucun choix disponible, ou scheme qui ne contient pas le test attendu. Vérifiez aussi que la cible est configurée pour la plateforme sur laquelle le workflow tente de lancer les tests. Un test macOS ne devient pas un test iOS parce que la commande demande un simulateur iOS.

Élément à comparer Exemple de preuve à relever Si les valeurs divergent
Scheme Scheme transmis à xcodebuild et scheme du projet Confirmer que le job utilise le bon scheme
Cible de test Cible réellement incluse par la commande Vérifier qu’elle correspond à la plateforme visée
Destination demandée Nom, plateforme et version système transmis au job Reprendre les valeurs parmi les destinations éligibles
Résultat de -showdestinations Destinations éligibles et motifs d’inéligibilité Isoler le filtre ou la condition incompatible

Ne corrigez pas une faute de nom en changeant toute la configuration du projet. Faites d’abord correspondre la valeur demandée à la sortie observée. Si la destination figure dans la liste mais reste inéligible, le motif fourni est plus utile qu’une tentative au hasard avec un autre nom d’appareil.

Runtime et inventaire du simulateur

La présence de Xcode 27 n’implique pas que le Runtime iOS précis demandé par le workflow soit installé. Les images Runner sont mises à jour ; leur inventaire peut donc changer. Vérifiez la machine de l’exécution en échec plutôt que de vous fier à un ancien log, à une capture d’écran ou à une liste relevée sur un autre Runner.

Comment vérifier le Runtime installé sur xcode-27 ?

Commencez par interroger le simulateur sur la machine du job :

xcrun simctl list runtimes
xcrun simctl list devices available

La première commande aide à établir quels runtimes sont visibles par l’installation active. La seconde recense les appareils disponibles associés à l’environnement courant. Comparez ces sorties à la plateforme, au nom d’appareil et à la version du système demandés dans le workflow. Pour vérifier ce que l’image déclare inclure, confrontez ces résultats au README officiel de l’image ; le diagnostic du job reste la preuve de ce qui était accessible lors de cette exécution.

Résultat constaté Diagnostic probable Action vérifiable
Le Runtime demandé n’apparaît pas dans simctl list runtimes Runtime absent de l’environnement actif ou non visible par ce Xcode Comparer le Xcode sélectionné et l’inventaire déclaré par l’image
Le Runtime existe, mais aucun appareil demandé n’apparaît Type d’appareil indisponible ou filtre de destination inadapté Utiliser la liste des appareils disponibles pour ajuster la destination
L’appareil apparaît, mais le test ne démarre pas La découverte du simulateur a fonctionné ; l’échec survient après Examiner le lancement, les logs et le résultat de test
Le README et le job ne concordent pas Image mise à jour, différence d’environnement ou diagnostic incomplet Enregistrer la version d’image et reproduire avec les mêmes paramètres

Si le Runtime doit être ajouté, suivez uniquement la méthode d’Apple pour télécharger et installer des composants Xcode supplémentaires. Sur un Runner temporaire, évaluez d’abord si cette installation est autorisée, reproductible et suffisamment stable pour votre pipeline. Installer un composant à chaque exécution sans vérifier son résultat peut masquer le vrai problème et allonger le diagnostic sans rendre l’environnement constant.

À retenir : la sortie de simctl décrit l’environnement de la tâche observée. Une liste provenant d’un autre job ou d’une exécution antérieure ne suffit pas à prouver que le même Runtime est disponible aujourd’hui.

Xcode actif et chemin des outils

Un Runner peut contenir plusieurs installations ou composants de développement, tandis que les commandes utilisent un seul répertoire de développement actif. Un label qui évoque Xcode 27 n’est donc pas, à lui seul, une preuve du binaire effectivement invoqué par votre script.

Relevez le chemin actif et la version réellement exécutée :

xcode-select -p
xcodebuild -version

Ajoutez ces commandes au job de diagnostic avant les tests, puis conservez leurs sorties avec le log complet. Apple documente le réglage des outils en ligne de commande et du répertoire de développement actif dans sa page sur la configuration des outils en ligne de commande Xcode. Vérifiez que le chemin affiché et la version déclarée correspondent à l’environnement attendu par le job.

Distinguez trois situations. D’abord, l’image peut proposer plusieurs outils et le répertoire actif peut pointer ailleurs que prévu. Ensuite, le workflow peut sélectionner une configuration qui n’emploie pas l’installation attendue. Enfin, l’installation active peut ne pas exposer le Runtime ou le composant requis par la destination. Ces cas demandent des corrections différentes : ne changez pas le projet si la commande s’exécute avec le mauvais Xcode.

Pour localiser l’étape fautive, consignez les sorties juste avant xcodebuild, puis comparez-les avec le chemin et les arguments visibles dans le log. La documentation Apple sur les tests automatisés avec Xcode fournit le contexte utile pour distinguer l’invocation de la commande de l’exécution des tests.

Nom d’appareil, état et lancement

Quand simctl affiche l’appareil attendu mais que le workflow échoue encore, cessez de traiter le problème comme une absence de destination. Comparez le nom exact, la version du système et, si votre outil la transmet, l’identifiant de l’appareil avec la liste de l’exécution en cours. Vérifiez aussi que la commande de test n’ajoute pas un filtre différent de celui que vous avez inspecté manuellement.

Un cas fréquent en CI est un job qui demande une combinaison précise, puis passe à une autre étape qui sélectionne un appareil par nom. Si les deux commandes ne partagent pas la même configuration, le diagnostic initial et l’échec final peuvent viser des appareils différents. Conservez la commande complète développée par le workflow et les sorties du Runner, plutôt que de ne garder que la dernière ligne d’erreur.

La distinction pratique est la suivante : si -showdestinations ne propose pas de destination correspondante, continuez l’enquête sur le scheme, le Runtime et les filtres. Si la destination est reconnue, mais que le simulateur ne démarre pas ou que le test échoue après son lancement, examinez les logs de démarrage et les résultats de test. Les journaux d’exécution GitHub permettent de revenir à l’étape exacte, et les instructions Apple sur les tests automatisés aident à séparer sélection de destination et exécution du test.

Liste de contrôle avant changement d’environnement

Avant de réécrire le workflow ou de déplacer la tâche, validez chaque point avec les sorties de la même exécution :

  • [ ] Le journal indique l’étiquette du Runner demandée et l’image effectivement utilisée.
  • [ ] L’étape qui échoue est identifiée : sélection du Runner, invocation de Xcode, résolution de destination, démarrage ou test.
  • [ ] xcode-select -p et xcodebuild -version correspondent à la chaîne d’outils attendue.
  • [ ] xcrun simctl list runtimes contient le Runtime demandé.
  • [ ] xcrun simctl list devices available contient un appareil compatible avec la destination.
  • [ ] xcodebuild -showdestinations -scheme "NomDuScheme" confirme une destination éligible.
  • [ ] Le scheme, la cible, la plateforme et la destination du workflow décrivent le même test.
  • [ ] Les logs et les résultats de test sont conservés pour comparer les nouvelles exécutions.

Pour une reproduction fiable, relancez le même commit avec le même scheme et une image identifiée. Comparez séparément le résultat du build, la résolution de la destination, le lancement du simulateur et l’issue du test. Une seule exécution « verte » ne suffit pas à expliquer un échec intermittent si l’image ou les paramètres ont changé entre les essais.

Décision après le diagnostic

Les Runner hébergés évitent de maintenir un hôte physique, mais l’image et son inventaire évoluent ; vous devez donc enregistrer les éléments utiles à chaque diagnostic. Un Mac dédié offre davantage de contrôle sur l’environnement et sa préparation, mais implique de gérer l’accès, la disponibilité et l’entretien de cet hôte. Le choix dépend de la reproductibilité requise et des contraintes du test, pas du seul nom de l’erreur.

Quand déplacer un test vers un Mac distant ?

Envisagez un environnement distinct si le Runtime requis ou la configuration de machine ne peut pas être maintenu de façon reproductible sur le Runner hébergé, ou si vous devez reproduire un échec avec une chaîne d’outils contrôlée. Avant de transférer le job, vérifiez les possibilités et les limites documentées des Runner hébergés par GitHub, puis comparez-les aux besoins réels de votre pipeline.

Déplacer le test ne dispense pas de contrôler le scheme, les versions d’outils, les variables et la destination. Il faut pouvoir rejouer le même commit et conserver les preuves du build, du démarrage du simulateur et du résultat. Et Simulator ne remplace pas une validation sur appareil réel lorsque votre exigence porte sur le comportement matériel ou les conditions propres à un appareil.

Si l’échec reste propre au Runner hébergé, tandis que vos tests exigent un environnement macOS préparé et contrôlable, vous pouvez examiner les options de Mac mini cloud de MACCOME comme environnement d’exécution distinct. À l’inverse, si vous avez besoin d’un hôte local permanent ou d’un accès physique à des périphériques, la location distante peut ne pas convenir ; un Mac acheté et administré par votre équipe sera alors plus adapté. Les Runner hébergés restent pratiques pour les jobs qui tolèrent leur environnement géré, mais ils vous laissent moins de contrôle sur l’image et les composants disponibles.

Pour un essai ciblé, comparez d’abord les exigences de votre tâche aux possibilités d’un environnement Mac distant, sans migrer toute la CI. Vous pouvez consulter les solutions Mac à distance proposées par MACCOME et décider sur la base des sorties de diagnostic, de la reproductibilité attendue et des contraintes d’accès de votre équipe.