Dieser Leitfaden richtet sich an Entwickler, die Xcode oder macOS-CI auf einem exklusiven physischen Mac ausführen möchten. Prüfen Sie zuerst Modell und Standort, rufen Sie dann die Verbindungsdaten ab, kontrollieren Sie die Toolchain und starten Sie einen reproduzierbaren Build.
Befehle und Rückmeldungen auf dieser Seite sind Beispiele und belegen nicht, dass Ihr Projekt bereits eingerichtet wurde. Maßgeblich sind die in der Konsole angezeigten Verbindungsdaten, Gerätestatus und Fortschritte.
Prüfen Sie zuerst diese vier Punkte, bevor Sie Ihr Projekt auf einem Remote-Knoten ausführen.
Beispiel-Checkliste · Maßgeblich sind Auftrag und Konsole
Die fünf Einstiege folgen der Reihenfolge der Arbeitsschritte. Bei einem bestehenden Auftrag können Sie direkt zu Verbindung oder Fehlerbehebung wechseln.
Modell, Standort, Laufzeit und Auftragsstatus prüfen und herausfinden, wo Sie die Verbindungsdaten erhalten.
Ablauf ansehen → 02SSH-Parameter prüfen und zwischen Aufgaben auf der Kommandozeile und Arbeiten mit grafischer Oberfläche unterscheiden.
Verbindungsbeispiele ansehen → 03Projekt auschecken, Xcode und Abhängigkeiten prüfen und anschließend den Speicherort der Artefakte kontrollieren.
Build-Schritte ansehen → 04Runner-Identität, Job-Tags und Signaturberechtigungen prüfen, bevor Sie den automatisierten Build starten.
CI-Einrichtung prüfen → 05Laufzeit und Zusatzoptionen prüfen. Details und Supportanfragen zu bestehenden Aufträgen verwalten Sie in der Konsole.
Verwaltungsweg ansehen →Die Zeitangaben rechts zeigen nur, wie lange die einzelnen Schritte in einem Beispiel dauern – nicht die Lieferzeit. Lieferzeit und Status der Verbindungsdaten entnehmen Sie dem Auftrag und Gerätestatus in der Konsole.
Ca. 4 MinutenGesamtdauer der Beispielschritte, Wartezeit auf das Gerät nicht inbegriffen
Wählen Sie eine verfügbare Konfiguration passend zu Arbeitsspeicher- und Speicherbedarf Ihres Projekts. Berücksichtigen Sie bei der Standortwahl den Sitz Ihres Teams und die Zeitzone für die Zusammenarbeit. Prüfen Sie zuerst die verfügbaren Standorte und geben Sie dann Ihre Bestellung auf.
Prüfen Sie Laufzeit und optionale Zusatzleistungen und senden Sie dann die Bestellung ab. Verfügbarkeit und tatsächlich nutzbare Zahlungs-Gateways zeigt die Konsole in Echtzeit an.
Warten Sie, bis das Gerät als bereit angezeigt wird. Rufen Sie Adresse, Konto und Verbindungshinweise für Ihre Instanz in der Konsole ab. Übernehmen Sie keine Zugangsdaten aus öffentlichen Beispielen.
Stellen Sie eine Verbindung her und prüfen Sie das aktuelle Konto, den freien Speicherplatz und die Version der Xcode-Toolchain. Bei Abweichungen stoppen Sie automatisierte Aufgaben und dokumentieren die Ausgabe.
SSH eignet sich zum Auschecken von Code, Ausführen von Builds und Prüfen von Logs. Für die grafische Xcode-Oberfläche folgen Sie den Remote-Desktop-Anweisungen Ihrer Instanz.
$ ssh developer@192.0.2.10
Last login: example session
$ xcodebuild -version
Xcode
Build version: example
$ xcodebuild -workspace App.xcworkspace \
-scheme App -configuration Release \
-destination 'generic/platform=iOS' build
** BUILD SUCCEEDED **
$ fastlane build
[example] Build completed
[example] Artifact: ./build/App.ipaVom lokalen Mac zum Cloud-Mac: Stellen Sie zuerst sicher, dass Quellcode und Abhängigkeiten verfügbar sind. Prüfen Sie dann die Toolchain und richten Sie schließlich CI-Aufgaben auf den neuen Runner aus.
Checken Sie den Code möglichst aus dem Versionsverwaltungssystem aus und ermitteln Sie Konfigurationsdateien sowie Build-Ressourcen, die nicht eingecheckt sind. Erfassen Sie vertrauliche Daten vor der Übertragung und speichern Sie Zugangsdaten weder im Repository noch in Logs.
Abschlussprüfung: Die erwarteten Projektdateien sind im Cloud-Verzeichnis vorhanden und die Zugriffsrechte vertraulicher Dateien wurden geprüft.
Dokumentieren Sie die lokal verwendeten Versionen von Xcode, Kommandozeilen-Tools und Paketabhängigkeiten. Lösen Sie die Abhängigkeiten in der Cloud erneut auf und gleichen Sie sie mit den Mindestanforderungen des Projekts an Betriebssystem und Architektur ab.
Abschlussprüfung: Dasselbe Scheme startet einen Build über die Kommandozeile; Versionsabweichungen sind dokumentiert.
Richten Sie für den neuen Knoten eine eigene Runner-Identität und Job-Tags ein. Führen Sie zuerst einen Prüflauf ohne Veröffentlichungsschlüssel aus und kontrollieren Sie anschließend die für den Build erforderlichen Berechtigungen.
Abschlussprüfung: Der Testjob läuft auf dem vorgesehenen Knoten; Logs und Artefakte sind nachvollziehbar.
Führen Sie zunächst manuell einen vollständigen Build aus und bewahren Sie Versionen, Befehl und Fehlerausgabe auf. Entscheiden Sie erst danach, ob der Build automatisiert werden soll. Signatur- und Abhängigkeitsanforderungen müssen für jedes Projekt separat eingerichtet werden.
Rufen Sie das Repository auf einem vom Team freigegebenen Weg ab und prüfen Sie den Ziel-Commit, Submodule und Lock-Dateien. Führen Sie zuerst git statusaus, damit Sie das Build-Ergebnis nicht anhand unbekannter Änderungen beurteilen.
Legen Sie fest, wer Zertifikate, Provisioning-Profile und benötigte Schlüssel verwaltet und darauf zugreifen darf. Speichern Sie keine privaten Schlüssel in öffentlichen Repositories und fügen Sie keine vollständigen Zugangsdaten in Supportanfragen ein.
Prüfen Sie zuerst xcodebuild -version und das Scheme des Projekts. Führen Sie dann den tatsächlich im Projekt verwendeten Build-Befehl aus und dokumentieren Sie Exit-Code und ersten aussagekräftigen Fehler, statt nur das Ende des Logs zu erfassen.
Prüfen Sie Artefaktdateien, Größe und Speicherort und archivieren oder übertragen Sie sie nach dem Teamablauf. Eine Erfolgsmeldung ersetzt nicht die Prüfung der tatsächlichen Dateien und Signatur.
Für GitLab-CI-macOS-Runner installieren und registrieren Sie den Runner auf dem Knoten, verknüpfen ihn mit einem berechtigten Projekt und begrenzen mit Job-Tags, wo Aufträge ausgeführt werden. Registrierung, Zugriffsbereich und Parallelität richten sich nach den CI-Richtlinien Ihres Teams.
Ein erster Prüfjob kann lediglich System- und Xcode-Version ausgeben. Damit lässt sich bestätigen, dass der Job den vorgesehenen Apple-Silicon-Knoten erreicht hat. Signierung, Abhängigkeitsdownload und Veröffentlichung sind dadurch jedoch nicht automatisch geprüft.
fastlane kann Teil eines bestehenden Build-Prozesses sein, ersetzt aber nicht die Prüfung von Berechtigungen, Signierung und Versionen für Ihr Projekt.
Prüfen Sie vor der Bestellung das Modell, den Standort, die Laufzeit (Tag, Woche, Monat oder Quartal) und ob Sie eine SSD-Erweiterung oder Thunderbolt-5-Verbundbetrieb benötigen. Zusatzoptionen werden einzeln berechnet; maßgeblich sind Ihre Auswahl und der bestätigte Bestellbetrag.
Zahlung nur mit USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); abgerechnet wird stets in US-Dollar (USD). Welche Gateways verfügbar sind, zeigt die Konsole an.
Prüfen Sie in der Konsole Auftragskennung, Laufzeit, Standort, Zusatzoptionen und Gerätestatus. Bei Fragen zur Abrechnung eines bestehenden Auftrags melden Sie sich an und erstellen Sie ein Support-Ticket. Geben Sie Auftragskennung und die zu prüfenden Positionen an. Senden Sie keine Zahlungsdaten in öffentlichen Nachrichten.
Zur KonsoleNotieren Sie vor der Kontaktaufnahme den Zeitpunkt, die Auftragskennung der Instanz, den ausgeführten Vorgang und anonymisierte Fehlerinformationen. Senden Sie keine Passwörter, privaten Schlüssel, Signaturzertifikate oder ungeschwärzten Projektdaten.
Prüfen Sie zuerst Gerätestatus, Adresse und Konto in der Konsole und danach Ihr lokales Netzwerk und die verwendete Verbindungsmethode. Dokumentieren Sie Verbindungsbefehl, Fehlertyp und Zeitpunkt. Schwärzen Sie Zugangsdaten.
Dokumentieren Sie Commit-Version, Xcode-Version, Scheme, vollständigen Befehl und den ersten aussagekräftigen Fehler. Unterscheiden Sie zwischen Abruf von Abhängigkeiten, Kompilierung, Signierung und Export. Die letzte Zeile „Build fehlgeschlagen“ reicht nicht aus.
Prüfen Sie Projektverzeichnis, Build-Cache und Speicherbedarf der Artefakte. Klären Sie zuerst, welche Dateien Ihr Team gefahrlos löschen kann. Fügen Sie anonymisierte Speicherstatistiken und den Fehlerpfad bei, damit benötigte Artefakte nicht versehentlich gelöscht werden.
Prüfen Sie das aktuelle Ausführungskonto, Dateieigentümer und Berechtigungen für Repository oder Signaturmaterial. Dokumentieren Sie betroffene Pfade und Fehlermeldung. Umgehen Sie das Problem nicht, indem Sie die Berechtigungen aller Dateien erweitern.
Prüfen Sie die drei Modelloptionen und Laufzeiten und bestätigen Sie die aktuelle Verfügbarkeit in der Konsole. Beginnen Sie nach dem Verbinden mit einem reproduzierbaren Test-Build.