Ein exklusiver Mac · zwei Zugriffswege

Builds per SSH,
Xcode per VNC

Kommandozeile und grafischer Desktop greifen auf denselben physischen Mac mini zu. Der Runner erledigt laufende Aufgaben. Wenn Sie Xcode, Simulatoren oder Zertifikate prüfen müssen, öffnen Sie die Bildschirmfreigabe.

Exklusiven Mac-Runner mieten Verbindung einrichten

Apple Silicon M4 · 2 Konfigurationen · ab $20/Tag. Der gesamte Rechner ist einem Kunden vorbehalten und keine virtuelle Maschine.

Eigener Team-Workflow

Builds laufen weiter, Desktop bei Bedarf

SSHAutomatisierung
  1. Projekt synchronisieren
  2. Tests ausführen
  3. Artefakte archivieren
VNCManuelle Prüfung
  1. Xcode öffnen
  2. Simulator prüfen
  3. Signierung prüfen

Projekt, Speicher und Toolchain werden gemeinsam genutzt – es sind nicht zwei Rechner, die separat eingerichtet werden müssen. Auch die Desktopnutzung beansprucht die Ressourcen des gesamten Rechners.

Aufgaben verteilen, dann verbinden

Automatisierung per Kommandozeile, manuelle Prüfungen am Desktop

Beide Zugriffswege lassen sich parallel nutzen. Entscheidend ist, ob eine Aufgabe eine grafische Oberfläche benötigt – nicht, ob jemand am Rechner sitzt.

SSH: für wiederkehrende Aufgaben

Zum Kompilieren und Testen mit xcodebuild, zum Registrieren von Runnern und Prüfen von Logs sowie für den Dateitransfer mit scp oder rsync. Build-Logs sind Text; eine laufende Übertragung des Desktopbilds ist dafür nicht nötig.

  • Abhängigkeiten installieren, Tests ausführen und Archive in die Pipeline integrieren, statt alles manuell anzuklicken.
  • Runner-Prozesse, Arbeitsverzeichnisse, freien Speicher und Fehlerprotokolle prüfen.
  • Runner als Dienst verwalten, damit länger laufende Aufgaben nicht von einer einzelnen SSH-Sitzung abhängen.

Geeignet für: PR-Prüfungen, Nightly-Builds, Stapelverarbeitung und Artefakttransfer.

VNC: wenn Sie die Oberfläche sehen müssen

Für die Xcode-Oberfläche, die Bedienung von Simulatoren sowie Schlüsselbund- und Zertifikatseinstellungen. Nutzen Sie die macOS-Bildschirmfreigabe oder einen kompatiblen VNC-Client.

  • Den tatsächlichen Status von Projekt-Targets, Build-Einstellungen und Signierung prüfen.
  • UI-Probleme im Simulator reproduzieren und Laufzeit sowie Gerätetyp überprüfen.
  • Einstellungen mit interaktiver Bestätigung vornehmen und wiederholbare Schritte anschließend skripten.

Geeignet für: Einrichtung, grafische Fehlersuche und manuelle Prüfungen vor der Veröffentlichung.

Erste Verbindung

Zugangsdaten einmal prüfen, beide Wege testen

Melden Sie sich im Portal an und öffnen Sie die Details der entsprechenden Instanz. Verwenden Sie die dort angezeigte Adresse, den Benutzernamen, Port und die Authentifizierungsmethode. Der SSH-Port ist nicht automatisch auch der VNC-Port.

  1. 01

    Zugangsdaten der Instanz abrufen

    Prüfen Sie Instanz-ID und Standort und notieren Sie die Verbindungsdaten für SSH und VNC getrennt. Vergewissern Sie sich vor dem ersten Verbindungsversuch, dass die Instanz bereit ist. Falls im Portal noch keine Zugangsdaten angezeigt werden, halten Sie Ihre Bestellinformationen bereit und fragen Sie über ein Support-Ticket im Portal nach. Raten Sie weder Adresse noch Passwort wiederholt.

  2. 02

    Kommandozeilenzugriff testen

    Verbinden Sie sich mit dem für die Instanz angegebenen Port und Benutzernamen. Prüfen Sie beim ersten Verbindungsversuch den angezeigten Host-Fingerprint. Ändert sich der Fingerprint derselben Adresse unerwartet, brechen Sie die Verbindung ab und klären Sie, ob die Instanz neu zugewiesen wurde.

    ssh -p "$SSH_PORT" "$MAC_USER@$MAC_HOST"
