Point vérifié au 5 septembre 2026 : les notes officielles de dotnet/macios indiquent la prise en charge de Xcode 26.6, tandis que .NET MAUI 10.0.100 est marqué comme publié le 20 août 2026 dans les informations officielles de .NET MAUI. En cas d’échec du build distant .NET MAUI 10, construisez donc d’abord un projet minimal directement sur le Mac. Si ce test échoue, corrigez l’outillage ; s’il réussit, concentrez-vous sur Pair to Mac, le compte distant, les caches ou la commande Windows, et ne reconstruisez le nœud qu’en présence d’une dérive persistante.

À qui s’adresse ce diagnostic

Ce guide concerne les développeurs qui utilisent Visual Studio sous Windows pour compiler et publier une application .NET MAUI iOS sur un Mac distant, ainsi que les ingénieurs DevOps qui maintiennent ce nœud de construction.

Il s’adresse aussi aux responsables mobiles qui doivent décider s’il faut poursuivre la mise à niveau vers Xcode 26.6, revenir temporairement à un couple d’outils connu, faire fonctionner deux chaînes en parallèle ou remplacer un environnement devenu impossible à isoler.

Dernière mise à jour : 5 septembre 2026. Les éléments de version ont été vérifiés dans la documentation .NET MAUI 10, les publications officielles de .NET for iOS et le guide Pair to Mac. Une nouvelle révision est nécessaire si une version de service .NET MAUI 10 paraît, si la prise en charge de Xcode change, si la documentation Pair to Mac est modifiée ou si le nœud distant reçoit une nouvelle chaîne d’outils.

Commencez par une preuve reproductible, pas par le dernier message d’erreur

Un message comme « build failed » ne permet pas de déterminer si le problème vient du réseau, du SDK, de Xcode ou de la signature. Avant toute suppression de cache ou réinstallation, les deux côtés doivent conserver une photographie identique de l’échec :

  • version du SDK .NET détectée par Windows et par le Mac ;
  • liste et version de la charge de travail .NET MAUI installée ;
  • version effective de .NET for iOS ;
  • projet, configuration, cible et RuntimeIdentifier utilisés ;
  • chemin Xcode réellement sélectionné ;
  • compte distant, adresse, port et méthode d’authentification ;
  • journal binaire ou sortie détaillée, avec le premier message d’erreur exploitable.

Le même dépôt doit ensuite être testé dans deux conditions. Sur le Mac, un projet minimal doit être construit directement avec la commande .NET habituelle. Depuis Windows, le même projet doit être envoyé par Pair to Mac avec une sortie détaillée. Cette comparaison répond à une question déterminante : le Mac ne sait-il pas construire, ou Windows ne parvient-il pas à lui demander correctement la construction ?

À retenir : « connecté » signifie seulement que Pair to Mac a établi une relation avec l’hôte. Cela ne prouve ni que Xcode est utilisable, ni que .NET for iOS est compatible, ni que le compte de service peut accéder au trousseau.

Donnez au responsable Windows une frontière claire entre réseau et projet

Le développeur Windows doit commencer par vérifier la couche de connexion sans utiliser le projet métier. Un projet iOS .NET MAUI vierge, avec un nom et un chemin neutres, sert de sonde : il évite qu’un paquet NuGet, une cible personnalisée ou un script de publication ne masque une panne de l’environnement.

La vérification doit progresser dans cet ordre :

  • confirmer que le nom ou l’adresse de l’hôte distant est résolu depuis Windows ;
  • tester le port SSH prévu avec le compte système fourni ;
  • vérifier que la clé privée correspond bien à la clé autorisée sur le Mac ;
  • confirmer le nom d’utilisateur macOS, sans le déduire du nom affiché dans l’interface ;
  • ouvrir Pair to Mac et distinguer « hôte introuvable », « authentification refusée » et « service distant non initialisé » ;
  • lancer un build minimal après connexion, sans reprendre immédiatement les paramètres du projet de production.

Le fonctionnement de Pair to Mac repose sur SSH pour appeler le Mac de construction ; les détails de ce mécanisme figurent dans la documentation officielle Pair to Mac. Une connexion graphique ou une simple réponse au réseau ne remplace donc pas la validation du compte et du service distant.

