Non basta conectar un iPhone a un Mac remoto para Xcode

A suposición habitual é que unha sesión de escritorio remoto traslada todo o contorno de desenvolvemento ao seu portátil. Traslada a pantalla, o teclado e o rato, e nada máis. O iPhone ten que chegar ao Mac que executa Xcode, e esa é unha conexión á parte cos seus propios requisitos de confianza, transporte e permisos. Todo o que segue derívase desa separación, e é aí onde a maioría das configuracións fallidas perden unha tarde.

O mito: o control remoto tamén move o dispositivo

O software de escritorio remoto reenvía unha pantalla e un fluxo de entrada, e cunha boa conexión parece que o Mac está sentado diante de vostede. O que non reenvía é o USB, e tampouco coloca o teléfono na rede do Mac. A sesión remata no escritorio do Mac, onde Xcode ten que atopar un dispositivo segundo as súas propias regras. Supoñer que o teléfono viaxa cos píxeles é o erro máis común nesta disposición.

As dúas conexións son independentes, e unha pode ser perfecta mentres a outra non existe en absoluto. Reparar a sesión de escritorio non lle di nada sobre a ruta ata o dispositivo.

Decidan onde está fisicamente o teléfono antes de configurar nada

Se o teléfono queda xunto ao Mac, fagan alí a configuración local habitual: confíen no ordenador, activen o modo de desenvolvedor no dispositivo e confirmen que Xcode compila e se executa nel mentres están sentados diante da máquina. Entón o escritorio remoto controla un fluxo de traballo que xa funciona. Esa é a disposición máis barata e a que convén preferir sempre que o hardware o permita.

Se o teléfono viaxa con vostede e o Mac queda na oficina, o Mac necesita unha ruta compatible ata ese dispositivo. Unha VPN fornece unha ruta de rede entre os dous extremos e non fornece nada máis: o emparellamento, o modo de desenvolvedor, a identidade de sinatura e o rexistro do dispositivo seguen sendo requisitos á parte. Traten o túnel como unha capa máis dunha pila, non como a conexión en si.

Anoten en cal das dúas disposicións se atopan. Cada comprobación posterior depende diso, e mesturalas produce arranxos que non poden funcionar.

Traten o descubrimento e o transporte como dous problemas distintos

Xcode atopa os dispositivos sen fíos emparellados mediante Bonjour na rede local, e tamén pode chegar a un dispositivo nun enderezo coñecido con Connect via IP Address. Son dous mecanismos con dous modos de fallo diferentes. Un dispositivo que nunca aparece na lista e outro que aparece pero se nega a conectarse non son o mesmo síntoma, aínda que ambos se len como un teléfono ausente.

Exploren o anuncio antes de cambiar nada: dns-sd -B _apple-mobdev2._tcp enumera o servizo que publica un teléfono emparellado na ligazón local. Se non aparece nada, o descubrimento é a capa rota e unha conexión baseada en enderezo é a única ruta que queda. Se o servizo aparece pero Xcode segue sen poder conectarse, o descubrimento funciona e o que falla é o transporte ou a relación de confianza.

A axuda de Apple sobre dispositivos sen fíos cobre tanto o requisito da mesma rede como o fluxo de traballo con enderezo, así que léxana fronte ás versións que teñen instaladas en lugar de seguir unha ruta de menú recordada dunha versión anterior. As etiquetas dos menús móvense entre versións de Xcode aínda que o mecanismo subxacente non cambie.

Comproben que pode ver o Mac desde onde está

Executen a enumeración no Mac, non no seu portátil, porque o Mac é a máquina que necesita o dispositivo. xcrun devicectl list devices imprime os dispositivos que Xcode pode alcanzar, e system_profiler SPUSBDataType mostra que está conectado fisicamente. Un teléfono que aparece na segunda lista pero non na primeira está conectado e non emparellado, o que é un problema de confianza e non de rede.

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

Se o dispositivo está noutra subrede, confirmen que o Mac pode alcanzar o enderezo que publica o teléfono, e lembren que os enderezos IPv6 de ligazón local están limitados a unha ligazón e non son encamiñables a través dun túnel. Por iso unha VPN por si soa raramente fai aparecer un teléfono remoto: o enderezo que anuncia o dispositivo só ten sentido no seu propio segmento.

A nota técnica TN3158 de Apple afirma que, a partir da versión 15, Xcode fala cun dispositivo conectado por cable a través dunha interface de rede construída sobre IPv6 de ligazón local, así que o filtrado local pode interferir mesmo cun teléfono conectado fisicamente. Escalen ese caso a quen sexa responsable da política de filtrado en lugar de desactivala vostedes mesmos.

Demóstrenno cunha compilación, non cunha icona de dispositivo

Unha entrada de dispositivo nunha lista, un indicador verde na barra de ferramentas ou un diálogo de emparellamento correcto son observacións intermedias. O fluxo de traballo queda demostrado cando Xcode instala unha compilación permitida e o depurador se adjunta a un proceso que se executa no dispositivo.

Executen a secuencia completa desde o Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instala sen o IDE, o que separa un problema da interface de Xcode dun problema da ruta ao dispositivo. Despois inicien a aplicación e adjunten unha consola. Se a instalación por liña de ordes funciona e o IDE non, o fallo restante está no esquema ou na configuración de sinatura, non na rede.

Manteñan a disposición estreita: un desenvolvedor autorizado, un Mac rexistrado, un dispositivo e un acceso que remata cando remata a sesión. Revoguen as credenciais cando a disposición cese. Se o teléfono pode simplemente quedar xunto ao Mac, elixan iso, porque a ruta compatible máis simple é a que deixa menos capas por depurar.