Xcode-Cloud-Builds: Mac mieten

Vier Übergabeschritte bis zu den Mac-Zugangsdaten

Für Registrierung, Konfiguration, Zahlung und Zuweisung jeweils etwa 1 Minute einplanen – im Idealfall ist die Bereitstellung in rund 4 Minuten abgeschlossen. Das ist eine Orientierung für den Ablauf, keine feste Lieferfrist. Maßgeblich sind der E-Mail-Eingang, die Zahlungsbestätigung und der Fortschritt in der Konsole.

Registrieren und Konsole öffnen
ca. 1 Minute
Verwenden Sie ein Team-Postfach, das Bestätigungscodes empfangen kann. Folgen Sie den Anweisungen auf der Seite und legen Sie ein Passwort fest. Nutzen Sie eine dauerhaft betreute Adresse, damit Ihr Team Bestellungen, Verlängerungen und Support-Tickets im Blick behält. Bestätigungscodes gehören nicht in öffentliche Build-Logs.
Modell, Laufzeit und Standort wählen
ca. 1 Minute
Wählen Sie Push M4 S oder Push M4 L sowie Abrechnungszeitraum und Standort. Für die tägliche CI eines einzelnen Apps ist zunächst die 16-GB-Variante zu prüfen; bei parallelen Archives mehrerer Targets kommt die 24-GB-Variante infrage. Die aktuelle Verfügbarkeit sehen Sie in der Konsole.
In US-Dollar bezahlen
ca. 1 Minute
Zahlen Sie mit USDT-TRC20 oder Visa, Mastercard bzw. Amex über Stripe. Welche Zahlungswege verfügbar sind, zeigt die Checkout-Seite. Bei einer Überweisung auf der Blockchain prüfen Sie Netzwerk, Adresse und Betrag und warten Sie auf die Bestätigung in der Konsole. Eine eingeleitete Zahlung bedeutet noch nicht, dass der Mac bereitgestellt ist.
Mac und Verbindungsdaten erhalten
ca. 1 Minute
Nach der Zuweisung des Macs prüfen Sie in der Bestellung oder den Instanzdetails Standort, Verbindungsadresse, Port und Anmeldenamen und rufen die SSH-/VNC-Zugangsdaten ab. Für spätere Support-Tickets genügt die Bestellnummer – weder Passwort noch privater Schlüssel werden benötigt.

Interaktive Arbeit nahe am Team, Builds nahe an den Abhängigkeiten

Alle fünf Standorte bieten zwei Tarife mit exklusiven physischen Macs. Grenzen Sie die Auswahl zuerst anhand der Standorte Ihrer Build-Verantwortlichen ein. Prüfen Sie dann die Übertragungswege zwischen Repository, Paketquellen und Artefaktspeicher. Eine passende Zeitzone bedeutet nicht automatisch geringe Netzwerklatenz. Testen Sie VNC und Abhängigkeits-Downloads getrennt.

Singapur

Eine gute Option, wenn die meisten Teammitglieder in Südostasien sitzen. Testen Sie sowohl die übliche Remoteverbindung als auch Downloads von Abhängigkeiten.

Zeitzone für die Zusammenarbeit: UTC+8

Tokio

Für Teams, die überwiegend nach japanischen Arbeitstagen arbeiten, ein guter erster Kandidat. Verwenden Sie feste Runner-Labels, damit Jobs nicht versehentlich auf einem anderen Standort landen.

Zeitzone für die Zusammenarbeit: UTC+9

Seoul

Eine Option, wenn Teammitglieder in Korea häufig am Schreibtisch arbeiten. Prüfen Sie die Reaktionszeit der grafischen Oberfläche über das tatsächliche Büronetzwerk.

Zeitzone für die Zusammenarbeit: UTC+9

Hongkong

Prüfen Sie den Standort für Verbindungen aus Südchina und Südostasien. Nutzen Sie den Remote-Desktop für interaktive Arbeit und SSH für die Kommandozeile; Logs bleiben im Build-System.

Zeitzone für die Zusammenarbeit: UTC+8

US-Ostküste

Eine gute Option, wenn tagsüber in Nordamerika interaktive Arbeit gefragt ist. Halten Sie für standortübergreifende Übergaben alle Aufgabenzeiten in UTC fest.

Zeitzone für die Zusammenarbeit: UTC−5 / UTC−4

An der US-Ostküste gilt eine saisonale Zeitverschiebung. Wenn an beiden Standorten häufig interaktiv gearbeitet wird, können Sie Macs in der Nähe der jeweiligen Teams mieten und Aufgaben über eine CI-Warteschlange koordinieren. Auch bei einem exklusiv genutzten Mac müssen parallele, rechenintensive Jobs begrenzt werden.

Erst SSH testen, dann den macOS-Schreibtisch öffnen

