Für Entwicklerteams in APAC und Nordamerika

Von der Verbindung bis zum fertigen Build

Ihr Mac ist bereit? Dann prüfen Sie gezielt den Schritt, an dem es gerade hakt. Kontrollieren Sie Verbindung, Toolchain, Codesignierung und Pipeline getrennt – so wird ein erfolgreicher Build reproduzierbar.

Cloud-Mac mieten Instanz in der Konsole anzeigen

Adresse, Port, Benutzername und Bereitstellungsstatus finden Sie in den Instanzdetails der Konsole. Ersetzen Sie die Umgebungsvariablen in den Befehlen durch Ihre eigenen Werte. Sie enthalten keine echten Zugangsdaten.

01 · Mit dem Mac verbinden

Erst den Zugang prüfen, dann die Verbindung

SSH dient für die Kommandozeile und Automatisierung, VNC für die grafische Oberfläche. Beide verbinden Sie mit demselben dedizierten Mac, aber die Verbindungsdaten müssen Sie jeweils separat prüfen.

SSH: Angaben aus der Bereitstellung prüfen

Öffnen Sie die betreffende Instanz in der Konsole und notieren Sie Hostadresse, SSH-Port und Benutzernamen. Prüfen Sie zunächst lokal den Pfad zum privaten Schlüssel und stellen Sie dann die Verbindung her. Verwenden Sie nicht den VNC-Port im SSH-Befehl.

chmod 600 "$SSH_KEY"
ssh -i "$SSH_KEY" -p "$SSH_PORT" "$NODE_USER@$NODE_HOST"

Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerabdruck. Können Sie ihn nicht verifizieren, eröffnen Sie zunächst ein Support-Ticket, statt die Host-Prüfung zu deaktivieren. Bei einem Timeout prüfen Sie zuerst Ihr lokales Netzwerk und die Erreichbarkeit des Ports. Bei einer Berechtigungsverweigerung prüfen Sie Benutzername, Schlüssel und den auf der Instanz hinterlegten öffentlichen Schlüssel.

Nach einer Neuinstallation oder einem Austausch des Macs kann sich der Fingerabdruck ändern. Aktualisieren Sie den lokalen Eintrag erst, nachdem Sie bestätigt haben, dass die Instanz tatsächlich geändert wurde.

VNC: für interaktive Aufgaben am Desktop

Verbinden Sie sich mit den Remote-Desktop-Daten aus der Konsole und prüfen Sie Adresse, Port und Passwort. Legen Sie nach dem ersten Login ein eigenes Zugriffspasswort fest, statt dieselben Zugangsdaten dauerhaft mit mehreren Personen zu teilen.

Der Desktop eignet sich zum Einrichten von Xcode, Prüfen des Schlüsselbunds und Beobachten des Simulators. Dauerhafte Builds sollten über SSH oder einen Runner laufen. Funktioniert SSH, aber der Desktop nicht, notieren Sie Fehlermeldung des Clients und Instanzstatus und prüfen Sie gezielt den Remote-Desktop, statt den ganzen Mac wiederholt neu zu starten.

Wenn Sie den Zugriff über einen SSH-Tunnel benötigen, leiten Sie den tatsächlichen VNC-Port weiter und verbinden Sie den Client mit dem lokalen Port:

ssh -N -L 5901:127.0.0.1:"$VNC_PORT" \
  -p "$SSH_PORT" "$NODE_USER@$NODE_HOST"

Die Verbindung muss während der Nutzung bestehen bleiben. Ob ein Tunnel verwendet wird und welcher Port gilt, hängt von der Instanzkonfiguration und den Zugriffsrichtlinien Ihres Teams ab.

Knoten: nach Arbeitsort statt Projektzugehörigkeit auswählen

Es gibt fünf Standorte: Singapur, Tokio, Seoul, Hongkong und die US-Ostküste. Für interaktive Desktop-Arbeit empfiehlt sich ein Standort in der Nähe der meisten Nutzer. Bei automatisierten Builds zählen auch die Wege zu Code und Abhängigkeiten. Teams über mehrere Regionen hinweg können jeweils einen nahe gelegenen Build-Mac einrichten und Jobs über klar definierte Runner-Labels zuweisen. Nicht alle müssen denselben Desktop fernsteuern.

