On ne branche pas un iPhone sur un Mac distant pour Xcode

L'hypothèse habituelle est qu'une session de bureau à distance déplace tout l'environnement de développement sur votre portable. Elle déplace l'écran, le clavier et la souris, et rien d'autre. L'iPhone doit joindre le Mac qui exécute Xcode, et c'est une connexion distincte avec ses propres exigences de confiance, de transport et d'autorisations. Tout ce qui suit découle de cette séparation, et c'est là que la plupart des installations ratées perdent un après-midi.

Le mythe : le contrôle à distance déplace aussi l'appareil

Un logiciel de bureau à distance transmet un affichage et un flux de saisie, et sur une bonne connexion on croirait le Mac assis devant soi. Ce qu'il ne transmet pas, c'est l'USB, et il ne place pas non plus le téléphone sur le réseau du Mac. La session s'arrête au bureau du Mac, où Xcode doit ensuite trouver un appareil selon ses propres règles. Supposer que le téléphone voyage avec les pixels est l'erreur la plus courante dans cette configuration.

Les deux connexions sont indépendantes, et l'une peut être parfaite tandis que l'autre n'existe pas du tout. Réparer la session de bureau ne vous dit rien du chemin vers l'appareil.

Décidez où se trouve physiquement le téléphone avant de configurer quoi que ce soit

Si le téléphone reste à côté du Mac, faites-y l'installation locale habituelle : faites confiance à l'ordinateur, activez le mode développeur sur l'appareil et confirmez que Xcode compile et s'exécute dessus pendant que vous êtes assis devant la machine. Le bureau à distance contrôle alors un flux de travail qui fonctionne déjà. C'est la configuration la moins chère et celle à préférer chaque fois que le matériel le permet.

Si le téléphone voyage avec vous et que le Mac reste au bureau, le Mac a besoin d'un chemin pris en charge vers cet appareil. Un VPN fournit une route réseau entre les deux extrémités et ne fournit rien d'autre : l'appairage, le mode développeur, l'identité de signature et l'enregistrement de l'appareil restent des exigences distinctes. Traitez le tunnel comme une couche dans une pile, pas comme la connexion elle-même.

Notez dans laquelle des deux configurations vous êtes. Chaque vérification ultérieure en dépend, et les mélanger produit des correctifs qui ne peuvent pas fonctionner.

Traitez la découverte et le transport comme deux problèmes différents

Xcode trouve les appareils sans fil appairés via Bonjour sur le réseau local, et il peut aussi joindre un appareil à une adresse connue avec Connect via IP Address. Ce sont deux mécanismes avec deux modes de défaillance différents. Un appareil qui n'apparaît jamais dans la liste et un appareil qui apparaît mais refuse de s'attacher ne sont pas le même symptôme, même si les deux se lisent comme un téléphone manquant.

Parcourez l'annonce avant de changer quoi que ce soit : dns-sd -B _apple-mobdev2._tcp liste le service qu'un téléphone appairé publie sur le lien local. Si rien n'apparaît, la découverte est la couche cassée et une connexion par adresse est la seule voie restante. Si le service apparaît mais que Xcode ne peut toujours pas s'attacher, la découverte fonctionne et c'est le transport ou la relation de confiance qui échoue.

L'aide d'Apple sur les appareils sans fil couvre à la fois l'exigence du même réseau et le flux de travail par adresse, alors lisez-la en regard de vos versions installées au lieu de suivre un chemin de menu retenu d'une version plus ancienne. Les libellés des menus bougent d'une version de Xcode à l'autre même quand le mécanisme sous-jacent ne change pas.

Vérifiez ce que le Mac voit depuis sa place

Exécutez l'énumération sur le Mac, pas sur votre portable, car c'est le Mac qui a besoin de l'appareil. xcrun devicectl list devices imprime les appareils que Xcode peut joindre, et system_profiler SPUSBDataType montre ce qui est physiquement attaché. Un téléphone qui figure dans la seconde liste mais pas dans la première est attaché et non appairé, ce qui est un problème de confiance et non de réseau.

xcrun devicectl list devices
system_profiler SPUSBDataType | grep -i iphone
xcrun devicectl device info DEVICE_UDID

Si l'appareil se trouve sur un autre sous-réseau, confirmez que le Mac peut joindre l'adresse que publie le téléphone, et rappelez-vous que les adresses IPv6 locales au lien sont limitées à un lien et ne sont pas routables à travers un tunnel. C'est pourquoi un VPN seul fait rarement apparaître un téléphone distant : l'adresse annoncée par l'appareil n'a de sens que sur son propre segment.

La note technique TN3158 d'Apple indique que, depuis la version 15, Xcode parle à un appareil câblé via une interface réseau bâtie sur de l'IPv6 local au lien, si bien qu'un filtrage local peut gêner même un téléphone physiquement branché. Faites remonter ce cas à qui détient la politique de filtrage plutôt que de la désactiver vous-même.

Prouvez-le par une compilation, pas par une icône d'appareil

Une entrée d'appareil dans une liste, un indicateur vert dans la barre d'outils ou une invite d'appairage réussie sont des observations intermédiaires. Le flux de travail est prouvé quand Xcode installe une compilation autorisée et que le débogueur s'attache à un processus qui tourne sur l'appareil.

Exécutez la séquence complète depuis le Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installe sans l'IDE, ce qui sépare un problème d'interface de Xcode d'un problème de chemin vers l'appareil. Lancez ensuite l'application et attachez-y une console. Si l'installation en ligne de commande fonctionne et que l'IDE non, la panne restante est dans le schéma ou la configuration de signature, pas dans le réseau.

Gardez la configuration étroite : un développeur autorisé, un Mac enregistré, un appareil et un accès qui se termine avec la session. Révoquez les identifiants quand la configuration s'arrête. Si le téléphone peut simplement rester à côté du Mac, choisissez cela, car le chemin pris en charge le plus simple est celui qui laisse le moins de couches à déboguer.