sw_vers
uname -m
xcode-select -p
df -h

    Setzen Sie die Variablen in Ihrem lokalen Terminal auf die im Portal angezeigten Werte. Prüfen Sie nach erfolgreicher Verbindung macOS, Architektur, Entwicklerverzeichnis und freien Speicherplatz.

  3. 03

    Bildschirmfreigabe öffnen

    Öffnen Sie unter macOS auf Ihrem lokalen Rechner die Bildschirmfreigabe und geben Sie die VNC-Adresse samt Port der Instanz ein. Auf anderen Systemen verwenden Sie einen kompatiblen Client. Melden Sie sich mit der für die Instanz vorgesehenen Authentifizierung an. Prüfen Sie zuerst, ob Sie den Desktop sehen und die Maus bedienen können, und öffnen Sie danach Xcode. Bei Verbindungsproblemen kontrollieren Sie Adresse, Port, Zugangsdaten und lokale Netzwerkeinschränkungen.

  4. 04

    Zugriff absichern

    Ändern Sie nach der ersten Anmeldung die anfänglichen Zugangsdaten mit der für die Instanz vorgesehenen Methode. Verwalten Sie SSH-Schlüssel für Teammitglieder getrennt und speichern Sie keine Passwörter im Repository. Registrieren Sie Runner mit Tokens, die nur die nötigen Rechte haben. Zugangsdaten, Zertifikate und private Schlüssel gehören in einen kontrollierten Prozess zur Schlüsselverwaltung. Führen Sie zunächst einen einfachen Build aus und aktivieren Sie danach die produktive Pipeline.

Im Portal anmelden und Zugangsdaten ansehen

5 Standorte · Netzwerk-Richtwerte

Beim Desktop zählt die Latenz, beim Build der Datenpfad

Die Reaktionszeit bei VNC hängt von der Round-Trip-Latenz ab. Bei laufenden Builds sind vor allem die Standorte von Repository, Paketquellen und Artefaktspeicher wichtig. Die folgenden Werte sind Richtwerte für die Standorte. Sie wurden nicht von Ihrem aktuellen Standort aus gemessen und sind keine Zusicherung für die Verbindungslatenz.

Standort, Einzugsgebiet und Round-Trip-Richtwert; wählen Sie den Zugriff passend zu Ihrer hauptsächlichen Arbeitsweise.
Standort Region Round-Trip-Richtwert Geeignet für
Singapur Südostasien 20~50ms Interaktive Entwicklung im Team in Südostasien; prüfen Sie auch Repository- und Downloadpfade für Abhängigkeiten.
Japan (Tokio) Ostasien 30~60ms Xcode-Nutzung durch Teammitglieder in Ostasien; Runner und Artefaktspeicher möglichst nahe platzieren.
Südkorea (Seoul) Nordostasien 30~50ms Simulator-Prüfungen, Remote-Fehlersuche und Projektsynchronisierung für Teams in Nordostasien.
Hongkong Südchina und Südostasien 20~40ms Bildschirmfreigabe und tägliche Build-Aufgaben für Teams in Südchina und Südostasien.
US-Ostküste Ost-Nordamerika und Westeuropa 25~35ms Zusammenarbeit für diese Region; wählen Sie den Standort passend zu Code- und Artefaktspeicher.

Richtwerte; die tatsächliche Verbindung hängt von Ihrem Netzwerk ab.

Testen Sie die Verbindung zunächst über ein häufig genutztes Büronetzwerk: Bedienen Sie einmal den Desktop, laden Sie Abhängigkeiten herunter und laden Sie ein Artefakt hoch. Halten Sie Bediengefühl, Übertragungsdauer und Build-Dauer getrennt fest, statt daraus ein pauschales Urteil über die Rechnerleistung abzuleiten.

Erst die Bildlast senken, dann die Verbindung prüfen

Bandbreite für die aktuelle Aufgabe reservieren

Beginnen Sie mit den nötigen Anzeigeeinstellungen. Je größer das Remote-Bild und je häufiger sich der Bildschirminhalt ändert, desto höher ist der Aufwand für Kodierung und Übertragung. Die Desktop-Einstellungen beschleunigen den Compiler nicht, können aber Wartezeiten bei der Bedienung verkürzen.

Auflösung an den Arbeitsbereich anpassen

Starten Sie mit 1440 × 900 oder 1600 × 900 und stellen Sie sicher, dass Editor und Logs gut lesbar sind. Erhöhen Sie die Auflösung nur, wenn Sie tatsächlich mehr Bereiche benötigen. Übertragen Sie nicht standardmäßig den gesamten Bildschirm in hoher Auflösung.

Ändern Sie jeweils nur eine Einstellung und vergleichen Sie Lesbarkeit und Reaktion beim Verschieben von Fenstern.

Farbtiefe und Qualität im Client einstellen

Wenn Ihr Client Einstellungen für Farbtiefe, Qualität oder Komprimierung anbietet, reduzieren Sie bei geringer Bandbreite zunächst die Bildqualität. Text im Code muss lesbar bleiben. Vermeiden Sie Videowiedergabe und ständig aktualisierte Fenster, die Sie nicht benötigen.

