Échec du téléchargement de l’iOS Simulator de Xcode 26.6 : réparation sur Mac distant en 2026

Un projet peut afficher un SDK iOS dans Xcode alors que l’iOS Simulator runtime correspondant n’est pas installé. Ces deux éléments ne sont pas interchangeables. Le SDK sert à compiler ; le runtime fournit l’environnement nécessaire à l’exécution et aux tests.

Commencez par trois observations indépendantes :

xcode-select -p
xcrun simctl list runtimes
xcrun simctl list devices

La première commande indique le Developer Directory utilisé par les outils en ligne de commande. La deuxième liste les runtimes reconnus par CoreSimulator. La troisième montre les appareils créés et leur état. La documentation Apple sur la compilation et l’exécution d’une application Xcode confirme la séparation entre la construction, la sélection de la destination et l’exécution.

Interprétez les résultats ainsi :

• Le projet compile, mais simctl list runtimes ne montre pas la plateforme recherchée : le SDK est probablement disponible, mais le runtime manque ou n’est pas enregistré.
• Le runtime apparaît comme installé, mais aucun appareil ne démarre : examinez CoreSimulator, l’appareil lui-même et l’association avec l’Xcode actif.
• Le runtime et les appareils sont visibles, mais la compilation échoue : le problème se situe plutôt dans le projet, la destination, la signature ou la version d’Xcode.
• Les commandes renvoient des chemins incohérents avec l’application Xcode ouverte graphiquement : suspectez plusieurs installations ou un DEVELOPER_DIR imposé par l’environnement CI.

Ne supprimez donc pas les données de développement tant que vous n’avez pas enregistré ces trois sorties. Elles constituent votre état de référence.

Le cas des installations multiples

Sur un poste de développement, une version de Xcode peut être ouverte dans l’interface tandis que le terminal utilise une autre version. Cette situation est fréquente sur les nœuds CI réutilisés, surtout lorsqu’un script définit DEVELOPER_DIR ou lorsqu’un ancien chemin reste configuré.

Vérifiez le chemin actif :

xcode-select -p
xcodebuild -version
xcrun --find simctl

Comparez ces résultats avec l’emplacement réel de l’application Xcode 26.6 ouverte sur le Mac distant. Utilisez un espace réservé plutôt qu’un chemin copié d’une autre machine :

sudo xcode-select --switch /Applications/<Xcode-26.6>.app/Contents/Developer

Ne faites cette modification qu’après avoir démontré le décalage. Sur un nœud partagé, changer globalement le Developer Directory peut interrompre une autre tâche qui attend une version différente. Une meilleure pratique consiste à définir explicitement le chemin dans le job concerné :

export DEVELOPER_DIR=/Applications/<Xcode-26.6>.app/Contents/Developer

Conservez cette variable dans le journal du pipeline. Elle explique souvent pourquoi une installation visible dans l’interface n’est pas celle consultée par xcodebuild.

La première initialisation

Une installation fraîche peut encore attendre l’acceptation de la licence, la création de composants auxiliaires ou la finalisation de son initialisation. Exécutez l’initialisation depuis le Developer Directory vérifié :

sudo xcodebuild -runFirstLaunch

L’opération peut demander des droits administrateur et doit être exécutée avec le compte prévu pour les builds. Sur un Mac distant, vérifiez aussi que le compte de service possède un accès fonctionnel au trousseau, au répertoire de travail et aux outils nécessaires. Un lancement graphique réalisé sous un compte ne répare pas forcément l’environnement d’un autre compte utilisé par l’agent CI.

Relancez ensuite xcodebuild -version, xcrun simctl list runtimes et un projet minimal. Si le runtime reste absent, passez à la chaîne de téléchargement plutôt qu’à la suppression de Xcode.

« Preparing » et retour à la liste

Lorsque Xcode reste sur « Preparing », revient à l’écran des composants ou affiche une erreur de connexion, ne concluez pas immédiatement à un défaut de l’installation. Plusieurs causes ont le même symptôme :

• résolution DNS incomplète ou intermittente ;
• proxy qui filtre les téléchargements de composants ;
• pare-feu sortant ou inspection TLS ;
• fichier hosts modifié ;
• catalogue de composants momentanément indisponible ;
• session d’authentification ou permissions locales incomplètes.

La documentation Apple sur le téléchargement et l’installation des composants Xcode doit servir de référence pour le chemin pris par l’interface et les commandes disponibles. Pour les détails de version et de compatibilité, vérifiez aussi les notes de version de Xcode 26.4 lorsque votre parc conserve plusieurs générations d’outils.

Avant toute nouvelle tentative, capturez :

