No n'hi ha prou de connectar un iPhone a un Mac remot per a Xcode

La suposició habitual és que una sessió d'escriptori remot trasllada tot l'entorn de desenvolupament al vostre portàtil. Trasllada la pantalla, el teclat i el ratolí, i res més. L'iPhone ha d'arribar al Mac que executa Xcode, i això és una connexió a part amb els seus propis requisits de confiança, transport i permisos. Tot el que segueix es desprèn d'aquesta separació, i és aquí on la majoria de configuracions fallides perden una tarda.

El mite: el control remot també mou el dispositiu

El programari d'escriptori remot reenvia una pantalla i un flux d'entrada, i amb una bona connexió sembla que el Mac se us estigui assegut al davant. El que no reenvia és l'USB, i tampoc posa el telèfon a la xarxa del Mac. La sessió acaba a l'escriptori del Mac, on Xcode després ha de trobar un dispositiu segons les seves pròpies regles. Suposar que el telèfon viatja amb els píxels és l'error més comú d'aquest muntatge.

Les dues connexions són independents, i una pot ser perfecta mentre l'altra no existeix en absolut. Reparar la sessió d'escriptori no us diu res sobre el camí cap al dispositiu.

Decidiu on és físicament el telèfon abans de configurar res

Si el telèfon es queda al costat del Mac, feu-hi la configuració local habitual: confieu en l'ordinador, activeu el mode de desenvolupador al dispositiu i confirmeu que Xcode compila i s'hi executa mentre sou asseguts davant la màquina. Llavors l'escriptori remot controla un flux de treball que ja funciona. Aquesta és la configuració més barata i la que cal preferir sempre que el maquinari ho permeti.

Si el telèfon viatja amb vosaltres i el Mac es queda a l'oficina, el Mac necessita un camí compatible fins a aquest dispositiu. Una VPN forneix una ruta de xarxa entre els dos extrems i no forneix res més: l'aparellament, el mode de desenvolupador, la identitat de signatura i el registre del dispositiu continuen sent requisits a part. Tracteu el túnel com una capa més d'una pila, no com la connexió en si.

Anoteu en quina de les dues configuracions sou. Totes les comprovacions posteriors en depenen, i barrejar-les produeix arranjaments que no poden funcionar.

Tracteu el descobriment i el transport com dos problemes diferents

Xcode troba els dispositius sense fil aparellats mitjançant Bonjour a la xarxa local, i també pot arribar a un dispositiu en una adreça coneguda amb Connect via IP Address. Són dos mecanismes amb dues maneres de fallar diferents. Un dispositiu que no apareix mai a la llista i un dispositiu que apareix però es nega a connectar-se no són el mateix símptoma, tot i que tots dos es llegeixen com un telèfon que falta.

Exploreu l'anunci abans de canviar res: dns-sd -B _apple-mobdev2._tcp llista el servei que publica un telèfon aparellat a l'enllaç local. Si no apareix res, el descobriment és la capa trencada i una connexió basada en adreça és l'únic camí que queda. Si el servei apareix però Xcode encara no es pot connectar, el descobriment funciona i el que falla és el transport o la relació de confiança.

L'ajuda d'Apple sobre dispositius sense fil cobreix tant el requisit de la mateixa xarxa com el flux de treball amb adreça, així que llegiu-la segons les versions que teniu instal·lades en lloc de seguir un camí de menú recordat d'una versió anterior. Les etiquetes dels menús es mouen entre versions de Xcode encara que el mecanisme de sota no canviï.

Comproveu què pot veure el Mac des d'on és

Executeu l'enumeració al Mac, no al vostre portàtil, perquè el Mac és la màquina que necessita el dispositiu. xcrun devicectl list devices imprimeix els dispositius que Xcode pot assolir, i system_profiler SPUSBDataType mostra què hi ha connectat físicament. Un telèfon que surt a la segona llista però no a la primera està connectat i no aparellat, cosa que és un problema de confiança i no de xarxa.

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

Si el dispositiu és en una altra subxarxa, confirmeu que el Mac pot arribar a l'adreça que publica el telèfon, i recordeu que les adreces IPv6 d'enllaç local estan limitades a un enllaç i no són encaminables a través d'un túnel. Per això una VPN tota sola poques vegades fa aparèixer un telèfon remot: l'adreça que anuncia el dispositiu només té sentit al seu propi segment.

La nota tècnica TN3158 d'Apple afirma que, a partir de la versió 15, Xcode parla amb un dispositiu connectat per cable a través d'una interfície de xarxa construïda sobre IPv6 d'enllaç local, així que el filtratge local pot interferir fins i tot amb un telèfon connectat físicament. Escaleu aquest cas a qui sigui titular de la política de filtratge en lloc de desactivar-la vosaltres mateixos.

Proveu-ho amb una compilació, no amb una icona de dispositiu

Una entrada de dispositiu en una llista, un indicador verd a la barra d'eines o un diàleg d'aparellament correcte són observacions intermèdies. El flux de treball queda provat quan Xcode instal·la una compilació permesa i el depurador s'adjunta a un procés que s'executa al dispositiu.

Executeu la seqüència completa des del Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instal·la sense l'IDE, cosa que separa un problema de la interfície de Xcode d'un problema del camí cap al dispositiu. Després inicieu l'aplicació i adjunteu-hi una consola. Si la instal·lació per línia d'ordres funciona i l'IDE no, la fallada restant és a l'esquema o a la configuració de signatura, no a la xarxa.

Manteniu el muntatge estret: un desenvolupador autoritzat, un Mac registrat, un dispositiu i un accés que s'acaba quan s'acaba la sessió. Revogueu les credencials quan el muntatge s'aturi. Si el telèfon simplement es pot quedar al costat del Mac, trieu això, perquè el camí compatible més simple és el que deixa menys capes per depurar.