Si Visual Studio conserve une association obsolète, il est préférable de supprimer cette seule relation puis de l’enregistrer à nouveau. Avant cette opération, le développeur doit conserver l’adresse, le compte, le port et le chemin de la clé afin de pouvoir revenir à l’état précédent. La suppression globale des clés ou des profils est disproportionnée tant que la cause exacte n’est pas connue.

Arrêt conseillé : si le projet minimal ne peut pas être construit depuis Windows mais réussit directement sur le Mac, le développeur Windows transmet au responsable CI le journal Pair to Mac, l’hôte utilisé et le premier échec. Il ne réinstalle pas la charge de travail sur la base d’un problème de connexion.

Faites vérifier à l’équipe mobile le couple .NET MAUI 10 et Xcode 26.6

Le nom du paquet .NET MAUI visible dans l’IDE ne suffit pas à prouver que le projet utilise la bonne chaîne iOS. Le diagnostic doit porter sur le SDK sélectionné, la charge de travail réellement résolue, la version de .NET for iOS et les propriétés de construction produites par le projet.

Le contrôle du responsable applicatif doit couvrir les éléments suivants :

  • exécuter les commandes d’information du SDK sur le Mac et dans le contexte distant réellement utilisé ;
  • comparer la charge de travail installée avec celle exigée par la version de .NET MAUI 10 retenue ;
  • vérifier la version de Xcode supportée par la publication .NET for iOS ;
  • inspecter la sortie de xcode-select --print-path ;
  • rechercher une variable DEVELOPER_DIR définie dans le compte, le service CI ou le script ;
  • vérifier que Visual Studio, le shell interactif et le processus distant ne sélectionnent pas trois installations différentes ;
  • relancer le projet minimal après chaque correction, avec le même objectif de compilation.

Le document de dépannage .NET MAUI explique notamment où contrôler la sélection de Xcode et les erreurs courantes. La conclusion pratique est simple : Xcode 26.6 peut être officiellement pris en charge, mais un projet peut tout de même appeler une autre installation ou une charge de travail décalée.

Pour plusieurs versions de Xcode, la sélection doit être attachée à la tâche ou au nœud qui en a besoin. Une modification globale et non documentée de xcode-select peut réparer un projet et en casser un autre. Un responsable de plateforme doit donc conserver l’ancien couple dans un nœud séparé ou dans une procédure de retour clairement testée, plutôt que d’alterner manuellement les chemins pendant une publication.

Arrêt conseillé : si le projet minimal échoue directement sur le Mac avec un message indiquant une incompatibilité d’outil, la connexion Windows est hors sujet. Le propriétaire de l’environnement corrige le SDK, la charge de travail ou Xcode, puis remet le journal Mac à l’équipe applicative.

Faites comparer les environnements par l’ingénieur CI

Lorsque Visual Studio réussit mais qu’une commande Windows échoue, ou lorsque deux pipelines donnent des résultats différents, l’ingénieur CI doit rechercher les différences implicites. Les paramètres à comparer sont l’adresse du Mac, le compte, le port, le dossier SDK distant, le répertoire du projet et la configuration de build.

Un écart fréquent apparaît lorsque obj contient des sorties produites par un autre SDK ou une autre cible. Le nettoyage doit rester local et justifié : conserver les journaux, supprimer seulement les artefacts du projet concerné, puis relancer le même test. Un nettoyage large du cache de l’utilisateur ou une réinstallation complète détruit souvent l’indice qui permettait d’identifier la dérive.

La validation CI doit partir d’un clone propre, d’une version d’outillage explicitement choisie et d’un compte de service documenté. Le pipeline doit également enregistrer la version du SDK, la charge de travail, le chemin Xcode, le RuntimeIdentifier et le premier échec. Ces informations permettent de comparer une exécution Visual Studio avec une exécution sans interface graphique.

La commande de publication doit être introduite seulement après la réussite du build minimal. Les indications de Microsoft sur la publication iOS en ligne de commande servent de référence pour vérifier les propriétés transmises, mais elles ne remplacent pas la validation du contexte distant.

Isolez enfin la signature, l’appareil et l’archive

Un build Debug ou simulateur réussi ne valide pas une publication Release sur appareil. À ce stade, le problème ne doit plus être attribué automatiquement à Pair to Mac.

Le responsable de publication vérifie séparément :

  • l’identité de signature demandée par la configuration ;
  • le profil de provisioning associé à l’identifiant d’application ;
  • l’accès du compte distant au trousseau ;
  • le RuntimeIdentifier de la cible ;
  • la visibilité de l’appareil depuis le Mac ;
  • les variables et secrets réellement disponibles dans le processus CI ;
  • la possibilité de créer une compilation sans signature avant l’archive officielle.

