Du kan ikke bare plugge en iPhone inn i en ekstern Mac for Xcode

Den vanlige antakelsen er at en ekstern skrivebordsøkt flytter hele utviklingsoppsettet over på laptopen din. Den flytter skjermen, tastaturet og musen, og ingenting annet. iPhonen må nå Macen som kjører Xcode, og det er en egen forbindelse med sine egne krav til tillit, transport og tillatelser. Alt nedenfor følger av denne delingen, og det er her de fleste mislykkede oppsettene mister en ettermiddag.

Myten: fjernstyring flytter apparatet også

Programvare for eksternt skrivebord videresender en skjerm og en inndatastrøm, og på en god forbindelse føles det som om Macen sitter foran deg. Det den ikke videresender, er USB, og den plasserer heller ikke telefonen på Macens nettverk. Økten slutter på Macens skrivebord, der Xcode deretter må finne et apparat etter sine egne regler. Å anta at telefonen reiser med pikslene er den vanligste feilen i dette oppsettet.

De to forbindelsene er uavhengige, og én kan være perfekt mens den andre ikke finnes i det hele tatt. Å reparere skrivebordsøkten sier deg ingenting om apparatveien.

Bestem hvor telefonen fysisk befinner seg før du konfigurerer noe

Hvis telefonen blir liggende ved siden av Macen, gjør du det vanlige lokale oppsettet der: stol på datamaskinen, slå på utviklermodus på apparatet, og bekreft at Xcode bygger og kjører til det mens du sitter foran maskinen. Deretter styrer det eksterne skrivebordet en arbeidsflyt som allerede virker. Det er det billigste oppsettet og det du bør foretrekke når maskinvaren tillater det.

Hvis telefonen reiser med deg og Macen blir stående på kontoret, trenger Macen en støttet vei til det apparatet. En VPN gir en nettverksrute mellom de to endene og gir ingenting annet: pardanning, utviklermodus, signeringsidentitet og apparatregistrering er alle separate krav. Behandle tunnelen som ett lag i en stabel, ikke som selve forbindelsen.

Skriv ned hvilket av de to oppsettene du er i. Hver senere kontroll avhenger av det, og å blande dem gir rettelser som ikke kan virke.

Behandle oppdagelse og transport som to forskjellige problemer

Xcode finner pardannede trådløse apparater via Bonjour på det lokale nettverket, og det kan også nå et apparat på en kjent adresse via Connect via IP Address. Det er to mekanismer med to forskjellige feilmoduser. Et apparat som aldri dukker opp i listen, og et apparat som dukker opp men nekter å koble seg til, er ikke samme symptom, selv om begge leses som en manglende telefon.

Søk etter annonseringen før du endrer noe: dns-sd -B _apple-mobdev2._tcp lister opp tjenesten en pardannet telefon publiserer på den lokale lenken. Hvis ingenting dukker opp, er oppdagelsen det ødelagte laget, og en adressebasert forbindelse er den eneste veien som gjenstår. Hvis tjenesten dukker opp men Xcode fortsatt ikke kan koble seg til, virker oppdagelsen, og det er transporten eller tillitsforholdet som svikter.

Apples hjelp for trådløse apparater dekker både kravet om samme nettverk og adressearbeidsflyten, så les den mot de installerte versjonene i stedet for å følge en menysti du husker fra en eldre utgivelse. Menyetiketter flytter seg mellom Xcode-utgivelser selv når mekanismen under ikke endres.

Kontroller hva Macen kan se fra der den står

Kjør oppramsingen på Macen og ikke på laptopen, fordi Macen er maskinen som trenger apparatet. xcrun devicectl list devices skriver ut apparatene Xcode kan nå, og system_profiler SPUSBDataType viser hva som er fysisk tilkoblet. En telefon som vises i den andre listen men ikke i den første, er tilkoblet og ikke pardannet, noe som er et tillitsproblem og ikke et nettverksproblem.

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

Hvis apparatet sitter på et annet subnett, bekreft at Macen kan nå adressen telefonen publiserer, og husk at link-local IPv6-adresser er begrenset til én lenke og ikke rutes gjennom en tunnel. Derfor gjør en VPN alene sjelden en ekstern telefon synlig: adressen apparatet annonserer, er bare meningsfull på sitt eget segment.

Apples tekniske notat TN3158 oppgir at Xcode fra versjon 15 og utover snakker med et kablet apparat over et nettverksgrensesnitt bygget på link-local IPv6, så lokal filtrering kan forstyrre selv en fysisk tilkoblet telefon. Eskaler det tilfellet til den som eier filtreringspolicyen i stedet for å slå den av selv.

Bevis det med et bygg, ikke med et apparatikon

En apparatoppføring i en liste, en grønn indikator i verktøylinjen eller en vellykket pardanningsforespørsel er mellomobservasjoner. Arbeidsflyten er bevist når Xcode installerer et tillatt bygg og feilsøkeren kobler seg til en prosess som kjører på apparatet.

Kjør hele sekvensen fra Macen. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installerer uten IDE, noe som skiller et Xcode-grensesnittproblem fra et apparatveiproblem. Start deretter appen og koble en konsoll til den. Hvis installasjonen fra kommandolinjen virker og IDE ikke gjør det, er den gjenværende feilen i skjemaet eller i signeringskonfigurasjonen og ikke i nettverket.

Hold oppsettet smalt: én autorisert utvikler, én registrert Mac, ett apparat og tilgang som slutter når økten slutter. Tilbakekall legitimasjonen når oppsettet avsluttes. Hvis telefonen bare kan bli liggende ved siden av Macen, velg det i stedet, fordi den enkleste støttede veien er den med færrest lag igjen å feilsøke.