Vergleichen Sie Standorte mit demselben Client, Netzwerk und Zeitfenster. Erfassen Sie Verbindungs-Latenz, Dauer des Repository-Downloads und einen vollständigen Build. Netzwerk-Latenz ist nicht gleich Kompilierzeit; vergleichen Sie keine Ergebnisse aus unterschiedlichen Netzwerkbedingungen.

02 · Toolchain festlegen

Jedem Branch eine klare Xcode-Umgebung zuordnen

Notieren Sie zuerst die Versionen, migrieren Sie danach die Signaturdaten. Ein erfolgreicher Build auf dem Desktop bedeutet nicht, dass auch die Runner-Sitzung bereit ist.

Versionen parallel nutzen, ohne Jobs umzustellen

Benennen Sie die Xcode-Versionen eindeutig und legen Sie sie im Programme-Ordner ab. Stable und Next sind frei gewählte App-Namen – ersetzen Sie sie vor der Ausführung durch die tatsächlichen Namen auf dem Mac. Starten Sie jede Version einmal, bestätigen Sie die Lizenz und installieren Sie die benötigten Plattformkomponenten, bevor Sie sie in die Pipeline aufnehmen.

xcode-select -p
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-version

sudo xcode-select --switch \
  /Applications/Xcode-Stable.app/Contents/Developer

Ein globaler Wechsel wirkt sich auf alle Jobs aus, die keine Toolchain explizit festlegen. Bei parallelen Builds für mehrere Branches setzen Sie die Umgebungsvariable besser pro Job. So kann eine andere Pipeline nicht die Standardversion ändern, die gerade verwendet wird.

export DEVELOPER_DIR=/Applications/Xcode-Next.app/Contents/Developer
xcodebuild -version

Zertifikat, privaten Schlüssel und Profil gemeinsam prüfen

Importieren Sie das Signierzertifikat samt zugehörigem privaten Schlüssel unter dem macOS-Benutzer, der den Build tatsächlich ausführt. Installieren Sie anschließend das Provisioning-Profil passend zu den Signiereinstellungen der verwendeten Xcode-Version. Ohne privaten Schlüssel lässt sich ein Zertifikat nicht zum Codesignieren verwenden.

security find-identity -v -p codesigning
xcodebuild -list -workspace App.xcworkspace

Prüfen Sie Team-ID, Bundle Identifier, Signiermethode und Gültigkeitsbereich des Provisioning-Profils im Projekt. Führen Sie zunächst als derselbe Benutzer manuell einen Archive-Vorgang aus und lassen Sie anschließend CI denselben Befehl ausführen. So können Sie Projektkonfiguration und Berechtigungen der Runner-Sitzung voneinander unterscheiden.

Für die Automatisierung empfiehlt sich ein eigener Schlüsselbund mit einem kontrollierten Verfahren zur Bereitstellung von Schlüsseln. Prüfen Sie, ob die Signieridentität in einer nicht interaktiven Sitzung verfügbar ist. Speichern Sie weder Schlüsselbundpasswort, Exportpasswort des Zertifikats noch privaten Schlüssel im Repository oder in Build-Logs.

Einen nachvollziehbaren Build-Beleg erstellen

Das folgende Beispiel verwendet einen Workspace und ein gemeinsam genutztes Scheme. Ersetzen Sie Projektnamen, Scheme und Exportkonfiguration. Richten Sie die Exportkonfiguration nach den Signier- und Distributionsanforderungen des Projekts aus. Protokollieren Sie Exit-Code, Toolchain-Version und Pfad des Build-Artefakts – nicht nur die Erfolgsmeldung.

xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath "$HOME/builds/App.xcarchive"

xcodebuild -exportArchive \
  -archivePath "$HOME/builds/App.xcarchive" \
  -exportPath "$HOME/builds/export" \
  -exportOptionsPlist ExportOptions.plist
03 · Kontinuierliche Builds einrichten

Jobs einem festen macOS-Benutzer zuweisen

Auch wenn ein Mac exklusiv an einen Kunden vermietet wird, sind Jobs nicht automatisch voneinander isoliert. Ihr Team muss weiterhin Benutzer, Verzeichnisse und Warteschlangen klar festlegen.

GitHub Actions: erst registrieren, dann als Dienst einrichten