Une expérience minimale est plus informative qu’une nouvelle installation : produire d’abord un binaire non signé, effectuer ensuite une signature avec une identité connue, puis lancer l’archive complète. Si la première étape passe et la seconde échoue, la chaîne de compilation est probablement saine. Le propriétaire du certificat ou du profil reprend alors le dossier, avec le journal et le compte d’exécution exacts.

Les certificats et mots de passe ne doivent jamais être copiés dans un ticket ou dans un script de diagnostic. Les exemples de cette procédure doivent rester génériques, tels que <COMPTE_MAC>, <ADRESSE_MAC>, <CHEMIN_PROJET> et <IDENTITE_SIGNATURE>.

Utilisez cette matrice avant de choisir une réparation

Le tableau suivant sépare les quatre états qui sont souvent confondus. Il permet de transmettre le problème au bon rôle plutôt que de demander une reconstruction prématurée du Mac.

État observé Ce qui est réellement validé Prochaine vérification Responsable
Pair to Mac connecté SSH et initialisation de la relation distante Projet minimal sur le Mac puis depuis Windows Développeur Windows
Build local Mac réussi SDK, charge de travail et Xcode utilisables localement Même projet via Pair to Mac Ingénieur CI
Build distant réussi Transport, commande et compilation à distance Signature, appareil et archive Responsable de publication
Archive signée réussie Chaîne de publication complète pour cette cible Reconnexion et reprise après redémarrage Responsable de plateforme

Le deuxième tableau aide à choisir une action proportionnée. Il ne faut pas confondre le prix d’un nouvel environnement avec le coût opérationnel d’un changement non vérifié : sans données tarifaires ou de configuration propres au nœud concerné, aucune estimation chiffrée ne doit être inventée.

Signal observé Action prioritaire Ce qu’il faut éviter
Échec local reproductible avec Xcode 26.6 Aligner SDK, .NET for iOS, charge de travail et sélection Xcode Effacer les clés Pair to Mac
Réussite locale, échec distant Recréer uniquement l’association et comparer le contexte SSH Réinstaller toute la chaîne
Réussite Debug, échec Release signé Tester identité, profil, trousseau et RuntimeIdentifier Modifier Xcode sans preuve
Échecs différents selon le projet Comparer les versions et les propriétés par dépôt Déclarer le nœud globalement défectueux
Échecs intermittents sur plusieurs projets Isoler un nœud de référence et mesurer après redémarrage Déplacer immédiatement toute la production

Validez la réparation avec une checklist exploitable

Avant de déclarer le nœud rétabli, le responsable de plateforme doit pouvoir cocher chaque condition suivante :

  • [ ] Le SDK .NET, la charge de travail et .NET for iOS sont enregistrés des deux côtés.
  • [ ] Le chemin Xcode est identique entre le shell de diagnostic, le service CI et l’IDE.
  • [ ] Le projet minimal réussit directement sur le Mac.
  • [ ] Le même projet minimal réussit depuis Windows avec Pair to Mac.
  • [ ] Le projet métier réussit après un clone propre, sans dépendre d’un obj ancien.
  • [ ] La compilation sans signature et l’expérience de signature minimale sont séparées.
  • [ ] Le compte distant retrouve le trousseau requis sans exposer de secret.
  • [ ] Une déconnexion puis une reconnexion reproduisent le résultat.
  • [ ] Un redémarrage du Mac est suivi d’une nouvelle construction réussie.
  • [ ] Une tâche réelle de publication termine avec le même RuntimeIdentifier et le même profil.

La dernière vérification est importante : un environnement qui fonctionne seulement après une session graphique manuelle n’est pas encore un nœud CI fiable. Dans ce cas, le résultat doit être transmis comme « réparation partielle », avec la condition de reprise documentée.

Décidez entre correction, retour temporaire et reconstruction

Le tableau final fournit une règle de décision pour le responsable de plateforme. Une correction locale est préférable lorsque le problème est reproductible, expliqué et limité à un projet ou à une version. Deux chaînes peuvent fonctionner en parallèle lorsque plusieurs projets ne peuvent pas migrer au même moment, à condition que les chemins Xcode, SDK et charges de travail soient isolés.

