Von der Bestellung bis zum ersten Archiv

Verbinden Sie Ihren Cloud-Mac mit Ihrem Xcode-Build-Prozess

Dieser Leitfaden deckt Auswahl, Bestellung, Verbindung, Umgebungsinitialisierung, das erste Archive und die Einbindung eines CI-Runners ab. Arbeiten Sie die Schritte der Reihe nach durch: Bringen Sie zunächst eine reproduzierbare Release-Kette zum Laufen und ergänzen Sie danach Parallelisierung und Caching.

Cloud-Mac jetzt mieten Konfigurationen und Preise ansehen

3 Tarife: Feste Konfigurationen
4: Verfügbare Standorte
$20.7/Tag: Niedrigster Einstiegspreis

BUILD RUN SHEET Erstes iOS-Archiv

Ausführung vorbereiten

Code-Repository Dedizierter Knoten Archivartefakt

01
Tarif und Knoten bestätigenKonfiguration, Laufzeit, Standort und Speichererweiterung müssen übereinstimmen
02
Xcode-Umgebung initialisierenVersionen, Befehlszeilentools, Git und Paketmanager prüfen
03
Erstes Archive ausführenScheme, Signierung und Exportparameter festlegen
04
CI-Runner registrierenArbeitsverzeichnisse isolieren und Bereinigung nach dem Build einrichten

SG Singapur JP Tokio KR Seoul HK Hongkong

Schritt 01

Legen Sie vorab fünf Eingaben fest

Für die Auslieferungsgeschwindigkeit ist nicht entscheidend, wie viele Tools installiert sind, sondern ob Kontoberechtigungen, Repository-Zugriff, Xcode-Version, Knoten und Mietdauer vor der Bestellung geklärt sind.

Entwicklerberechtigungen

Stellen Sie sicher, dass das Apple-Developer-Konto über das richtige Team sowie die erforderlichen Berechtigungen für Zertifikate, Profile und Releases verfügt. Prüfen Sie den Signaturzugriff nicht erst nach dem Archive.

Repository-Zugriff

Bereiten Sie Zugangsdaten mit minimalen Rechten vor und prüfen Sie den Zugriff auf Haupt-Repository, private Abhängigkeiten, Submodule und Large-File-Speicher. CI-Zugangsdaten nicht mit persönlichen, langfristig verwendeten Zugangsdaten teilen.

Xcode-Version

Legen Sie die Projektanforderungen auf Haupt- und Build-Version genau fest und prüfen Sie die Kompatibilität von Swift, SDK und Befehlszeilentools. Die Runner-Version sollte feststehen; verlassen Sie sich nicht auf spontane Wechsel.

Knotenstandort

Wählen Sie zwischen Singapur, Tokio, Seoul und Hongkong bevorzugt den Standort nahe den wichtigsten Entwicklern, dem Code-Repository und den Bezugsquellen der Abhängigkeiten. Prüfen Sie die Wahl anschließend mit einer echten Verbindung.

Mietdauer

Für vorübergehende Signaturtests können Sie mit Tages- oder Wochenmieten beginnen; laufende Entwicklung und feste Runner eignen sich besser für Monats- oder Quartalsmieten. Wählen Sie anhand des realen Build-Plans und nicht anhand einer geschätzten Auslastung.

Schritt 02

Wählen Sie nach der Last – nicht nach dem Projektnamen

Alle drei Tarife bieten dedizierte physische Apple-Silicon-Mac-Knoten statt virtueller Maschinen. Entscheidend sind Anzahl paralleler Aufgaben, Umfang der Abhängigkeiten, Cache-Größe und Bedarf an Unified Memory.

Leichte Builds

Go M4 Core

Geeignet für Einzelprojekt-Validierung, temporäre Signierung, Xcode-Builds mit geringer Parallelität und kurzfristige Aufgaben in einer dedizierten Umgebung.

Chip: M4
Arbeitsspeicher: 16GB
Speicher: 256GB

Go M4 Core auswählen

Tägliche Entwicklung

Go M4 Plus

Geeignet für mehrere laufende Projekte, die Installation von React-Native- oder Flutter-Abhängigkeiten sowie CI-Warteschlangen mit moderater Parallelität.

Chip: M4
Arbeitsspeicher: 24GB
Speicher: 512GB

Go M4 Plus auswählen

Hohe Speicherlast

Go M4 Pro

Geeignet für Builds mit hoher Parallelität, große Abhängigkeits-Caches und KI-Inferenzexperimente mit höherem Bedarf an Unified Memory und lokalem Speicher.

Chip: M4 Pro
Arbeitsspeicher: 64GB
Speicher: 2TB

Go M4 Pro auswählen

Schritt 03

Bestätigen Sie beim Erstellen der Bestellung vier Parametergruppen

Der Konfigurator fasst Host, Laufzeit, Knoten und Zusatzoptionen in einer Bestellung zusammen. Prüfen Sie vor dem Absenden jede Zeile, damit Sie Daten nicht nach der Bereitstellung migrieren müssen.

Bestellparameter-Checkliste Vor dem Absenden prüfen