Laden Sie in den Runner-Einstellungen des Repositorys oder der Organisation das passende Paket für Apple Silicon und die Registrierungsbefehle herunter und entpacken Sie alles in ein eigenes Verzeichnis. Verwenden Sie das temporäre Token von dieser Seite und registrieren Sie den Runner für das betreffende Repository oder die Organisation. Speichern Sie das Token nicht in einem Skript.

./config.sh \
  --url "$RUNNER_URL" \
  --token "$RUNNER_TOKEN" \
  --labels pushmac,macos,arm64

./svc.sh install
./svc.sh start
./svc.sh status

Der Wert runs-on im Workflow muss zu den registrierten Labels passen. Starten Sie zuerst einen Testjob ohne Signierdaten und prüfen Sie Toolchain, Arbeitsverzeichnis und Berechtigungen. Fügen Sie erst danach Release-Jobs hinzu. Verwenden Sie Runner mit Signiermaterial nur für vertrauenswürdigen Code.

Führen Sie die Dienstbefehle im Installationsverzeichnis des Runners aus. Verwenden Sie für den Dienst denselben Benutzer wie für die Bedienung.

GitLab Runner: Executor und Arbeitsverzeichnis festlegen

Installieren Sie gemäß der Dokumentation Ihrer GitLab-Instanz eine kompatible Runner-Version und registrieren Sie sie mit den von der Instanz bereitgestellten Zugangsdaten. Für native macOS-Builds können Sie den Shell-Executor wählen. Dabei laufen Jobs mit den Berechtigungen des lokalen Benutzers. Beschränken Sie daher, welche Projekte und Branches Jobs starten dürfen.

mkdir -p "$HOME/ci"
gitlab-runner register
gitlab-runner install --working-directory "$HOME/ci"
gitlab-runner start
gitlab-runner status

Geben Sie die Adresse Ihrer GitLab-Instanz, Token, Labels und Executor wie aufgefordert ein. Die Konfigurationsdatei kann Zugangsdaten enthalten – schränken Sie den Zugriff darauf ein. Logs sollten Jobnummern und Fehler-Stacktraces enthalten, aber keine geheimen Umgebungsvariablen ausgeben.

Die Installationsparameter müssen zur installierten Runner-Version passen. Prüfen Sie vor der Ausführung die lokale Hilfe.

Autostart mit dem ersten Job nach einem Neustart prüfen

Dienste für macOS-Benutzer benötigen in der Regel eine angemeldete Benutzersitzung. Die Installation eines Dienstes garantiert nicht, dass Signieraufgaben auch ohne Login ausgeführt werden können. Prüfen Sie den verwendeten launchd-Diensttyp, die Login-Bedingungen und die Verfügbarkeit des Schlüsselbunds. Um Autostart zu erzwingen, dürfen Sie die Zugriffsrichtlinien Ihres Teams nicht umgehen.

Prüfen Sie in einem kontrollierten Zeitfenster nach einem Neustart den Dienststatus und führen Sie einen vollständigen Build aus. Führen Sie Fastlane mit den im Projekt festgelegten Abhängigkeiten aus, zum Beispiel bundle exec fastlane ios build. Der Lane-Name richtet sich nach dem Projekt. Legen Sie bei Übergaben über Zeitzonen hinweg Parallelität und Warteschlangenregeln klar fest, damit nicht zwei Archive in dasselbe Artefaktverzeichnis schreiben.

04 · Wiederverwendbare Arbeit behalten

Build-Zeiten aufschlüsseln, dann Speicher erweitern

Erfassen Sie die Dauer für Abhängigkeitsauflösung, Kompilierung, Codesignierung und Export separat. Nur wenn Commit und Toolchain identisch sind, lässt sich der Kaltbau mit dem Warmbau vergleichen und die Cache-Wirkung beurteilen.

Caches nach Projekt und Toolchain trennen

Auf einem dedizierten Mac können Sie DerivedData, SPM-Downloads und CocoaPods-Caches während der Mietdauer behalten. Lassen Sie nicht alle Branches unterschiedslos in dasselbe Verzeichnis schreiben. Trennen Sie Pfade nach Projekt, Toolchain und Jobtyp und behalten Sie die Lockfiles für Abhängigkeiten bei.

xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'generic/platform=iOS' \
  -derivedDataPath "$HOME/ci-cache/App/stable/DerivedData" \
  -clonedSourcePackagesDirPath "$HOME/ci-cache/App/stable/SPM" \
  -archivePath "$HOME/builds/App.xcarchive"