Verbindungsadresse, Port und Benutzername entnehmen Sie der Konsole – verwenden Sie keine Zugangsdaten aus einer anderen Bestellung. Die Befehle unten fragen die aktuellen Werte ab. Vergewissern Sie sich vorher, dass auf Ihrem Rechner ein SSH-Client verfügbar ist.

SSH: Kommandozeilenzugang prüfen

Führen Sie den Befehl im lokalen Terminal aus. Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerabdruck. Wenn die Konsole keine Angaben zur Überprüfung bereitstellt, fragen Sie erst über ein Support-Ticket nach, statt die Prüfung der Host-Identität zu überspringen.

printf 'Verbindungsadresse: '
read -r MAC_HOST
printf 'SSH-Port: '
read -r MAC_PORT
printf 'Benutzername: '
read -r MAC_USER
ssh -p "$MAC_PORT" "$MAC_USER@$MAC_HOST"

Führen Sie nach der Anmeldung whoami und sw_versaus, um Benutzer und Systeminformationen zu prüfen. Wenn Sie später SSH-Schlüssel einrichten, laden Sie nur den öffentlichen Schlüssel hoch. Der private Schlüssel bleibt auf Ihrem Gerät oder in der Schlüsselverwaltung Ihres CI.

VNC: Desktop-Zugang prüfen

Melden Sie sich in der Konsole an und öffnen Sie die Verbindungsdaten der bereitgestellten Instanz.
Stellen Sie die Remoteverbindung mit der für die Instanz angegebenen Methode her und prüfen Sie Adresse und Authentifizierungsdaten.
Prüfen Sie unter macOS Tastatur, Anzeige und Netzwerk und legen Sie das VNC-Passwort gemäß den Teamvorgaben fest.
Schließen Sie die Hinweise beim ersten Start von Xcode ab und erteilen Sie die erforderlichen Schlüsselbundberechtigungen. Führen Sie den Build anschließend wieder über SSH aus.

Nutzen Sie den Desktop für Berechtigungen in der grafischen Oberfläche und die Kommandozeile für reproduzierbare Skripte. Prüfen Sie bei Zeitüberschreitungen zuerst Port, Instanzstatus und lokales Netzwerk und erstellen Sie dann ein Support-Ticket. Wiederholtes Ändern des Passworts ist keine Netzwerkdiagnose.

Ein reproduzierbares Archive als Build-Nachweis

Der erste Build umfasst vier Prüfungen: Toolchain, Projekt, Codesignierung und Export. Die Befehle eignen sich für iOS-Projekte mit Workspace. Bei einem Projekt ohne Workspace ersetzen Sie -workspace durch -projectund verwenden den tatsächlichen Dateinamen Ihres Projekts.

Aktuelle Toolchain prüfen

Prüfen Sie zuerst, welches Xcode das System tatsächlich verwendet – nicht nur, welche Versionen im Programme-Ordner liegen. Sind mehrere Versionen installiert, wählen Sie den für das Projekt vorgesehenen Anwendungspfad und prüfen Sie anschließend Version und SDK erneut.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer

Repository klonen und Shared Scheme finden

Geben Sie die Adresse eines Repositories ein, auf das Sie Lesezugriff haben. Authentifizieren Sie sich per SSH-Schlüssel oder über eine sichere Anmeldedatenverwaltung – Zugriffstoken gehören nicht in Befehle. Bereiten Sie zuerst die Abhängigkeiten wie im Projekt vorgesehen vor und listen Sie anschließend Workspace und Scheme auf.

printf 'Repository-Adresse: '
read -r REPOSITORY_URL
git clone "$REPOSITORY_URL" app
cd app
git rev-parse HEAD
find . -name '*.xcworkspace' -prune
xcodebuild -list -workspace MyApp.xcworkspace

Arbeitsverzeichnis festlegen und Archive erstellen

Ersetzen Sie MyApp.xcworkspace und MyApp durch die zuvor ermittelten tatsächlichen Namen. Für Builds mit Gerätesignierung importieren Sie zuerst sicher das passende Zertifikat und Provisioning Profile. Stellen Sie außerdem sicher, dass der Build-Prozess auf den Schlüsselbund zugreifen kann.

mkdir -p build
xcodebuild \
  -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -derivedDataPath build/DerivedData \
  -archivePath build/MyApp.xcarchive \
  archive

Build-Artefakte mit der Exportkonfiguration des Projekts erstellen

ExportOptions.plist muss der festgelegten Signierungs- und Distributionskonfiguration des Projekts entsprechen und darf nicht aus einem anderen Team übernommen werden. Ein erfolgreiches Archive bedeutet nicht, dass auch der Export funktioniert hat. Erfassen Sie Exit-Status und Logs für beide Schritte separat.

xcodebuild -exportArchive \
  -archivePath build/MyApp.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist ExportOptions.plist