HOST

Eine der drei Hauptkonfigurationen auswählen

Chip, Arbeitsspeicher und Systemlaufwerk entsprechen den Angaben auf der Konfigurationskarte.

TERM

Tag, Woche, Monat oder Quartal auswählen

Die Laufzeit der Zusatzoptionen muss der Host-Laufzeit entsprechen.

NODE

Einen der vier verfügbaren Knoten auswählen

Singapur, Tokio, Seoul und Hongkong können im Konfigurator ausgewählt werden.

ADD

Erweiterungen nach Bedarf hinzufügen

+1TB SSD, +2TB SSD oder Thunderbolt 5 können pro Gerät hinzugefügt werden.

Knotenauswahl

Richten Sie sich zuerst nach dem wichtigsten Workflow

Die Remote-Desktop-Erfahrung hängt stärker von der Verbindung der Entwickler zum Knoten ab; die Geschwindigkeit beim Abruf von Abhängigkeiten wird zudem durch den Standort von Repository und Downloadquellen beeinflusst. Wählen Sie zunächst einen möglichen Knoten und testen Sie ihn mit einem echten Projekt.

Informationen zu den Knoten ansehen

Verfügbarkeitsinformationen

Maßgeblich ist die Live-Antwort der Konsole

Alle Kombinationen im Verzeichnis können bestellt werden. Der tatsächliche Status beim Erstellen der Bestellung wird live von der Konsole zurückgegeben. Leiten Sie den aktuellen Status nicht aus Screenshots ab.

Bestellung konfigurieren

Schritt 04

Erst über die grafische Oberfläche prüfen, dann automatisieren

Prüfen Sie nach Erhalt der Zugangsdaten zunächst per VNC Desktop, Tastatur, Netzwerk und Systemstatus. Sobald die Basisumgebung funktioniert, führen Sie Skripte und Runner-Aufgaben per SSH aus.

Verbindung 01

Desktop per VNC abnehmen

Prüfen Sie Auflösung, Tastaturlayout, Zwischenablage, Zeitzone und Netzwerkzugriff. Ändern Sie bei der ersten Abnahme nicht gleichzeitig viele Systemeinstellungen, damit sich Fehler leichter eingrenzen lassen.

Knotenadresse und Verbindungszeit protokollieren
Dauerhafte Nutzung der Desktopsitzung bestätigen
Grundlegende Downloads und Repository-Zugriff prüfen

Verbindung 02

Wiederkehrende Aufgaben per SSH ausführen

Schreiben Sie Codeabruf, Abhängigkeitsinstallation, Cache-Bereinigung und Builds in reproduzierbare Skripte. Zugangsdaten müssen minimale Rechte besitzen und getrennt von Logs und Buildartefakten gespeichert werden.

Zugriff der Schlüssel auf die erforderlichen Projekte begrenzen
Skripteinstieg und Arbeitsverzeichnis festlegen
Exit-Codes und Logs fehlgeschlagener Befehle aufbewahren

Schritt 05

Richten Sie die Entwicklungsumgebung reproduzierbar ein

Prüfen Sie zuerst System und Xcode und installieren Sie danach die Projektools. Halten Sie bei jedem Schritt die Versionsausgabe fest, damit der Runner Unterschiede später dem Code oder dem Host zuordnen kann.

Befehle zur Umgebungsprüfung ENV-CHECK

$ sw_vers macOS-Version bestätigen

$ xcodebuild -version Xcode- und Build-Version bestätigen

$ xcode-select -p Pfad der Befehlszeilentools bestätigen

$ git --version Git-Verfügbarkeit bestätigen

$ fastlane --version Version der Automatisierungstools bestätigen

01
Systemkonto prüfen
Bestätigen Sie aktuellen Benutzer, Home-Verzeichnis, Administratorrechte und Einhängepunkte. Projektverzeichnisse sollten nicht über Desktop oder temporäre Downloadordner verteilt sein.
02
Xcode erstmals starten
Öffnen Sie das gewünschte Xcode, installieren Sie erforderliche Komponenten und stellen Sie sicher, dass die Befehlszeilentools auf dieselbe Version zeigen.
03
Projektabhängigkeiten installieren
Installieren Sie Paketmanager und Abhängigkeiten anhand der Lockfiles des Projekts. Aktualisieren Sie beim ersten Build nicht blind gesperrte Versionen.
04
Fastlane und Skripteinstieg festlegen
Verwenden Sie versionsgebundene Vorgaben im Projekt und teilen Sie Build, Tests, Archive und Verteilung in unabhängig wiederholbare Aufgaben auf.

Schritt 06

Beim ersten Xcode-Cloud-Build nur die Hauptkette validieren

Im ersten Durchlauf geht es nicht um maximale Geschwindigkeit, sondern um ein überprüfbares Artefakt aus einem sauberen Verzeichnis. Fixieren Sie Repository-Version, Scheme, Signierung und Exportmethode und optimieren Sie Caches erst danach.

Eine bestimmte Version abrufen

