Ein iPhone lässt sich nicht einfach an einen entfernten Mac für Xcode anschließen

Die übliche Annahme ist, dass eine Sitzung mit entferntem Desktop die gesamte Entwicklungsumgebung auf Ihr Notebook verschiebt. Sie verschiebt den Bildschirm, die Tastatur und die Maus, und sonst nichts. Das iPhone muss den Mac erreichen, auf dem Xcode läuft, und das ist eine eigene Verbindung mit eigenen Anforderungen an Vertrauen, Transport und Berechtigungen. Alles Folgende ergibt sich aus dieser Trennung, und genau dort verlieren die meisten gescheiterten Einrichtungen einen Nachmittag.

Der Mythos: Fernsteuerung verschiebt auch das Gerät

Software für entfernte Desktops überträgt eine Anzeige und einen Eingabestrom, und bei einer guten Verbindung fühlt es sich an, als säße der Mac vor Ihnen. Was sie nicht überträgt, ist USB, und sie stellt das Telefon auch nicht in das Netz des Macs. Die Sitzung endet am Schreibtisch des Macs, wo Xcode dann ein Gerät nach seinen eigenen Regeln finden muss. Die Annahme, das Telefon reise mit den Pixeln, ist der häufigste Fehler in dieser Anordnung.

Die beiden Verbindungen sind unabhängig, und eine kann perfekt sein, während die andere gar nicht existiert. Eine Reparatur der Desktop-Sitzung sagt Ihnen nichts über den Weg zum Gerät.

Entscheiden Sie, wo das Telefon physisch ist, bevor Sie etwas konfigurieren

Bleibt das Telefon neben dem Mac, machen Sie dort die gewöhnliche lokale Einrichtung: Vertrauen Sie dem Computer an, aktivieren Sie den Entwicklermodus auf dem Gerät und bestätigen Sie, dass Xcode darauf baut und startet, während Sie vor der Maschine sitzen. Der entfernte Desktop steuert dann einen Ablauf, der bereits funktioniert. Das ist die günstigste Anordnung und die, die Sie bevorzugen sollten, wann immer es die Hardware erlaubt.

Reist das Telefon mit Ihnen und bleibt der Mac im Büro, braucht der Mac einen unterstützten Weg zu diesem Gerät. Ein VPN liefert eine Netzwerkroute zwischen beiden Enden und sonst nichts: Kopplung, Entwicklermodus, Signaturidentität und Geräteregistrierung bleiben getrennte Anforderungen. Behandeln Sie den Tunnel als eine Schicht in einem Stapel und nicht als die Verbindung selbst.

Notieren Sie, in welcher der beiden Anordnungen Sie sich befinden. Jede spätere Prüfung hängt davon ab, und eine Vermischung führt zu Korrekturen, die nicht funktionieren können.

Behandeln Sie Erkennung und Transport als zwei verschiedene Probleme

Xcode findet gekoppelte drahtlose Geräte über Bonjour im lokalen Netzwerk und kann ein Gerät unter einer bekannten Adresse auch über Connect via IP Address erreichen. Das sind zwei Mechanismen mit zwei verschiedenen Fehlerbildern. Ein Gerät, das nie in der Liste erscheint, und ein Gerät, das erscheint, aber die Zuordnung verweigert, sind nicht dasselbe Symptom, obwohl sich beides als fehlendes Telefon liest.

Sehen Sie sich die Ankündigung an, bevor Sie etwas ändern: dns-sd -B _apple-mobdev2._tcp listet den Dienst auf, den ein gekoppeltes Telefon auf dem lokalen Link veröffentlicht. Erscheint nichts, ist die Erkennung die defekte Schicht, und eine adressbasierte Verbindung ist der einzig verbleibende Weg. Erscheint der Dienst, aber Xcode kann sich weiterhin nicht zuordnen, funktioniert die Erkennung, und es scheitert der Transport oder die Vertrauensbeziehung.

Die Apple-Hilfe zu drahtlosen Geräten deckt sowohl die Anforderung des gleichen Netzwerks als auch den Ablauf über die Adresse ab; lesen Sie sie daher gegen Ihre installierten Versionen, statt einem aus einer älteren Version erinnerten Menüpfad zu folgen. Menübeschriftungen verschieben sich zwischen Xcode-Versionen, auch wenn der Mechanismus darunter gleich bleibt.

Prüfen Sie, was der Mac von seinem Standort aus sieht

Führen Sie die Aufzählung auf dem Mac aus, nicht auf Ihrem Notebook, denn der Mac ist die Maschine, die das Gerät braucht. xcrun devicectl list devices gibt die Geräte aus, die Xcode erreichen kann, und system_profiler SPUSBDataType zeigt, was physisch angeschlossen ist. Ein Telefon, das in der zweiten Liste erscheint, aber nicht in der ersten, ist angeschlossen und nicht gekoppelt, was ein Vertrauensproblem und kein Netzwerkproblem ist.

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

Liegt das Gerät in einem anderen Subnetz, bestätigen Sie, dass der Mac die vom Telefon veröffentlichte Adresse erreicht, und bedenken Sie, dass link-lokale IPv6-Adressen auf einen Link beschränkt und nicht über einen Tunnel routbar sind. Deshalb macht ein VPN allein ein entferntes Telefon selten sichtbar: Die Adresse, die das Gerät ankündigt, ist nur in seinem eigenen Segment sinnvoll.

Die Apple-Techniknotiz TN3158 stellt fest, dass Xcode ab Version 15 mit einem verkabelten Gerät über eine Netzwerkschnittstelle spricht, die auf link-lokalem IPv6 aufbaut, sodass lokale Filterung selbst ein physisch angeschlossenes Telefon stören kann. Geben Sie diesen Fall an die Stelle weiter, die die Filterrichtlinie verantwortet, statt sie selbst abzuschalten.

Beweisen Sie es mit einem Build, nicht mit einem Gerätesymbol

Ein Geräteeintrag in einer Liste, eine grüne Anzeige in der Symbolleiste oder eine erfolgreiche Kopplungsabfrage sind Zwischenbeobachtungen. Der Ablauf ist bewiesen, wenn Xcode einen zulässigen Build installiert und der Debugger sich an einen auf dem Gerät laufenden Prozess anhängt.

Führen Sie die vollständige Sequenz vom Mac aus. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installiert ohne die IDE, was ein Problem der Xcode-Oberfläche von einem Problem des Gerätepfads trennt. Starten Sie dann die App und hängen Sie eine Konsole daran. Funktioniert die Installation über die Kommandozeile und die IDE nicht, liegt der verbleibende Fehler im Schema oder in der Signierungskonfiguration und nicht im Netzwerk.

Halten Sie die Anordnung eng: ein autorisierter Entwickler, ein registrierter Mac, ein Gerät und ein Zugang, der endet, wenn die Sitzung endet. Widerrufen Sie Anmeldedaten, wenn die Anordnung endet. Kann das Telefon einfach neben dem Mac bleiben, wählen Sie das, denn der einfachste unterstützte Weg ist der mit den wenigsten verbleibenden Schichten zum Debuggen.