test -d build/MyApp.xcarchive
find build/export -maxdepth 1 -type f -print

Vier Angaben für die Übergabe – keine Schlüssel

Notieren Sie Commit-SHA, Xcode-Version, tatsächlich verwendetes Scheme und Artefaktpfad. Prüfen Sie bei einem Fehlschlag zuerst die erste Fehlermeldung: Bei Problemen mit Abhängigkeiten kontrollieren Sie Netzwerk und Versionssperren, bei Signierungsfehlern Zertifikat und Provisioning Profile, bei Exportfehlern die Exportkonfiguration. Ändern Sie bei einem erneuten Versuch nicht gleichzeitig Standort, Toolchain und Signierungseinstellungen.

Geprüfte Befehle an den CI-Dienst übergeben

Führen Sie den Ablauf zuerst manuell unter demselben Build-Benutzer aus und registrieren Sie danach einen selbst gehosteten Runner. Der Dauerbetrieb sichert Stromversorgung und Hosting des Macs – ob der Runner-Prozess automatisch startet, Zertifikate gültig sind und Jobs in der Warteschlange hängen, muss Ihr Team weiterhin konfigurieren und prüfen.

Runner registrieren und Jobs gezielt zuweisen

Rufen Sie die Installationsanweisungen für einen macOS-ARM64-Runner in den Projekt- oder Organisationseinstellungen Ihrer CI-Plattform ab. Verwenden Sie die Registrierungsdaten des aktuellen Projekts und keine abgelaufenen Tokens. Die Labels sollten Standort, Architektur und Einsatzzweck abbilden.

GitHub Actions: Erzeugen Sie unter Self-hosted runners die Registrierungsanweisungen und prüfen Sie den Berechtigungsumfang des Repositories.
GitLab Runner: Registrieren Sie den Runner mit der für das Projekt angegebenen Adresse und dem zugehörigen Token. Wählen Sie für Jobs mit Xcode eine passende Ausführungsart.
Erlauben Sie nur vertrauenswürdigen Pipelines den Zugriff auf Signierungsressourcen. Führen Sie ungeprüften Code nicht direkt auf einem Mac mit hinterlegten Schlüsseln aus.

Starten Sie beim ersten Einsatz nur einen Build-Job. Beobachten Sie Speicher, Festplatte und Laufzeit, bevor Sie die Parallelität erhöhen. Starten Sie nicht allein deshalb alle Archives gleichzeitig, weil der Mac exklusiv genutzt wird.

Autostart einrichten und Hintergrunddienst prüfen

Nach dem Entpacken und Registrieren des GitHub-Actions-Runners können Sie im Installationsverzeichnis das mitgelieferte Dienstskript verwenden. Diese Befehle laden den Runner weder herunter noch registrieren sie ihn. Schließen Sie zuerst den vorherigen Schritt gemäß den Anweisungen der CI-Plattform ab.

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

Prüfen Sie, ob das Dienstskript den laufenden Status meldet und der Runner in der CI-Plattform online erscheint. Ein LaunchAgent hängt in der Regel von der angemeldeten Sitzung des Benutzers ab. Für einen unbeaufsichtigten Start konfigurieren und testen Sie den Runner nach den offiziell unterstützten Verfahren. Ein installierter Dienst ist keine Garantie dafür, dass nach einem Neustart Builds ausgeführt werden können.

Abschlusstest: Builds auch ohne offenes Terminal

Schließen Sie das Terminal, in dem Sie den Runner manuell gestartet haben, und starten Sie einen kontrollierten Job in der CI. Prüfen Sie Benutzer, ausgewähltes Xcode, Schlüsselbundzugriff, Cache-Verzeichnisse und Artefakt-Upload. Testen Sie bei Macs für unbeaufsichtigte Builds zusätzlich den Runner-Status nach der Wiederherstellung. Vergewissern Sie sich vor einem Neustart, dass keine anderen Jobs laufen.

Auf exklusiv genutzten Macs können DerivedData und Abhängigkeits-Caches erhalten bleiben. Unterscheiden Sie Cache-Schlüssel mindestens nach Toolchain, Abhängigkeitssperrdatei und Build-Konfiguration. Legen Sie Aufräumregeln fest, damit Caches und Artefakte die Systemfestplatte nicht füllen.

Beim nächsten Push auf diesen Build-Nachweis zurückgreifen

Sobald Verbindung und erster Build geprüft sind, halten Sie Standort, Toolchain und Build-Befehl in der Teamdokumentation fest. Details zum Versionswechsel und Caching finden Sie im Leitfaden; für mehr Build-Kapazität prüfen Sie die verfügbaren Tarife.

Anleitung ansehen Mac-Tarife wählen

Einen Code-Pushdirekt auf den Mac im Rechenzentrum bringen