No basta con conectar un iPhone a un Mac remoto para Xcode

La suposición habitual es que una sesión de escritorio remoto traslada todo el entorno de desarrollo a su portátil. Traslada la pantalla, el teclado y el ratón, y nada más. El iPhone tiene que llegar al Mac que ejecuta Xcode, y esa es una conexión aparte con sus propios requisitos de confianza, transporte y permisos. Todo lo que sigue se deriva de esa separación, y es ahí donde la mayoría de las configuraciones fallidas pierden una tarde.

El mito: el control remoto también mueve el dispositivo

El software de escritorio remoto reenvía una pantalla y un flujo de entrada, y con una buena conexión parece que el Mac estuviera sentado delante de usted. Lo que no reenvía es el USB, y tampoco coloca el teléfono en la red del Mac. La sesión termina en el escritorio del Mac, donde Xcode tiene que encontrar un dispositivo según sus propias reglas. Suponer que el teléfono viaja con los píxeles es el error más común en esta disposición.

Las dos conexiones son independientes, y una puede ser perfecta mientras la otra no existe en absoluto. Reparar la sesión de escritorio no le dice nada sobre la ruta hasta el dispositivo.

Decida dónde está físicamente el teléfono antes de configurar nada

Si el teléfono se queda junto al Mac, haga allí la configuración local habitual: confíe en el ordenador, active el modo de desarrollador en el dispositivo y confirme que Xcode compila y se ejecuta en él mientras está sentado delante de la máquina. Entonces el escritorio remoto controla un flujo de trabajo que ya funciona. Esa es la disposición más barata y la que conviene preferir siempre que el hardware lo permita.

Si el teléfono viaja con usted y el Mac se queda en la oficina, el Mac necesita una ruta compatible hasta ese dispositivo. Una VPN proporciona una ruta de red entre los dos extremos y no proporciona nada más: el emparejamiento, el modo de desarrollador, la identidad de firma y el registro del dispositivo siguen siendo requisitos aparte. Trate el túnel como una capa más de una pila, no como la conexión en sí.

Anote en cuál de las dos disposiciones se encuentra. Cada comprobación posterior depende de ello, y mezclarlas produce arreglos que no pueden funcionar.

Trate el descubrimiento y el transporte como dos problemas distintos

Xcode encuentra los dispositivos inalámbricos emparejados mediante Bonjour en la red local, y también puede llegar a un dispositivo en una dirección conocida con Connect via IP Address. Son dos mecanismos con dos modos de fallo diferentes. Un dispositivo que nunca aparece en la lista y otro que aparece pero se niega a conectarse no son el mismo síntoma, aunque ambos se lean como un teléfono ausente.

Explore el anuncio antes de cambiar nada: dns-sd -B _apple-mobdev2._tcp enumera el servicio que publica un teléfono emparejado en el enlace local. Si no aparece nada, el descubrimiento es la capa rota y una conexión basada en dirección es la única ruta que queda. Si el servicio aparece pero Xcode sigue sin poder conectarse, el descubrimiento funciona y lo que falla es el transporte o la relación de confianza.

La ayuda de Apple sobre dispositivos inalámbricos cubre tanto el requisito de la misma red como el flujo de trabajo con dirección, así que léala frente a las versiones que tiene instaladas en lugar de seguir una ruta de menú recordada de una versión anterior. Las etiquetas de los menús se mueven entre versiones de Xcode aunque el mecanismo subyacente no cambie.

Compruebe qué puede ver el Mac desde donde está

Ejecute la enumeración en el Mac, no en su portátil, porque el Mac es la máquina que necesita el dispositivo. xcrun devicectl list devices imprime los dispositivos que Xcode puede alcanzar, y system_profiler SPUSBDataType muestra qué está conectado físicamente. Un teléfono que aparece en la segunda lista pero no en la primera está conectado y no emparejado, lo que es un problema de confianza y no de red.

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

Si el dispositivo está en otra subred, confirme que el Mac puede alcanzar la dirección que publica el teléfono, y recuerde que las direcciones IPv6 de enlace local están limitadas a un enlace y no son enrutables a través de un túnel. Por eso una VPN por sí sola rara vez hace aparecer un teléfono remoto: la dirección que anuncia el dispositivo solo tiene sentido en su propio segmento.

La nota técnica TN3158 de Apple afirma que, a partir de la versión 15, Xcode habla con un dispositivo conectado por cable a través de una interfaz de red construida sobre IPv6 de enlace local, así que el filtrado local puede interferir incluso con un teléfono conectado físicamente. Escale ese caso a quien sea responsable de la política de filtrado en lugar de desactivarla usted mismo.

Demuéstrelo con una compilación, no con un icono de dispositivo

Una entrada de dispositivo en una lista, un indicador verde en la barra de herramientas o un diálogo de emparejamiento correcto son observaciones intermedias. El flujo de trabajo queda demostrado cuando Xcode instala una compilación permitida y el depurador se adjunta a un proceso que se ejecuta en el dispositivo.

Ejecute la secuencia completa desde el Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instala sin el IDE, lo que separa un problema de la interfaz de Xcode de un problema de la ruta al dispositivo. Después inicie la aplicación y adjunte una consola. Si la instalación por línea de órdenes funciona y el IDE no, el fallo restante está en el esquema o en la configuración de firma, no en la red.

Mantenga la disposición estrecha: un desarrollador autorizado, un Mac registrado, un dispositivo y un acceso que termina cuando termina la sesión. Revogue las credenciales cuando la disposición cese. Si el teléfono puede simplemente quedarse junto al Mac, elija eso, porque la ruta compatible más simple es la que deja menos capas por depurar.