Du kan ikkje berre plugge ein iPhone inn i ein ekstern Mac for Xcode

Den vanlege føresetnaden er at ein ekstern skrivebordsøkt flyttar heile utviklingsoppsettet over på den berbare datamaskina di. Ho flyttar skjermen, tastaturet og musa, og ingenting anna. iPhonen må nå Macen som køyrer Xcode, og det er ei eiga tilkopling med sine eigne krav til tillit, transport og løyve. Alt nedanfor følgjer av denne delinga, og det er her dei fleste mislukka oppsetta mistar ein ettermiddag.

Myten: fjernstyring flyttar eininga òg

Programvare for eksternt skrivebord sender vidare ein skjerm og ein inndatastraum, og på ei god tilkopling kjennest det som om Macen sit framom deg. Det han ikkje sender vidare, er USB, og han set heller ikkje telefonen på nettet til Macen. Økta sluttar på skrivebordet til Macen, der Xcode så må finne ei eining etter sine eigne reglar. Å tru at telefonen reiser med pikslane er den vanlegaste feilen i dette oppsettet.

Dei to tilkoplingane er uavhengige, og éin kan vere perfekt medan den andre ikkje finst i det heile. Å reparere skrivebordsøkta seier deg ingenting om vegen til eininga.

Avgjer kvar telefonen fysisk er før du konfigurerer noko

Viss telefonen blir liggande ved sida av Macen, gjer du det vanlege lokale oppsettet der: stol på datamaskina, slå på utviklarmodus på eininga, og stadfest at Xcode byggjer og køyrer til henne medan du sit framom maskina. Deretter styrer det eksterne skrivebordet ein arbeidsflyt som alt verkar. Det er det billegaste oppsettet og det du bør føretrekkje når maskinvara tillèt det.

Viss telefonen reiser med deg og Macen blir ståande på kontoret, treng Macen ein støtta veg til den eininga. Ein VPN gjev ei nettrute mellom dei to endane og gjev ingenting anna: pardanning, utviklarmodus, signeringsidentitet og einingregistrering er alle separate krav. Handsam tunnelen som eitt lag i ein stabel, ikkje som sjølve tilkoplinga.

Skriv ned kva av dei to oppsetta du er i. Kvar seinare kontroll heng av det, og å blande dei gjev rettingar som ikkje kan verke.

Handsam oppdaging og transport som to ulike problem

Xcode finn pardanna trådlause einingar via Bonjour på det lokale nettet, og han kan òg nå ei eining på ei kjend adresse via Connect via IP Address. Det er to mekanismar med to ulike feilmodusar. Ei eining som aldri dukkar opp i lista, og ei eining som dukkar opp men nektar å kople seg til, er ikkje same symptomet, sjølv om begge blir lesne som ein manglande telefon.

Søk etter annonseringa før du endrar noko: dns-sd -B _apple-mobdev2._tcp listar opp tenesta ein pardanna telefon publiserer på den lokale lenkja. Viss ingenting dukkar opp, er oppdaginga det øydelagde laget, og ei adressebasert tilkopling er den einaste vegen som står att. Viss tenesta dukkar opp men Xcode framleis ikkje kan kople seg til, verkar oppdaginga, og det er transporten eller tillitsforholdet som sviktar.

Apple-hjelpa for trådlause einingar dekkjer både kravet om same nett og adressearbeidsflyten, så les ho mot dei installerte versjonane i staden for å følgje ein menysti du hugsar frå ein eldre utgiving. Menyetikettar flyttar seg mellom Xcode-utgivingar sjølv når mekanismen under ikkje endrar seg.

Kontroller kva Macen kan sjå frå der han står

Køyr oppramsinga på Macen og ikkje på den berbare datamaskina, fordi Macen er maskina som treng eininga. xcrun devicectl list devices skriv ut einingane Xcode kan nå, og system_profiler SPUSBDataType viser kva som er fysisk tilkopla. Ein telefon som viser seg i den andre lista men ikkje i den første, er tilkopla og ikkje pardanna, noko som er eit tillitsproblem og ikkje eit nettproblem.

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

Viss eininga sit på eit anna subnett, stadfest at Macen kan nå adressa telefonen publiserer, og hugs at link-local IPv6-adresser er avgrensa til éi lenkje og ikkje blir ruta gjennom ein tunnel. Difor gjer ein VPN åleine sjeldan ein ekstern telefon synleg: adressa eininga annonserer, er berre meiningsfull på sin eigen segment.

Det tekniske notatet TN3158 frå Apple seier at Xcode frå versjon 15 og utover snakkar med ei kabeltilkopla eining over eit nettverksgrensesnitt bygd på link-local IPv6, så lokal filtrering kan forstyrre sjølv ein fysisk tilkopla telefon. Eskaler det tilfellet til den som eig filtreringspolicyen i staden for å slå han av sjølv.

Prov det med eit bygg, ikkje med eit einingikon

Ei einingsoppføring i ei liste, ein grøn indikator i verktøylinja eller ei vellukka pardanningsførespurnad er mellomobservasjonar. Arbeidsflyten er prova når Xcode installerer eit tillaten bygg og feilsøkjaren koplar seg til ein prosess som køyrer på eininga.

Køyr heile sekvensen frå Macen. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installerer utan IDE, noko som skil eit Xcode-grensesnittproblem frå eit einingvegproblem. Start deretter appen og kople ein konsoll til han. Viss installasjonen frå kommandolinja verkar og IDE ikkje gjer det, er den gjenverande feilen i skjemaet eller i signeringskonfigurasjonen og ikkje i nettet.

Hald oppsettet smalt: éin autorisert utviklar, éin registrert Mac, éi eining og tilgang som sluttar når økta sluttar. Trekk attende legitimasjonen når oppsettet sluttar. Viss telefonen berre kan bli liggande ved sida av Macen, vel det i staden, fordi den enklaste støtta vegen er den med færrast lag att å feilsøkje.