Nie można po prostu podłączyć iPhone’a do zdalnego Maca na potrzeby Xcode

Zwykłe założenie jest takie, że sesja zdalnego pulpitu przenosi całe środowisko programistyczne na twojego laptopa. Przenosi ekran, klawiaturę i mysz, i nic więcej. iPhone musi dotrzeć do Maca, na którym działa Xcode, a to osobne połączenie z własnymi wymaganiami dotyczącymi zaufania, transportu i uprawnień. Wszystko poniżej wynika z tego podziału, i właśnie tutaj większość nieudanych konfiguracji traci pół dnia.

Mit: zdalne sterowanie przenosi też urządzenie

Oprogramowanie zdalnego pulpitu przekazuje obraz i strumień wejściowy, a przy dobrym połączeniu wydaje się, że Mac siedzi przed tobą. Nie przekazuje jednak USB i nie umieszcza telefonu w sieci Maca. Sesja kończy się na pulpicie Maca, gdzie Xcode musi następnie znaleźć urządzenie według własnych zasad. Założenie, że telefon podróżuje razem z pikselami, to najczęstszy błąd w tym układzie.

Oba połączenia są niezależne, i jedno może być idealne, podczas gdy drugie w ogóle nie istnieje. Naprawa sesji pulpitu nie mówi nic o ścieżce do urządzenia.

Zdecyduj, gdzie fizycznie znajduje się telefon, zanim cokolwiek skonfigurujesz

Jeśli telefon zostaje obok Maca, wykonaj tam zwykłą konfigurację lokalną: zaufaj komputerowi, włącz tryb programisty na urządzeniu i potwierdź, że Xcode buduje i uruchamia na nim, gdy siedzisz przed maszyną. Zdalny pulpit steruje wtedy przepływem pracy, który już działa. To najtańszy układ i ten, który należy wybierać, gdy sprzęt na to pozwala.

Jeśli telefon podróżuje z tobą, a Mac zostaje w biurze, Mac potrzebuje obsługiwanej ścieżki do tego urządzenia. VPN dostarcza trasę sieciową między dwoma końcami i nic więcej: parowanie, tryb programisty, tożsamość podpisywania i rejestracja urządzenia pozostają osobnymi wymaganiami. Traktuj tunel jako jedną warstwę w stosie, a nie jako samo połączenie.

Zapisz, w którym z tych dwóch układów jesteś. Każda późniejsza kontrola zależy od tego, a mieszanie ich daje poprawki, które nie mogą działać.

Traktuj wykrywanie i transport jako dwa różne problemy

Xcode znajduje sparowane urządzenia bezprzewodowe przez Bonjour w sieci lokalnej, a może też dotrzeć do urządzenia pod znanym adresem przez Connect via IP Address. To dwa mechanizmy o dwóch różnych trybach awarii. Urządzenie, które nigdy nie pojawia się na liście, i urządzenie, które się pojawia, ale odmawia połączenia, to nie ten sam objaw, choć oba czytają się jako brakujący telefon.

Zanim cokolwiek zmienisz, sprawdź rozgłoszenie: dns-sd -B _apple-mobdev2._tcp wylicza usługę, którą sparowany telefon publikuje w lokalnym łączu. Jeśli nic się nie pojawia, wykrywanie jest zepsutą warstwą i pozostaje tylko połączenie oparte na adresie. Jeśli usługa się pojawia, ale Xcode nadal nie może się połączyć, wykrywanie działa, a zawodzi transport lub relacja zaufania.

Pomoc Apple dotycząca urządzeń bezprzewodowych obejmuje zarówno wymóg tej samej sieci, jak i przepływ pracy z adresem, więc czytaj ją na tle zainstalowanych wersji, zamiast podążać ścieżką menu zapamiętaną ze starszego wydania. Etykiety menu przesuwają się między wydaniami Xcode, nawet gdy mechanizm pod nimi się nie zmienia.

Sprawdź, co Mac widzi ze swojego miejsca

Uruchom wyliczenie na Macu, a nie na laptopie, bo to Mac jest maszyną, która potrzebuje urządzenia. xcrun devicectl list devices wypisuje urządzenia, do których Xcode może dotrzeć, a system_profiler SPUSBDataType pokazuje, co jest fizycznie podłączone. Telefon, który pojawia się na drugiej liście, ale nie na pierwszej, jest podłączony i niesparowany, co jest problemem zaufania, a nie sieci.

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

Jeśli urządzenie znajduje się w innej podsieci, potwierdź, że Mac może dotrzeć do adresu publikowanego przez telefon, i pamiętaj, że adresy link-local IPv6 są ograniczone do jednego łącza i nie są rutowane przez tunel. Dlatego sam VPN rzadko sprawia, że zdalny telefon się pojawia: adres rozgłaszany przez urządzenie ma znaczenie tylko w jego własnym segmencie.

Nota techniczna Apple TN3158 stwierdza, że od wersji 15 Xcode rozmawia z urządzeniem po kablu przez interfejs sieciowy zbudowany na link-local IPv6, więc lokalne filtrowanie może przeszkadzać nawet fizycznie podłączonemu telefonowi. Eskaluj taki przypadek do właściciela polityki filtrowania, zamiast wyłączać ją samodzielnie.

Udowodnij to kompilacją, a nie ikoną urządzenia

Wpis urządzenia na liście, zielony wskaźnik na pasku narzędzi czy udane okno parowania to obserwacje pośrednie. Przepływ pracy jest udowodniony, gdy Xcode instaluje dozwoloną kompilację, a debugger podłącza się do procesu działającego na urządzeniu.

Uruchom całą sekwencję z Maca. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instaluje bez IDE, co oddziela problem z interfejsem Xcode od problemu ze ścieżką do urządzenia. Następnie uruchom aplikację i podłącz do niej konsolę. Jeśli instalacja z wiersza poleceń działa, a IDE nie, pozostały błąd tkwi w schemacie lub w konfiguracji podpisywania, a nie w sieci.

Utrzymuj układ wąski: jeden upoważniony programista, jeden zarejestrowany Mac, jedno urządzenie i dostęp, który kończy się wraz z sesją. Odwołaj dane uwierzytelniające, gdy układ się kończy. Jeśli telefon może po prostu zostać obok Maca, wybierz to, bo najprostsza obsługiwana ścieżka ma najmniej warstw do debugowania.