Décision Conditions minimales Critère d’arrêt
Corriger le nœud actuel Le build local et le build distant deviennent reproductibles après alignement Revenir au diagnostic si un autre projet dérive
Revenir temporairement Une version connue fonctionne et la nouvelle version échoue avec une preuve locale Ne pas présenter le retour comme une correction définitive
Faire fonctionner deux chaînes Les projets ont des exigences Xcode distinctes et des nœuds séparés Refuser le partage de caches et de chemins globaux
Reconstruire un nœud Plusieurs projets échouent de façon instable, même après isolement Refaire la checklist avant migration de production

La reconstruction n’est donc pas la première étape. Elle devient raisonnable lorsque l’état ne peut plus être expliqué, que les versions ne peuvent pas être fixées, ou que le comportement change après redémarrage sans modification déclarée. Avant de déplacer la production, un Mac distant neuf doit réussir le projet minimal, le build Windows, la signature et la reprise après redémarrage.

Si le Mac actuellement utilisé ne permet pas d’isoler Xcode et les charges de travail .NET, une machine distante séparée peut servir de nœud d’essai. Les offres Mac distantes de RUVCLOUD permettent d’évaluer cette approche sans confondre immédiatement le test de compatibilité avec une migration de toute la chaîne. Pour une équipe qui veut d’abord vérifier l’accès et les droits, l’environnement Mac de RUVCLOUD doit être testé avec le projet minimal, Pair to Mac, une construction propre et une signature contrôlée.

Un environnement Windows associé à un Mac distant conserve toutefois des inconvénients réels : la compilation dépend de la latence et de la session SSH, les caches peuvent diverger entre deux clients, et la signature reste attachée au trousseau du Mac. À l’inverse, l’achat d’un Mac mini immobilise du matériel et ne résout pas automatiquement la séparation de versions. Pour un test temporaire, une migration progressive ou un nœud de publication isolé, louer un Mac avec des droits complets auprès de RUVCLOUD peut donc être plus simple à valider ; pour une charge permanente et parfaitement stable, le Mac dédié reste à comparer selon les contraintes matérielles et de gouvernance.

Questions fréquentes

Pourquoi .NET MAUI 10 se connecte-t-il au Mac mais ne construit-il pas l’application iOS ?

Une connexion Pair to Mac réussie prouve seulement que la session distante peut être ouverte. Le build peut encore échouer parce que le Mac utilise un SDK .NET différent, une charge .NET for iOS incompatible avec Xcode 26.6, un mauvais chemin xcode-select ou une configuration de projet non supportée. Un projet minimal construit directement sur le Mac permet de séparer ces causes.

Que faire si Pair to Mac ne trouve plus le Mac distant ou redemande l’authentification ?

Commencez par vérifier la résolution du nom, le port SSH, le compte système et la clé utilisée, puis distinguez l’hôte invisible de l’authentification refusée. Si l’enregistrement Visual Studio est incohérent, supprimez uniquement cette association et recréez-la avec les mêmes identifiants validés. Ne supprimez pas toutes les clés avant d’avoir conservé une voie de récupération.

Comment corriger l’incompatibilité entre Xcode 26.6 et .NET for iOS ?

Comparez la version réellement chargée par le projet avec la matrice de prise en charge officielle, puis contrôlez xcode-select, DEVELOPER_DIR et le chemin configuré dans l’IDE. Si plusieurs Xcode sont installés, choisissez la version au niveau de la tâche ou du nœud dédié plutôt que de modifier globalement le système sans journaliser le changement.

Comment vérifier depuis Windows un build MAUI iOS exécuté sur un Mac distant ?

Lancez d’abord le même projet minimal sur le Mac avec dotnet build, en journalisant le SDK, la charge de travail, la cible et le chemin Xcode. Depuis Windows, utilisez ensuite une commande de publication ou de construction avec un niveau de journal détaillé, le même compte distant et le même projet propre. Comparez le premier échec utile, et non la dernière ligne de sortie.

Pourquoi le build distant réussit-il alors que la publication signée MAUI iOS échoue ?

La compilation et la publication signée sont deux validations différentes. Une identité de signature absente, un profil incompatible, un trousseau inaccessible au compte de service, un RuntimeIdentifier incorrect ou un appareil invisible peuvent bloquer l’archive après un build réussi. Reproduisez d’abord une compilation sans signature, puis une signature minimale avant de relancer l’archive officielle.