Não basta ligar um iPhone a um Mac remoto para o Xcode

A suposição habitual é que uma sessão de ambiente de trabalho remoto move toda a configuração de desenvolvimento para o seu portátil. Move o ecrã, o teclado e o rato, e mais nada. O iPhone tem de chegar ao Mac que executa o Xcode, e isso é uma ligação separada com os seus próprios requisitos de confiança, transporte e permissões. Tudo o que se segue decorre dessa separação, e é aí que a maioria das configurações falhadas perde uma tarde.

O mito: o controlo remoto também move o dispositivo

O software de ambiente de trabalho remoto reencaminha um ecrã e um fluxo de entrada e, numa boa ligação, parece que o Mac está sentado à sua frente. O que não reencaminha é o USB, e também não coloca o telefone na rede do Mac. A sessão termina no ambiente de trabalho do Mac, onde o Xcode tem então de encontrar um dispositivo pelas suas próprias regras. Assumir que o telefone viaja com os píxeis é o erro mais comum nesta configuração.

As duas ligações são independentes, e uma pode estar perfeita enquanto a outra não existe de todo. Reparar a sessão do ambiente de trabalho não lhe diz nada sobre o caminho até ao dispositivo.

Decida onde está fisicamente o telefone antes de configurar o que quer que seja

Se o telefone fica ao lado do Mac, faça aí a configuração local habitual: confie no computador, ative o modo de programador no dispositivo e confirme que o Xcode compila e executa nele enquanto está sentado à frente da máquina. O ambiente de trabalho remoto passa então a controlar um fluxo de trabalho que já funciona. É a configuração mais barata e a que deve preferir sempre que o equipamento o permitir.

Se o telefone viaja consigo e o Mac fica no escritório, o Mac precisa de um caminho suportado até esse dispositivo. Uma VPN fornece uma rota de rede entre as duas pontas e não fornece mais nada: emparelhamento, modo de programador, identidade de assinatura e registo do dispositivo continuam a ser requisitos separados. Trate o túnel como uma camada numa pilha e não como a própria ligação.

Anote em qual dessas duas configurações está. Cada verificação posterior depende disso, e misturá-las produz correções que não podem funcionar.

Trate a descoberta e o transporte como dois problemas diferentes

O Xcode encontra dispositivos sem fios emparelhados através do Bonjour na rede local, e também pode chegar a um dispositivo num endereço conhecido através de Connect via IP Address. São dois mecanismos com dois modos de falha diferentes. Um dispositivo que nunca aparece na lista e um dispositivo que aparece mas recusa ligar-se não são o mesmo sintoma, embora ambos se leiam como um telefone em falta.

Procure o anúncio antes de mudar seja o que for: dns-sd -B _apple-mobdev2._tcp lista o serviço que um telefone emparelhado publica na ligação local. Se não aparecer nada, a descoberta é a camada avariada e uma ligação baseada em endereço é a única via que resta. Se o serviço aparecer mas o Xcode continuar sem conseguir ligar-se, a descoberta funciona e o que falha é o transporte ou a relação de confiança.

A ajuda da Apple sobre dispositivos sem fios cobre tanto o requisito de a mesma rede como o fluxo de trabalho por endereço, por isso leia-a em função das versões instaladas em vez de seguir um caminho de menu lembrado de uma versão anterior. As etiquetas de menu mudam entre versões do Xcode mesmo quando o mecanismo por baixo não muda.

Verifique o que o Mac consegue ver a partir do lugar onde está

Execute a enumeração no Mac e não no seu portátil, porque o Mac é a máquina que precisa do dispositivo. xcrun devicectl list devices imprime os dispositivos que o Xcode consegue alcançar, e system_profiler SPUSBDataType mostra o que está fisicamente ligado. Um telefone que aparece na segunda lista mas não na primeira está ligado e não emparelhado, o que é um problema de confiança e não de rede.

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

Se o dispositivo estiver noutra sub-rede, confirme que o Mac consegue alcançar o endereço que o telefone publica, e lembre-se de que os endereços link-local IPv6 estão limitados a uma ligação e não são encaminhados através de um túnel. É por isso que uma VPN sozinha raramente faz aparecer um telefone remoto: o endereço que o dispositivo anuncia só tem significado no seu próprio segmento.

A nota técnica TN3158 da Apple indica que, a partir da versão 15, o Xcode comunica com um dispositivo por cabo através de uma interface de rede construída sobre link-local IPv6, pelo que a filtragem local pode interferir mesmo com um telefone ligado fisicamente. Escale esse caso para quem detém a política de filtragem em vez de a desativar por sua conta.

Prove-o com uma compilação, não com um ícone de dispositivo

Uma entrada de dispositivo numa lista, um indicador verde na barra de ferramentas ou um pedido de emparelhamento bem-sucedido são observações intermédias. O fluxo de trabalho fica provado quando o Xcode instala uma compilação permitida e o depurador se liga a um processo a correr no dispositivo.

Execute a sequência completa a partir do Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instala sem o IDE, o que separa um problema da interface do Xcode de um problema do caminho até ao dispositivo. Depois inicie a aplicação e ligue-lhe uma consola. Se a instalação pela linha de comandos funcionar e o IDE não, a falha restante está no esquema ou na configuração de assinatura e não na rede.

Mantenha a configuração estreita: um programador autorizado, um Mac registado, um dispositivo e um acesso que termina quando a sessão termina. Revogue as credenciais quando a configuração acabar. Se o telefone puder simplesmente ficar ao lado do Mac, escolha isso, porque o caminho suportado mais simples é o que tem menos camadas por depurar.