Die Optionen heißen je nach Client anders. Maßgeblich sind die verfügbaren Einstellungen.

Desktop bei Bedarf schließen

Bei großen Dateitransfers oder einer langsamen Verbindung können Sie Text-Logs per SSH prüfen und Builds einem als Dienst eingerichteten Runner überlassen. Halten Sie länger laufende Aufgaben nicht in einem grafischen Terminalfenster offen. Prüfen Sie zuerst, ob sie auch ohne interaktive Sitzung weiterlaufen.

Trennen Sie nach der Prüfung die Desktopverbindung, ohne sich vom System abzumelden oder es herunterzufahren.

Grenzen der Xcode-Remote-Entwicklung

Am Desktop prüfen, in der Pipeline reproduzieren

Machen Sie manuelle Prüfungen zu nachvollziehbaren Änderungen an der Umgebung: Dokumentieren Sie Xcode-Version, Simulator-Laufzeitumgebung und Signierungseinstellungen und prüfen Sie anschließend dasselbe Projekt über die Kommandozeile. Verlassen Sie sich nicht auf Einstellungen, die nur einmal am Desktop angeklickt wurden.

Computer und Desktopgeräte an einem Remote-Entwicklungsarbeitsplatz; gezeigt wird der Zugriff vom lokalen Arbeitsplatz auf Xcode in der Cloud
Beispiel eines Remote-Entwicklungsarbeitsplatzes. Bei der Bildschirmfreigabe wird der Desktop in der Cloud übertragen; lokale Peripheriegeräte werden dadurch nicht automatisch mit dem Remote-Rechner verbunden.

In der Cloud möglich

Projektprüfung in Xcode, Kompilieren, Archivieren, Simulator-Tests und Zertifikatseinstellungen finden in der entfernten macOS-Umgebung statt. SSH und VNC greifen auf dieselben Dateien zu. Ändern Sie kein Arbeitsverzeichnis manuell, während der Runner es verwendet.

Tests auf echten Geräten separat planen

Ein lokal angeschlossenes iPhone wird durch VNC nicht in Xcode in der Cloud angezeigt. Für Tests auf echten Geräten müssen Gerätezugriff und Testablauf separat eingerichtet werden. Sie können den Build zunächst in der Cloud signieren und ihn anschließend über den bestehenden Verteilungsprozess des Teams an die Testgeräte weitergeben.

Projekt, Cache und Artefakte getrennt verwalten

Kleine Dateien direkt übertragen, wiederholte Syncs inkrementell ausführen

Das Repository verwaltet die Versionshistorie; die Dateisynchronisierung kümmert sich um Arbeitskopien und Artefakte. Übertragen Sie Zertifikate, private Schlüssel und Tokens nicht in gewöhnlichen Projektverzeichnissen. Prüfen Sie vor dem Upload Ignore-Regeln und Zielpfad.

scp: ein Build-Artefakt übertragen

Geeignet für ein bestimmtes Archiv oder Ressourcenpaket. Der folgende Befehl lädt ein bereits erstelltes Archiv vom Remote-Rechner herunter. Ersetzen Sie Remote-Verzeichnis und Dateinamen durch die tatsächlichen Pfade.

scp -P "$SSH_PORT" \
  "$MAC_USER@$MAC_HOST:build/ios-build.zip" \
  ./ios-build.zip

Bei scp wird der Port mit dem großen -P angegeben. Prüfen Sie anschließend die Dateigröße und vergleichen Sie bei Bedarf die Prüfsummen beider Dateien.

rsync: Arbeitskopie des Projekts synchronisieren

Geeignet für wiederholte Synchronisierungen desselben Verzeichnisses. Führen Sie zuerst einen Probelauf aus und prüfen Sie Zielpfad und Ausschlüsse. Der Schrägstrich am Ende bezeichnet den Inhalt des Verzeichnisses.

rsync -avn \
  -e "ssh -p $SSH_PORT" \
  --exclude '.git/' \
  --exclude 'DerivedData/' \
  ./project/ "$MAC_USER@$MAC_HOST:project/"

Wenn die Ausgabe des Probelaufs stimmt, ersetzen Sie -avn durch -av. Es wird kein Löschparameter verwendet, damit lokal fehlende Dateien nicht versehentlich auf dem Remote-Rechner entfernt werden.

Standort festlegen, ersten Build starten

Wählen Sie den Standort mit der kürzesten Verbindung

Für interaktive Entwicklung zählt Ihr Büronetzwerk, für laufende Builds der Standort von Repository und Artefakten. Wählen Sie den Standort bei der Bestellung; den aktuellen Verfügbarkeitsstatus sehen Sie direkt im Portal.

Standort wählen und Mac mieten Richtwerte für 5 Standorte