Bei Flutter- und React-Native-Projekten müssen außerdem Toolversionen und gesperrte iOS-Abhängigkeiten zueinander passen. Bei Fehlern sichern Sie zuerst die Logs und bereinigen Sie dann gezielt die betroffenen Caches. Werden vor jedem Build alle Caches gelöscht, geht der Vorteil von Warm-Builds in der Regel verloren.

Speicherplatz und Arbeitsspeicher getrennt betrachten

Push M4 S bietet M4 / 16GB / 256GB und eignet sich für die tägliche CI eines einzelnen Apps. Push M4 L bietet M4 / 24GB / 512GB und passt zu höherem Arbeitsspeicherbedarf sowie Builds mit mehreren Targets. Ob parallele Builds sinnvoll sind, sollte ein Test mit dem jeweiligen Projekt zeigen.

+1TB SSD eignet sich, wenn Abhängigkeits-Caches, mehrere Toolchains und ältere Build-Artefakte nach und nach den Systemdatenträger füllen. +2TB SSD ist für Workflows gedacht, die mehr Projekt-Caches und Archives behalten müssen. Eine Speichererweiterung erhöht nicht den gemeinsamen Arbeitsspeicher und garantiert keine schnelleren Builds.

df -h
du -sh "$HOME/ci-cache" "$HOME/builds"

Legen Sie zuerst den Einhängepfad fest, migrieren Sie dann die Caches und passen Sie die Pipeline-Variablen an. Ein Speicher-Add-on ist kein Backup. Sichern Sie Archives, Symboldateien und wichtige Konfigurationen weiterhin gemäß den Richtlinien Ihres Teams separat.

Konfiguration und Add-ons ansehen
05 · Konto und Mietdauer

Verlängerung vor dem nächsten Release einplanen

Abrechnungszeitraum, Standort und Zahlungsstatus entnehmen Sie der Konsole. Geben Sie bei einem Support-Ticket die Bestellnummer an, aber senden Sie keine Passwörter, privaten Schlüssel oder vollständigen Kartendaten.

Miete ab einem Tag und Verlängerungszeiträume

Abrechnung ist täglich, wöchentlich, monatlich oder vierteljährlich möglich. Push M4 S kostet $19.2 pro Tag, $51.8 pro Woche, $95.9 pro Monat oder $260.8 pro Quartal; Push M4 L kostet $39.7 pro Tag, $107.2 pro Woche, $198.5 pro Monat oder $539.9 pro Quartal. Prüfen Sie in der Konsole das Ablaufdatum der Instanz, die Verlängerungsoptionen und verfügbare Zeiträume. Leiten Sie Listenpreise für andere Zeiträume nicht durch Multiplikation des Tagespreises ab.

Prüfen Sie vor einem Release, ob die Mietdauer Build und Abnahme abdeckt. Wenn Sie den Zeitraum ändern möchten, richten Sie sich nach den verfügbaren Aktionen in der Konsole und der tatsächlichen Abrechnung. Gehen Sie nicht davon aus, dass eine bereits erfolgte Zahlung automatisch auf einen anderen Zeitraum umgestellt wird.

Vor dem Wechsel des Standorts die Migration vorbereiten

Ein Standortwechsel bringt einen neuen Netzwerkzugang und eine neue Mac-Umgebung mit sich. Er ist nicht mit dem Ändern eines Regionslabels getan. Klären Sie das Vorgehen zuerst über ein Support-Ticket in der Konsole und sichern Sie anschließend Code, Signiermaterial, Runner-Konfiguration und benötigte Build-Artefakte. Gehen Sie nicht davon aus, dass lokale Dateien, Caches oder Login-Daten automatisch migriert werden.

Prüfen Sie nach der Migration erneut Host-Fingerabdruck, Runner-Labels und Signierberechtigungen. Verifizieren Sie den neuen Mac mit einem Build, bevor Sie keine weiteren Jobs mehr an die alte Umgebung verteilen.

Zahlungsarten und Abrechnung in US-Dollar