Verwenden Sie einen eindeutigen Branch, Tag oder Commit. Synchronisieren Sie Submodule und Dependency-Lockfiles und protokollieren Sie den zugehörigen Commit.

Scheme bestätigen

Führen Sie zuerst xcodebuild -list aus, um verfügbare Schemes zu prüfen. Stellen Sie sicher, dass das gewünschte Scheme geteilt und für Builds über die Befehlszeile geeignet ist.

Signaturmaterial prüfen

Prüfen Sie Zertifikate, Profile, Bundle Identifier und Team-Berechtigungen. Signaturpasswörter dürfen nicht im Repository oder in gewöhnlichen Build-Logs stehen.

Archive ausführen

Legen Sie Workspace oder Project, Scheme, Configuration und Archivpfad eindeutig fest. Bewahren Sie bei Fehlern vollständigen Exit-Code und Logs auf.

Exportartefakt validieren

Prüfen Sie Artefaktname, Versionsnummer, Build-Nummer, Signierung und Dateigröße und stellen Sie sicher, dass die TestFlight-Verteilung die Datei empfangen kann.

Erfolgskriterium Derselbe Commit erzeugt mit demselben Befehl erneut ein gültiges Archiv

Noch nicht optimieren Parallelität, Cache-Trefferrate und Geschwindigkeit inkrementeller Builds

Schritt 07

Den self-hosted Runner kontrolliert mit Builds beauftragen

Registrieren Sie den Runner erst nach einem erfolgreichen ersten Archive. Entscheidend sind nicht bloß Online-Status, sondern isolierte Arbeitsverzeichnisse, klare Labels, begrenzte Projektberechtigungen und Wiederherstellbarkeit nach jeder Aufgabe.

Arbeitsverzeichnis

Jeder Runner verwendet einen eigenen Pfad

Verwalten Sie Quellcode, DerivedData, Dependency-Cache und Exportartefakte in getrennten Verzeichnissen. Mehrere parallele Aufgaben dürfen nicht in denselben Archivpfad schreiben.

Label-Design

Labels beschreiben Fähigkeiten, keine temporären Aufgaben

Labels können Region, Xcode-Hauptversion und Laststufe angeben. Verwenden Sie in dauerhaften Labels weder Projekt- oder Personennamen noch kurzfristige Branches.

Zugriffsbereich

Nur benötigte Projekte autorisieren

Begrenzen Sie den Zugriff des Runners auf erforderliche Repositorys und Variablen. Produktionssignierung und Rechte für Test-Builds sollten nach Workflow getrennt werden.

Bereinigungsregeln

Sensible Reste nach jeder Aufgabe löschen

Löschen Sie temporäre Zugangsdaten, Exportkonfigurationen und nicht mehr benötigte Artefakte. Verwalten Sie Caches nach Verzeichnis, Größe und Änderungszeit statt pauschal alles zu löschen.

Schritt 08

Letzte Übergabeprüfung vor dem Start abschließen

Nehmen Sie die folgenden Punkte in das Betriebshandbuch Ihres Teams auf. Erst nach erfolgreicher Prüfung sollte der Runner kontinuierliche Builds und TestFlight-Verteilung übernehmen.

Zertifikate und Profile

Gültigkeit, Teamzugehörigkeit, Bundle Identifier und Nutzungsumfang prüfen und die zuständige Person für Aktualisierungen dokumentieren.

Freier Speicherplatz

Belegung durch Quellcode, DerivedData, Dependency-Cache, Archive und Exportartefakte prüfen und ausreichend Platz für aufeinanderfolgende Builds reservieren.

Cache-Strategie

Festlegen, welche Verzeichnisse wiederverwendet werden dürfen, wann sie ungültig werden, welche Kapazitätsgrenzen gelten und wann bereinigt wird. Signaturpasswörter und temporäre Tokens nicht cachen.

TestFlight-Kette

Den gesamten Ablauf vom Archivexport bis zum Upload einmal Ende zu Ende prüfen und die Zuordnung von Versionsnummer, Build-Nummer und Release-Log bestätigen.

Bereinigung sensibler Informationen

Repository, Umgebungsdateien, Befehlsverlauf und Build-Logs prüfen und Schlüssel, Tokens sowie Signaturpasswörter löschen, die nicht dauerhaft aufbewahrt werden sollen.

Eskalationsweg bei Fehlern

Bestellnummer, Knoten, Reproduktionszeit, Fehler-Logs und bereits ausgeführte Schritte dokumentieren. Wenn Sie Hilfe benötigen, reichen Sie über die Konsole ein Ticket ein.

READY Erster Build reproduzierbar, Runner-Zugriff kontrolliert, sensible Informationen bereinigt

Ticket über die Konsole einreichen

Bereit? Beginnen Sie mit einem dedizierten Knoten

Wählen Sie Konfiguration, Laufzeit und Knoten, führen Sie zunächst das erste Xcode-Archiv erfolgreich aus und binden Sie anschließend den stabilen Befehl in die CI-Warteschlange ein.

Cloud-Mac jetzt mieten Drei Tarife vergleichen