Du kan inte bara koppla in en iPhone i en extern Mac för Xcode

Det vanliga antagandet är att en fjärrskrivbordssession flyttar hela utvecklingsmiljön till din bärbara dator. Den flyttar skärmen, tangentbordet och musen, och ingenting annat. iPhonen måste nå Macen som kör Xcode, och det är en separat anslutning med egna krav på förtroende, transport och behörigheter. Allt nedan följer av den uppdelningen, och det är där de flesta misslyckade uppsättningarna förlorar en eftermiddag.

Myten: fjärrstyrning flyttar också enheten

Programvara för fjärrskrivbord vidarebefordrar en skärm och en indataström, och på en bra anslutning känns det som om Macen sitter framför dig. Det den inte vidarebefordrar är USB, och den placerar inte heller telefonen i Macens nätverk. Sessionen slutar på Macens skrivbord, där Xcode sedan måste hitta en enhet enligt sina egna regler. Att anta att telefonen färdas med pixlarna är det vanligaste misstaget i den här uppsättningen.

De två anslutningarna är oberoende, och en kan vara perfekt medan den andra inte finns alls. Att reparera skrivbordssessionen säger dig ingenting om vägen till enheten.

Bestäm var telefonen fysiskt befinner sig innan du konfigurerar något

Om telefonen ligger kvar bredvid Macen gör du den vanliga lokala uppsättningen där: lita på datorn, slå på utvecklarläget på enheten och bekräfta att Xcode bygger och kör till den medan du sitter framför maskinen. Fjärrskrivbordet styr sedan ett arbetsflöde som redan fungerar. Det är den billigaste uppsättningen och den du bör föredra när hårdvaran tillåter.

Om telefonen reser med dig och Macen står kvar på kontoret behöver Macen en väg som stöds till den enheten. Ett VPN ger en nätverksrutt mellan de två ändarna och ingenting annat: parkoppling, utvecklarläge, signeringsidentitet och enhetsregistrering är alla separata krav. Behandla tunneln som ett lager i en stack, inte som själva anslutningen.

Skriv ner vilken av de två uppsättningarna du är i. Varje senare kontroll beror på det, och att blanda dem ger åtgärder som inte kan fungera.

Behandla upptäckt och transport som två olika problem

Xcode hittar parkopplade trådlösa enheter via Bonjour på det lokala nätverket, och det kan också nå en enhet på en känd adress via Connect via IP Address. Det är två mekanismer med två olika felmoder. En enhet som aldrig dyker upp i listan och en enhet som dyker upp men vägrar ansluta är inte samma symptom, även om båda läses som en saknad telefon.

Sök efter annonsen innan du ändrar något: dns-sd -B _apple-mobdev2._tcp listar den tjänst som en parkopplad telefon publicerar på den lokala länken. Om ingenting dyker upp är upptäckten det trasiga lagret, och en adressbaserad anslutning är den enda vägen som återstår. Om tjänsten dyker upp men Xcode fortfarande inte kan ansluta fungerar upptäckten, och det är transporten eller förtroendeförhållandet som brister.

Apples hjälp för trådlösa enheter täcker både kravet på samma nätverk och adressarbetsflödet, så läs den mot de installerade versionerna i stället för att följa en menysökväg som du minns från en äldre utgåva. Menyetiketter flyttar sig mellan Xcode-utgåvor även när mekanismen under dem inte ändras.

Kontrollera vad Macen kan se från sin plats

Kör uppräkningen på Macen och inte på den bärbara datorn, eftersom Macen är maskinen som behöver enheten. xcrun devicectl list devices skriver ut de enheter som Xcode kan nå, och system_profiler SPUSBDataType visar vad som är fysiskt anslutet. En telefon som finns i den andra listan men inte i den första är ansluten och inte parkopplad, vilket är ett förtroendeproblem och inte ett nätverksproblem.

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

Om enheten sitter på ett annat subnät, bekräfta att Macen kan nå adressen som telefonen publicerar, och kom ihåg att link-local IPv6-adresser är begränsade till en länk och inte routas genom en tunnel. Därför gör ett VPN ensamt sällan en extern telefon synlig: adressen som enheten annonserar är bara meningsfull på sitt eget segment.

Apples tekniska not TN3158 anger att Xcode från version 15 och framåt talar med en kabelansluten enhet över ett nätverksgränssnitt byggt på link-local IPv6, så lokal filtrering kan störa även en fysiskt inkopplad telefon. Eskalera det fallet till den som äger filtreringspolicyn i stället för att stänga av den själv.

Bevisa det med en byggnad, inte med en enhetsikon

En enhetspost i en lista, en grön indikator i verktygsfältet eller en lyckad parkopplingsförfrågan är mellanobservationer. Arbetsflödet är bevisat när Xcode installerar en tillåten byggnad och felsökaren ansluter till en process som körs på enheten.

Kör hela sekvensen från Macen. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installerar utan IDE, vilket skiljer ett problem med Xcode-gränssnittet från ett problem med vägen till enheten. Starta sedan appen och anslut en konsol till den. Om installationen från kommandoraden fungerar och IDE inte gör det, sitter det återstående felet i schemat eller i signeringskonfigurationen och inte i nätverket.

Håll uppsättningen snäv: en auktoriserad utvecklare, en registrerad Mac, en enhet och åtkomst som slutar när sessionen slutar. Återkalla uppgifterna när uppsättningen upphör. Om telefonen bara kan ligga kvar bredvid Macen, välj det, eftersom den enklaste vägen som stöds har minst lager kvar att felsöka.