Unterstützt werden ausschließlich USDT-TRC20 sowie Visa-, Mastercard- und Amex-Karten, verarbeitet über Stripe. Abgerechnet wird immer in US-Dollar (USD). Welche Zahlungswege tatsächlich verfügbar sind, richtet sich nach der Rückmeldung des Backends. Bezahlen Sie on-chain mit Netzwerk, Empfängerangaben und Betrag der jeweiligen Bestellung. Verwenden Sie keine Angaben aus einer früheren Bestellung erneut.

Prüfen Sie nach der Zahlung zuerst den Bestellstatus. Falls eine Klärung nötig ist, geben Sie im Support-Ticket die Bestellnummer, den Zahlungszeitpunkt und den Transaktions-Hash oder die Zahlungsreferenz an. Lösen Sie keine weitere Zahlung aus, um den Status zu aktualisieren.

365 Tage Betrieb und Projekt-Backups

Dedizierte physische Knoten sind 365 Tage im Jahr in Betrieb. Das Rechenzentrum kümmert sich um Stromversorgung, Netzwerk und Kühlung. Dauerbetrieb ersetzt kein Projekt-Backup und bedeutet nicht, dass die Verbindung auf Ihrer Seite nie unterbrochen wird. Bricht eine Remote-Sitzung ab, prüfen Sie zuerst den Instanzstatus und eine alternative Verbindungsmethode, bevor Sie von einem Problem mit dem Mac ausgehen.

Nach Ende der Mietdauer wird der gesamte Mac gelöscht, bevor er an den nächsten Kunden übergeben wird. Exportieren Sie vor der Rückgabe benötigten Code, Build-Artefakte und Konfigurationen. Entfernen Sie die Runner-Registrierung und widerrufen Sie zugehörige Zugriffstoken. Nutzen Sie die Instanz nicht als einzigen Speicherort für Ihre Daten.

Build-Abläufe weiter optimieren

Für konkrete Schritte: Anleitung. Für Konzepte: Fachartikel.

Diese Seite behandelt konkrete Arbeitsschritte. Für Migration, Cache-Design und Zusammenarbeit über Zeitzonen hinweg finden Sie den vollständigen Kontext in unseren Artikeln.

PushMac-Fachartikel ansehen

Wählen Sie ein Thema aus unseren veröffentlichten Artikeln und lesen Sie die vollständigen Schritte und Voraussetzungen. Bevor Sie Toolchains migrieren oder Cache-Verzeichnisse ändern, halten Sie die bestehende Konfiguration fest, planen Sie einen Rollback und prüfen Sie jede Änderung einzeln.

Die Befehle in dieser Anleitung dienen der Orientierung. Auch die Praxisbeispiele in den Artikeln müssen Sie an Repository-Struktur, Signierrichtlinien und Berechtigungen Ihres Teams anpassen.

Fachartikel lesen

Support-Tickets mit nachvollziehbaren Build-Daten ergänzen

Wenn Teammitglieder in APAC und Nordamerika dasselbe Problem nacheinander bearbeiten, erleichtern genaue Zeit- und Standortangaben die weitere Diagnose. „Verbindung funktioniert nicht“ reicht dafür meist nicht aus.

  1. 01

    Instanz identifizieren

    Geben Sie Bestell- oder Instanznummer, Standort sowie Zeitpunkt und Zeitzone an. Wenn Teammitglieder unterschiedliche Netzwerke nutzen, nennen Sie für jede Verbindung den jeweiligen Standort.

  2. 02

    Fehler dokumentieren

    Fügen Sie die Fehlermeldung des Clients, den Build-Befehl, Exit-Code, die Xcode-Version und den letzten relevanten Logabschnitt hinzu. Entfernen Sie vertrauliche Informationen, bevor Sie Screenshots oder Text übermitteln.

  3. 03

    Bereits geprüfte Schritte aufführen

    Geben Sie an, ob SSH und VNC jeweils funktionieren, ob sich das Problem reproduzieren lässt und welche Konfigurationen zuletzt geändert wurden. So muss die nächste Person die gleichen Prüfungen nicht wiederholen.

Prüfergebnisse an den Support senden

Melden Sie sich in der Konsole an und eröffnen Sie ein Support-Ticket, um Fragen zu Instanzen und Bestellungen zu klären. Falls Sie sich nicht anmelden können, schreiben Sie an support@pushmac.comund nennen Sie die E-Mail-Adresse Ihres Kontos sowie den betroffenen Bereich.

Anmelden und Support-Ticket erstellen Cloud-Mac mieten