Du kan ikke bare slutte en iPhone til en fjern Mac for Xcode

Den sædvanlige antagelse er, at en fjerndesktop-session flytter hele udviklingsopsætningen over på din bærbare. Den flytter skærmen, tastaturet og musen, og intet andet. iPhonen skal nå den Mac, der kører Xcode, og det er en separat forbindelse med sine egne krav til tillid, transport og tilladelser. Alt nedenfor følger af denne opdeling, og det er her, de fleste mislykkede opsætninger mister en eftermiddag.

Myten: fjernstyring flytter også enheden

Fjerndesktop-software videresender en skærm og en inputstrøm, og på en god forbindelse føles det, som om Macen sidder foran dig. Det, den ikke videresender, er USB, og den anbringer heller ikke telefonen på Macens netværk. Sessionen slutter ved Macens skrivebord, hvor Xcode derefter skal finde en enhed efter sine egne regler. At antage, at telefonen rejser med pixels, er den mest almindelige fejl i denne opsætning.

De to forbindelser er uafhængige, og den ene kan være perfekt, mens den anden slet ikke findes. At reparere skrivebordssessionen fortæller dig intet om vejen til enheden.

Afgør, hvor telefonen fysisk er, før du konfigurerer noget

Hvis telefonen bliver liggende ved Macen, så lav den sædvanlige lokale opsætning der: stol på computeren, slå udviklertilstand til på enheden, og bekræft, at Xcode bygger og kører på den, mens du sidder foran maskinen. Så styrer fjerndesktop en arbejdsgang, der allerede virker. Det er den billigste opsætning og den, du bør foretrække, når hardwaren tillader det.

Hvis telefonen rejser med dig, og Macen bliver på kontoret, har Macen brug for en understøttet vej til den enhed. En VPN leverer en netværksrute mellem de to ender og leverer intet andet: parring, udviklertilstand, signeringsidentitet og enhedsregistrering er stadig separate krav. Behandl tunnelen som et lag i en stak snarere end som selve forbindelsen.

Skriv ned, hvilken af de to opsætninger du er i. Hver senere kontrol afhænger af det, og at blande dem giver rettelser, der ikke kan virke.

Behandl opdagelse og transport som to forskellige problemer

Xcode finder parrede trådløse enheder via Bonjour på det lokale netværk, og den kan også nå en enhed på en kendt adresse via Connect via IP Address. Det er to mekanismer med to forskellige fejlmåder. En enhed, der aldrig dukker op på listen, og en enhed, der dukker op, men nægter at koble sig på, er ikke det samme symptom, selv om begge læses som en manglende telefon.

Gennemse annoncen, før du ændrer noget: dns-sd -B _apple-mobdev2._tcp viser den tjeneste, som en parret telefon udgiver på det lokale link. Hvis der intet dukker op, er opdagelse det ødelagte lag, og en adressebaseret forbindelse er den eneste vej tilbage. Hvis tjenesten dukker op, men Xcode stadig ikke kan koble sig på, virker opdagelse, og det er transporten eller tillidsforholdet, der svigter.

Apples hjælp til trådløse enheder dækker både kravet om samme netværk og adressearbejdsgangen, så læs den op mod dine installerede versioner i stedet for at følge en menusteg, du husker fra en ældre udgivelse. Menupunkter flytter sig mellem Xcode-udgivelser, selv når mekanismen under dem ikke gør.

Kontroller, hvad Macen kan se fra sin plads

Kør optællingen på Macen, ikke på din bærbare, fordi Macen er den maskine, der har brug for enheden. xcrun devicectl list devices udskriver de enheder, som Xcode kan nå, og system_profiler SPUSBDataType viser, hvad der fysisk er tilsluttet. En telefon, der optræder på den anden liste men ikke den første, er tilsluttet og ikke parret, og det er et tillidsproblem snarere end et netværksproblem.

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

Hvis enheden ligger på et andet subnet, så bekræft, at Macen kan nå den adresse, som telefonen udgiver, og husk, at link-lokale IPv6-adresser er begrænset til ét link og ikke kan routes gennem en tunnel. Derfor gør en VPN alene sjældent en fjern telefon synlig: den adresse, enheden annoncerer, giver kun mening på dens eget segment.

Apples tekniske note TN3158 fastslår, at Xcode fra version 15 og frem taler med en kablet enhed over et netværksinterface bygget på link-lokal IPv6, så lokal filtrering kan forstyrre selv en telefon, der er fysisk tilsluttet. Eskalér det tilfælde til den, der ejer filtreringspolitikken, i stedet for selv at slå den fra.

Bevis det med et build, ikke med et enhedsikon

En enhedspost på en liste, en grøn indikator i værktøjslinjen eller en vellykket parringsanmodning er mellemliggende observationer. Arbejdsgangen er bevist, når Xcode installerer et tilladt build, og debuggeren knytter sig til en proces, der kører på enheden.

Kør hele sekvensen fra Macen. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installerer uden IDE, hvilket skiller et Xcode-grænsefladeproblem fra et problem med vejen til enheden. Start derefter appen, og knyt en konsol til den. Hvis installationen fra kommandolinjen virker, og IDE ikke gør, er den resterende fejl i skemaet eller signeringskonfigurationen snarere end i netværket.

Hold opsætningen snæver: én autoriseret udvikler, én registreret Mac, én enhed og adgang, der slutter, når sessionen slutter. Tilbagekald legitimationsoplysninger, når opsætningen stopper. Hvis telefonen bare kan blive liggende ved Macen, så vælg det, fordi den enkleste understøttede vej er den med færrest lag tilbage at fejlfinde.