Nu poți doar conecta un iPhone la un Mac aflat la distanță pentru Xcode

Presupunerea obișnuită este că o sesiune de desktop la distanță mută întregul mediu de dezvoltare pe laptopul tău. Mută ecranul, tastatura și mouse-ul, și nimic altceva. iPhone-ul trebuie să ajungă la Mac-ul care rulează Xcode, iar aceasta este o conexiune separată, cu propriile cerințe de încredere, transport și permisiuni. Tot ce urmează decurge din această separare, și exact aici majoritatea configurărilor eșuate pierd o jumătate de zi.

Mitul: controlul de la distanță mută și dispozitivul

Software-ul de desktop la distanță transmite un ecran și un flux de intrare, iar pe o conexiune bună pare că Mac-ul stă în fața ta. Ce nu transmite este USB-ul și nici nu pune telefonul în rețeaua Mac-ului. Sesiunea se termină pe desktopul Mac-ului, unde Xcode trebuie apoi să găsească un dispozitiv după propriile reguli. A presupune că telefonul călătorește împreună cu pixelii este cea mai frecventă greșeală în această configurare.

Cele două conexiuni sunt independente, iar una poate fi perfectă în timp ce cealaltă nu există deloc. Repararea sesiunii de desktop nu îți spune nimic despre calea către dispozitiv.

Decide unde se află fizic telefonul înainte de a configura ceva

Dacă telefonul rămâne lângă Mac, fă acolo configurarea locală obișnuită: ai încredere în computer, activează modul dezvoltator pe dispozitiv și confirmă că Xcode compilează și rulează pe el în timp ce stai în fața mașinii. Desktopul la distanță controlează apoi un flux de lucru care funcționează deja. Aceasta este cea mai ieftină configurare și cea pe care ar trebui să o preferi ori de câte ori hardware-ul permite.

Dacă telefonul călătorește cu tine și Mac-ul rămâne în birou, Mac-ul are nevoie de o cale acceptată către acel dispozitiv. Un VPN oferă o rută de rețea între cele două capete și nimic altceva: împerecherea, modul dezvoltator, identitatea de semnare și înregistrarea dispozitivului rămân toate cerințe separate. Tratează tunelul ca un strat într-o stivă, nu ca însăși conexiunea.

Notează în care dintre cele două configurări te afli. Fiecare verificare ulterioară depinde de asta, iar amestecarea lor produce remedii care nu pot funcționa.

Tratează descoperirea și transportul ca două probleme diferite

Xcode găsește dispozitivele wireless împerecheate prin Bonjour în rețeaua locală și poate ajunge și la un dispozitiv de la o adresă cunoscută prin Connect via IP Address. Sunt două mecanisme cu două moduri diferite de eșec. Un dispozitiv care nu apare niciodată în listă și un dispozitiv care apare dar refuză să se atașeze nu sunt același simptom, chiar dacă ambele se citesc ca un telefon lipsă.

Caută anunțul înainte de a schimba ceva: dns-sd -B _apple-mobdev2._tcp listează serviciul pe care un telefon împerecheat îl publică pe legătura locală. Dacă nu apare nimic, descoperirea este stratul defect și o conexiune bazată pe adresă este singura cale rămasă. Dacă serviciul apare dar Xcode tot nu se poate atașa, descoperirea funcționează și ceea ce eșuează este transportul sau relația de încredere.

Ajutorul Apple pentru dispozitive wireless acoperă atât cerința aceleiași rețele, cât și fluxul de lucru cu adresă, așa că citește-l raportat la versiunile instalate, în loc să urmezi o cale de meniu ținută minte dintr-o versiune mai veche. Etichetele de meniu se mută între versiunile Xcode chiar și atunci când mecanismul de dedesubt nu se schimbă.

Verifică ce poate vedea Mac-ul din locul în care se află

Rulează enumerarea pe Mac, nu pe laptop, pentru că Mac-ul este mașina care are nevoie de dispozitiv. xcrun devicectl list devices afișează dispozitivele la care Xcode poate ajunge, iar system_profiler SPUSBDataType arată ce este conectat fizic. Un telefon care apare în a doua listă dar nu în prima este conectat și nu împerecheat, ceea ce este o problemă de încredere, nu de rețea.

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

Dacă dispozitivul se află într-o altă subrețea, confirmă că Mac-ul poate ajunge la adresa pe care o publică telefonul și ține minte că adresele link-local IPv6 sunt limitate la o singură legătură și nu sunt rutate printr-un tunel. De aceea un VPN singur face rar un telefon de la distanță vizibil: adresa pe care o anunță dispozitivul are sens doar în propriul segment.

Nota tehnică Apple TN3158 afirmă că, de la versiunea 15 încolo, Xcode comunică cu un dispozitiv pe cablu printr-o interfață de rețea construită pe link-local IPv6, așa că filtrarea locală poate interfera chiar și cu un telefon conectat fizic. Escaladează acel caz către cel care deține politica de filtrare, în loc să o dezactivezi singur.

Demonstrează cu o compilare, nu cu o pictogramă de dispozitiv

O intrare de dispozitiv într-o listă, un indicator verde în bara de instrumente sau o cerere de împerechere reușită sunt observații intermediare. Fluxul de lucru este dovedit când Xcode instalează o compilare permisă și depanatorul se atașează la un proces care rulează pe dispozitiv.

Rulează întreaga secvență de pe Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instalează fără IDE, ceea ce separă o problemă a interfeței Xcode de o problemă a căii către dispozitiv. Apoi lansează aplicația și atașează o consolă la ea. Dacă instalarea din linia de comandă funcționează și IDE-ul nu, defectul rămas este în schemă sau în configurația de semnare, nu în rețea.

Ține configurarea îngustă: un dezvoltator autorizat, un Mac înregistrat, un dispozitiv și un acces care se termină când se termină sesiunea. Revocă acreditările când configurarea încetează. Dacă telefonul poate pur și simplu să rămână lângă Mac, alege asta, pentru că cea mai simplă cale acceptată este cea cu cele mai puține straturi de depanat.