date
scutil --dns
env | grep -i proxy
grep -v '^[[:space:]]*#' /etc/hosts

Ajoutez au journal le nom du runtime demandé, le texte exact de l’erreur, l’heure locale, l’heure UTC si votre équipe est distribuée et le nœud concerné. Une erreur reproduite sur un seul Mac ne permet pas d’affirmer que le service de distribution est globalement défaillant. Les signalements du forum Apple Developer concernant les téléchargements de simulateurs sont utiles pour comparer les symptômes, mais ils ne constituent pas une confirmation officielle d’une panne généralisée.

Le téléchargement en ligne de commande

Lorsque l’interface graphique n’apporte pas assez de détails, essayez le mécanisme en ligne de commande documenté pour votre version de Xcode. Le schéma courant ressemble à celui-ci :

xcodebuild -downloadPlatform iOS

Utilisez le xcodebuild appartenant à Xcode 26.6, et non celui trouvé par hasard dans le PATH. Vérifiez d’abord :

xcrun --find xcodebuild
xcodebuild -version

Si la commande échoue, ne remplacez pas le message par une description vague comme « problème réseau ». Conservez le code de sortie et le journal complet. Un échec DNS, un refus de proxy et une absence de composant ont des remèdes différents.

Attention : un nœud distant utilisé par plusieurs équipes ne doit pas recevoir une modification permanente du proxy ou du fichier hosts uniquement pour contourner un essai. Documentez la règle appliquée, limitez-la au test, puis rétablissez la configuration après la vérification.

Les trois états de CoreSimulator

Un fichier de runtime peut exister sur le disque sans être utilisable. Pour prendre une décision, comparez toujours l’interface Xcode, simctl et le démarrage réel d’un appareil.

xcrun simctl list runtimes
xcrun simctl create <Nom-appareil> <Type-appareil> <Identifiant-runtime>
xcrun simctl boot <Identifiant-appareil>
xcrun simctl bootstatus <Identifiant-appareil> -b

Remplacez les valeurs entre chevrons par celles correspondant au nœud. N’inventez pas un identifiant de runtime : utilisez celui retourné par simctl list runtimes.

Vous pouvez rencontrer trois situations :

• Téléchargé mais non importé : le paquet a été obtenu, mais CoreSimulator ne le propose pas encore. Utilisez le flux officiel d’importation au lieu de copier un dossier partiel.
• Importé mais indisponible : le runtime est listé, mais son appareil ne démarre pas. Vérifiez l’état du service, les journaux et l’association avec l’Xcode actif.
• Appareil corrompu ou obsolète : le runtime fonctionne, mais un appareil créé avant le changement échoue. Créez un appareil de test neuf avant de supprimer les anciens.

La page Apple consacrée à l’ajout de simulateurs supplémentaires décrit le principe d’ajout de plateformes et de simulateurs. Elle ne transforme toutefois pas un fichier incomplet en runtime valide.

Ne supprimez pas immédiatement les répertoires CoreSimulator, les ressources système ou l’ensemble des données Developer. Cette action peut supprimer des appareils, des états de test, des caches utiles et des éléments nécessaires à une comparaison. Si elle devient nécessaire, exportez d’abord les journaux, notez les runtimes reconnus, sauvegardez les projets et préparez une procédure de restauration. Sur un nœud de production, une reconstruction contrôlée est souvent plus sûre qu’un nettoyage non réversible.

Exporter depuis un Mac fonctionnel

Pour un réseau filtré ou un parc de nœuds nombreux, le téléchargement répété sur chaque Mac est rarement une bonne stratégie. Apple documente un flux d’exportation et d’importation des plateformes Simulator. Le principe est de télécharger la plateforme sur une machine capable d’achever l’opération, puis de produire un paquet destiné au nœud cible.

Commencez par identifier précisément :

• la version de Xcode qui a téléchargé le composant ;
• la plateforme et la variante d’architecture demandées ;
• le chemin d’exportation ;
• l’identité du nœud source et du nœud cible ;
• le résultat de la vérification avant exportation.

Un exemple de structure, à adapter aux paramètres acceptés par votre version :

xcodebuild -downloadPlatform iOS
xcodebuild -exportPlatform iOS -exportPath <répertoire-export>

Transférez le paquet par un canal approuvé, puis importez-le sur le Mac distant avec la commande prévue par la documentation de votre version de Xcode :

xcodebuild -importPlatform <chemin-du-paquet>

Ne copiez pas directement un répertoire de runtime trouvé dans le système. Une copie interrompue peut manquer un manifeste, des permissions ou des métadonnées d’enregistrement. Après l’importation, répétez :

