Je kunt een iPhone niet zomaar op een externe Mac aansluiten voor Xcode

De gebruikelijke aanname is dat een sessie op een extern bureaublad de hele ontwikkelomgeving naar je laptop verplaatst. Het verplaatst het scherm, het toetsenbord en de muis, en niets anders. De iPhone moet de Mac bereiken waarop Xcode draait, en dat is een aparte verbinding met eigen eisen aan vertrouwen, transport en rechten. Alles hieronder volgt uit die splitsing, en juist daar verliezen de meeste mislukte opstellingen een middag.

De mythe: bediening op afstand verplaatst ook het apparaat

Software voor een extern bureaublad stuurt een beeld en een invoerstroom door, en op een goede verbinding voelt het alsof de Mac voor je zit. Wat het niet doorstuurt, is USB, en het zet de telefoon ook niet op het netwerk van de Mac. De sessie eindigt op het bureaublad van de Mac, waar Xcode vervolgens volgens zijn eigen regels een apparaat moet vinden. Aannemen dat de telefoon met de pixels meereist, is de meest voorkomende fout in deze opstelling.

De twee verbindingen zijn onafhankelijk, en de ene kan perfect zijn terwijl de andere helemaal niet bestaat. Het repareren van de bureaubladsessie zegt je niets over de weg naar het apparaat.

Bepaal waar de telefoon fysiek staat voordat je iets configureert

Als de telefoon naast de Mac blijft, doe daar de gewone lokale opstelling: vertrouw de computer, schakel de ontwikkelaarsmodus op het apparaat in en bevestig dat Xcode erop bouwt en draait terwijl je voor de machine zit. Het externe bureaublad bestuurt daarna een werkwijze die al werkt. Dat is de goedkoopste opstelling en degene die je moet kiezen wanneer de hardware het toelaat.

Als de telefoon met je meereist en de Mac in het kantoor blijft, heeft de Mac een ondersteunde route naar dat apparaat nodig. Een VPN levert een netwerkroute tussen beide uiteinden en niets anders: koppelen, ontwikkelaarsmodus, ondertekeningsidentiteit en apparaatregistratie blijven allemaal aparte eisen. Zie de tunnel als één laag in een stapel, niet als de verbinding zelf.

Schrijf op in welke van die twee opstellingen je zit. Elke latere controle hangt daarvan af, en ze door elkaar halen levert oplossingen op die niet kunnen werken.

Behandel ontdekking en transport als twee verschillende problemen

Xcode vindt gekoppelde draadloze apparaten via Bonjour op het lokale netwerk, en het kan ook een apparaat op een bekend adres bereiken via Connect via IP Address. Dat zijn twee mechanismen met twee verschillende storingswijzen. Een apparaat dat nooit in de lijst verschijnt en een apparaat dat verschijnt maar weigert te koppelen zijn niet hetzelfde symptoom, ook al lezen beide als een ontbrekende telefoon.

Zoek naar de advertentie voordat je iets verandert: dns-sd -B _apple-mobdev2._tcp somt de dienst op die een gekoppelde telefoon op de lokale link publiceert. Als er niets verschijnt, is ontdekking de kapotte laag en is een verbinding op adres de enige route die overblijft. Als de dienst verschijnt maar Xcode zich toch niet kan koppelen, werkt ontdekking en is het transport of de vertrouwensrelatie wat faalt.

De Apple-hulp voor draadloze apparaten behandelt zowel de eis van hetzelfde netwerk als de werkwijze met een adres, dus lees die naast je geïnstalleerde versies in plaats van een menupad te volgen dat je je uit een oudere release herinnert. Menulabels verschuiven tussen Xcode-releases, ook wanneer het mechanisme eronder niet verandert.

Controleer wat de Mac kan zien vanaf zijn plek

Voer de opsomming uit op de Mac en niet op je laptop, want de Mac is de machine die het apparaat nodig heeft. xcrun devicectl list devices drukt de apparaten af die Xcode kan bereiken, en system_profiler SPUSBDataType laat zien wat fysiek is aangesloten. Een telefoon die in de tweede lijst staat maar niet in de eerste, is aangesloten en niet gekoppeld, wat een vertrouwensprobleem is en geen netwerkprobleem.

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

Als het apparaat op een ander subnet zit, bevestig dan dat de Mac het adres kan bereiken dat de telefoon publiceert, en onthoud dat link-local IPv6-adressen tot één link beperkt zijn en niet via een tunnel worden gerouteerd. Daarom maakt een VPN alleen zelden een externe telefoon zichtbaar: het adres dat het apparaat adverteert, is alleen betekenisvol op zijn eigen segment.

De technische nota TN3158 van Apple stelt dat Xcode vanaf versie 15 met een bekabeld apparaat praat via een netwerkinterface die op link-local IPv6 is gebouwd, zodat lokale filtering zelfs een fysiek aangesloten telefoon kan storen. Escaleer dat geval naar wie het filterbeleid bezit in plaats van het zelf uit te schakelen.

Bewijs het met een build, niet met een apparaatpictogram

Een apparaatregel in een lijst, een groene indicator in de werkbalk of een geslaagde koppelvraag zijn tussenobservaties. De werkwijze is bewezen wanneer Xcode een toegestane build installeert en de debugger zich aan een proces op het apparaat koppelt.

Voer de volledige reeks uit vanaf de Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installeert zonder de IDE, wat een probleem met de Xcode-interface scheidt van een probleem met de weg naar het apparaat. Start daarna de app en koppel er een console aan. Als de installatie vanaf de opdrachtregel werkt en de IDE niet, zit de resterende fout in het schema of in de ondertekeningsconfiguratie en niet in het netwerk.

Houd de opstelling nauw: één bevoegde ontwikkelaar, één geregistreerde Mac, één apparaat en toegang die eindigt wanneer de sessie eindigt. Trek de inloggegevens in wanneer de opstelling stopt. Als de telefoon gewoon naast de Mac kan blijven, kies dat dan, want de eenvoudigste ondersteunde route heeft de minste lagen om te debuggen.