Non si può semplicemente collegare un iPhone a un Mac remoto per Xcode

L'ipotesi abituale è che una sessione di desktop remoto sposti l'intero ambiente di sviluppo sul vostro portatile. Sposta lo schermo, la tastiera e il mouse, e nient'altro. L'iPhone deve raggiungere il Mac che esegue Xcode, e quella è una connessione separata con i propri requisiti di fiducia, trasporto e autorizzazioni. Tutto ciò che segue deriva da questa separazione, ed è lì che la maggior parte delle configurazioni fallite perde un pomeriggio.

Il mito: il controllo remoto sposta anche il dispositivo

Il software di desktop remoto inoltra un display e un flusso di input, e su una buona connessione sembra che il Mac sia seduto davanti a voi. Ciò che non inoltra è l'USB, e non colloca nemmeno il telefono sulla rete del Mac. La sessione termina sul desktop del Mac, dove Xcode deve poi trovare un dispositivo secondo le proprie regole. Supporre che il telefono viaggi con i pixel è l'errore più comune in questa disposizione.

Le due connessioni sono indipendenti, e una può essere perfetta mentre l'altra non esiste affatto. Riparare la sessione desktop non vi dice nulla sul percorso verso il dispositivo.

Decidete dove si trova fisicamente il telefono prima di configurare qualcosa

Se il telefono resta accanto al Mac, fate lì la solita configurazione locale: fidatevi del computer, attivate la modalità sviluppatore sul dispositivo e confermate che Xcode compili e si avvii su di esso mentre siete seduti davanti alla macchina. Il desktop remoto controlla allora un flusso di lavoro che già funziona. È la disposizione più economica e quella da preferire ogni volta che l'hardware lo consente.

Se il telefono viaggia con voi e il Mac resta in ufficio, il Mac ha bisogno di un percorso supportato verso quel dispositivo. Una VPN fornisce una rotta di rete tra i due estremi e non fornisce nient'altro: accoppiamento, modalità sviluppatore, identità di firma e registrazione del dispositivo restano requisiti separati. Trattate il tunnel come uno strato in una pila, non come la connessione stessa.

Annotate in quale delle due disposizioni vi trovate. Ogni verifica successiva dipende da questo, e mescolarle produce correzioni che non possono funzionare.

Trattate scoperta e trasporto come due problemi diversi

Xcode trova i dispositivi wireless accoppiati tramite Bonjour sulla rete locale, e può anche raggiungere un dispositivo a un indirizzo noto con Connect via IP Address. Sono due meccanismi con due diverse modalità di guasto. Un dispositivo che non compare mai nell'elenco e uno che compare ma rifiuta di collegarsi non sono lo stesso sintomo, anche se entrambi si leggono come un telefono mancante.

Esaminate l'annuncio prima di cambiare qualcosa: dns-sd -B _apple-mobdev2._tcp elenca il servizio che un telefono accoppiato pubblica sul collegamento locale. Se non compare nulla, la scoperta è lo strato rotto e una connessione basata sull'indirizzo è l'unica via rimasta. Se il servizio compare ma Xcode continua a non potersi collegare, la scoperta funziona e ciò che fallisce è il trasporto o la relazione di fiducia.

La guida Apple sui dispositivi wireless copre sia il requisito della stessa rete sia il flusso di lavoro con l'indirizzo, quindi leggetela rispetto alle versioni installate invece di seguire un percorso di menu ricordato da una versione precedente. Le etichette dei menu si spostano tra le versioni di Xcode anche quando il meccanismo sottostante non cambia.

Controllate cosa il Mac vede da dove si trova

Eseguite l'enumerazione sul Mac, non sul vostro portatile, perché il Mac è la macchina che ha bisogno del dispositivo. xcrun devicectl list devices stampa i dispositivi che Xcode può raggiungere, e system_profiler SPUSBDataType mostra cosa è collegato fisicamente. Un telefono che compare nel secondo elenco ma non nel primo è collegato e non accoppiato, il che è un problema di fiducia e non di rete.

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

Se il dispositivo si trova su un'altra sottorete, confermate che il Mac possa raggiungere l'indirizzo pubblicato dal telefono, e ricordate che gli indirizzi IPv6 locali al collegamento sono limitati a un collegamento e non sono instradabili attraverso un tunnel. Per questo una VPN da sola raramente fa comparire un telefono remoto: l'indirizzo annunciato dal dispositivo ha senso solo sul suo segmento.

La nota tecnica TN3158 di Apple afferma che, dalla versione 15 in poi, Xcode parla a un dispositivo via cavo attraverso un'interfaccia di rete costruita su IPv6 locale al collegamento, quindi il filtraggio locale può interferire anche con un telefono fisicamente collegato. Scalate quel caso a chi detiene la politica di filtraggio invece di disattivarla voi stessi.

Provatelo con una compilazione, non con un'icona di dispositivo

Una voce di dispositivo in un elenco, un indicatore verde nella barra degli strumenti o una richiesta di accoppiamento riuscita sono osservazioni intermedie. Il flusso di lavoro è provato quando Xcode installa una compilazione consentita e il debugger si aggancia a un processo in esecuzione sul dispositivo.

Eseguite l'intera sequenza dal Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installa senza l'IDE, il che separa un problema dell'interfaccia di Xcode da un problema del percorso verso il dispositivo. Poi avviate l'applicazione e collegatevi una console. Se l'installazione da riga di comando funziona e l'IDE no, il guasto rimanente è nello schema o nella configurazione di firma, non nella rete.

Tenete stretta la disposizione: uno sviluppatore autorizzato, un Mac registrato, un dispositivo e un accesso che finisce quando finisce la sessione. Revocate le credenziali quando la disposizione cessa. Se il telefono può semplicemente restare accanto al Mac, scegliete quello, perché il percorso supportato più semplice è quello che lascia meno strati da fare il debug.