xcrun simctl list runtimes
xcrun simctl list devices

Notez le nom du paquet, son empreinte si votre procédure interne en utilise une, la date du transfert, le résultat de l’importation et le runtime finalement reconnu. Pour un déploiement en série, cette trace est plus utile qu’une simple mention « installation réussie ».

Le cas du Mac distant

Un Mac distant peut réutiliser un runtime téléchargé sur une autre machine si l’exportation et l’importation sont réalisées par le mécanisme pris en charge, avec une version compatible de Xcode et la bonne plateforme. Une archive de fichiers copiée manuellement n’offre pas la même garantie.

Avant l’importation, contrôlez l’espace disponible, les droits du compte de service, l’architecture du nœud et la version active de Xcode. Après l’importation, ne vous contentez pas de voir le runtime dans l’interface : démarrez un appareil et exécutez un test minimal. Cette distinction est essentielle pour une flotte de Mac distants destinée à la compilation et aux tests, car un composant affiché comme présent ne prouve pas que le pipeline pourra l’utiliser.

Le test minimal puis le projet réel

La réparation est terminée seulement lorsque le nœud survit à un cycle d’utilisation complet. Exécutez les contrôles dans cet ordre :

• [ ] xcode-select -p pointe vers l’application attendue.
• [ ] xcodebuild -version confirme Xcode 26.6.
• [ ] xcrun simctl list runtimes affiche le runtime requis comme disponible.
• [ ] Un appareil neuf peut être créé ou un appareil existant peut être démarré.
• [ ] xcrun simctl bootstatus termine sans erreur.
• [ ] Un projet minimal compile et s’exécute sur la destination Simulator.
• [ ] Le projet réel lance au moins le test représentatif qui échouait.
• [ ] Une reconnexion SSH ne laisse pas le job dans un état incohérent.
• [ ] Un redémarrage du Mac ne fait pas disparaître le runtime.
• [ ] Le redémarrage de Xcode conserve la destination et les composants attendus.

Le test SSH est important sur une machine sans écran local. Une session graphique interrompue ne doit pas être la condition cachée du fonctionnement du Simulator. Pour les tests automatisés, lancez également le job avec le même compte et le même DEVELOPER_DIR que la chaîne de production.

La décision de continuer ou de remplacer

Si le téléchargement fonctionne à nouveau, que le runtime est reconnu et que le projet réel passe après redémarrage, gardez le nœud et documentez la correction. Si le paquet s’importe mais que le runtime disparaît après redémarrage, isolez la machine : le problème peut concerner les permissions, le stockage ou l’image système.

Si plusieurs nettoyages ont déjà modifié le poste, la valeur de ses journaux baisse fortement. Dans ce cas, une machine propre permet de distinguer un problème reproductible du nœud d’un problème lié au réseau ou à la version de Xcode. C’est précisément le moment où un Mac distant neuf peut servir de référence, avant de décider de reconstruire l’ancien.

Un Mac local déjà utilisé pour le développement présente ici plusieurs limites : il peut être éteint pendant une fenêtre CI, son réseau domestique peut bloquer le téléchargement, et ses versions de Xcode peuvent évoluer au gré des besoins d’un seul utilisateur. Un serveur Linux ou une machine virtuelle non native ajoute une autre contrainte : il ne reproduit pas nécessairement le comportement du runtime iOS attendu par Xcode. Enfin, un poste qui a été nettoyé sans journal fiable coûte du temps à chaque nouvel incident.

Pour un besoin temporaire de validation, de préparation d’un runner ou de comparaison entre deux versions d’Xcode, louer un Mac distant auprès de CALMVPS peut donc être plus rationnel que continuer à réparer un nœud dont la base n’est plus crédible. Vous pouvez consulter les options de location de Mac distant, puis appliquer exactement la même séquence : sélectionner Xcode, initialiser, importer le runtime, lancer le projet réel et redémarrer la machine.

Cette approche ne convient pas à tous les cas. Si vous exécutez une charge lourde et stable pendant une longue période, si vous devez contrôler physiquement les ports ou si votre équipe possède déjà une infrastructure Mac correctement maintenue, l’achat et l’administration directe peuvent rester préférables. En revanche, pour un environnement de test ponctuel, un nœud CI de transition ou une reproduction rapide après un échec de téléchargement, un Mac distant propre évite de payer le coût caché des nettoyages successifs.

La règle finale est simple : ne réinstallez pas Xcode pour masquer un runtime absent. Établissez d’abord la preuve, utilisez l’exportation et l’importation prises en charge, puis remplacez le nœud lorsque son état ne permet plus une validation fiable.