Der gesamte physische Mac steht Ihrem Team zur Verfügung. Prüfen Sie zuerst die Verbindung, legen Sie dann die Toolchain fest und registrieren Sie anschließend den Runner. Mit dieser Checkliste planen Sie die ersten 30 Minuten. Wie lange das Herunterladen von Projektabhängigkeiten und ein vollständiger Build dauern, hängt von Ihrem Projekt ab.
Noch keinen Server gemietet? Apple Silicon M4 / M4 Pro, exklusiv für Ihr Team, kein virtueller Mac – ab $20.1 pro Tag.
Bevor Sie Automatisierungsaufgaben registrieren, stellen Sie sicher, dass eine grafische Verbindung funktioniert, und testen Sie anschließend SSH. Deaktivieren Sie die Passwortanmeldung nicht, bevor Sie die alternative Verbindung geprüft haben.
Melden Sie sich im Kundenportal an, öffnen Sie die Details der betreffenden Instanz und prüfen Sie Kennung, Adresse, Benutzername und Verbindungshinweise. Die Zugangsdaten sind nur in Ihrem Konto einsehbar. Kopieren Sie sie nicht in Support-Tickets, Pipeline-Konfigurationen oder Quellcode-Repositories.
Öffnen Sie den Browser-Remote-Desktop über die Instanzdetails und vergewissern Sie sich, dass die macOS-Umgebung dieser Instanz angezeigt wird. Ändern Sie nach dem ersten Login das Passwort des Systembenutzers und speichern Sie es im Passwortmanager Ihres Teams. Legen Sie außerdem fest, wer für Verlängerungen und den Wechsel der Zugangsdaten zuständig ist.
Prüfen Sie unter „Allgemein“ und „Freigaben“ in den macOS-Systemeinstellungen die Option „Entfernte Anmeldung“ und beschränken Sie den Zugriff auf die benötigten Benutzer. Verwenden Sie für die Verbindung die Adresse und den Port aus dem Kundenportal. Weicht der Port vom Standard ab, geben Sie ihn ausdrücklich im ssh-Befehl an.
Erstellen Sie auf Ihrem Arbeitsrechner einen eigenen SSH-Schlüssel und fügen Sie nur den öffentlichen Schlüssel zu authorized_keys auf dem Mac hinzu. Lassen Sie die aktuelle Sitzung geöffnet, testen Sie die Anmeldung mit Schlüssel in einem zweiten Terminal und passen Sie erst danach weitere Authentifizierungseinstellungen an.
Berechtigungen auf dem Mac prüfen
mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
whoami
sw_vers
uname -mErwartetes Ergebnis: Der Benutzername stimmt mit den Zugangsdaten der Instanz überein und die macOS-Version erfüllt die Projektanforderungen. Auf Apple Silicon sollte die Architektur als arm64 ausgegeben werden. Prüfen Sie beim ersten SSH-Verbindungsaufbau den Host-Fingerabdruck, bevor Sie ihn bestätigen. Deaktivieren Sie die Hostschlüsselprüfung nicht, um die Verbindung zu erzwingen.
Die folgende Ausgabe dient nur als Beispiel und stammt nicht von Ihrer Instanz. Das Beispielprojekt heißt TeamApp. Ersetzen Sie Workspace, Scheme und Signierungseinstellungen durch die Werte Ihres Repositorys.
$ ssh "$NODE_USER@$NODE_ADDRESS"
Authenticated using "publickey".
$ uname -m
arm64
$ xcodebuild -workspace TeamApp.xcworkspace \
-scheme TeamApp -configuration Release \
-destination 'generic/platform=iOS' \
-archivePath build/TeamApp.xcarchive archive
** ARCHIVE SUCCEEDED **
$ bundle exec fastlane gym --scheme TeamApp
Successfully exported and compressed dSYM file
Successfully exported and compressed ipa file
Successfully generated ipa file:
build/TeamApp.ipaPrüfen Sie nach erfolgreicher SSH-Verbindung auch Ruby, Bundler und die Projektabhängigkeiten. Verwenden Sie nach Möglichkeit die im Repository festgelegten Versionen, statt mit einem globalen Upgrade-Befehl die Build-Umgebung des ganzen Teams zu verändern.
Prüfpunkt: Derselbe Benutzer kann das Repository öffnen und die Abhängigkeiten installieren.
Wenn das Archiv erstellt wird, der IPA-Export aber fehlschlägt, prüfen Sie zuerst die Exportoptionen, das Signierzertifikat und das Provisioning-Profil. Sichern Sie den ersten Fehler samt Kontext und nicht nur die letzte Fehlermeldung.
Prüfpunkt: Im Zielpfad liegt ein Build-Artefakt für nachfolgende Aufgaben.
Der Mac ist exklusiv Ihrem Team zugeordnet. Wie viele Builds parallel laufen können, hängt dennoch von Arbeitsspeicher, Speicherplatz und der Isolierung der Jobs ab. Testen Sie zunächst die gesamte Pipeline mit einem Build und erhöhen Sie erst danach die Parallelität.
Fügen Sie in den Actions-Einstellungen Ihres Repositorys oder Ihrer Organisation einen self-hosted runner hinzu und wählen Sie macOS und ARM64 aus. Führen Sie die dort aktuell bereitgestellten Befehle zum Herunterladen, Prüfen und Registrieren aus. Verwenden Sie keine Installationspakete aus unbekannten Quellen.
Registrieren Sie den Runner mit einem eigens dafür vorgesehenen Systembenutzer und vergeben Sie Labels wie vmfly und ios-build. Richten Sie runs-on im Workflow auf die passenden Labels aus, damit Jobs nicht länger in einer gemeinsam genutzten Ausführungsumgebung landen.
runs-on: [self-hosted, macOS, ARM64, vmfly, ios-build]Prüfpunkt: Der Runner wird in der Verwaltungsoberfläche als online angezeigt und nimmt manuell gestartete Jobs an.
Verwenden Sie eine Runner-Version, die mit Ihrer GitLab-Umgebung kompatibel ist, und erstellen Sie den Runner nach dem Ablauf für Ihr Projekt oder Ihre Gruppe. Verwenden Sie unter macOS den Shell-Executor und versehen Sie den Mac mit dem Label macos-arm64 sowie passenden Labels für den Einsatzzweck.
Geben Sie in den Pipeline-Jobs dieselben Tags an. Stellen Sie sicher, dass das Arbeitsverzeichnis dem ausführenden Benutzer gehört. Auch auf Zertifikate, Abhängigkeits-Caches und Build-Ausgaben sollte derselbe Benutzer zugreifen können. So vermeiden Sie, dass Befehle im interaktiven Terminal funktionieren, automatisierte Jobs aber fehlschlagen.
ios_archive:
tags:
- macos-arm64
- ios-build
script:
- bundle exec fastlane gymPrüfpunkt: Ein Testjob gibt die Systemarchitektur aus und kann auf die benötigte Toolchain zugreifen.
Für einen GitHub Runner können Sie im Registrierungsverzeichnis das Serviceskript mit ./svc.sh install und ./svc.sh start ausführen. Bei einem GitLab Runner verwenden Sie je nach Installationsart gitlab-runner install und gitlab-runner start. Richten Sie für denselben Runner nicht mehrere Autostart-Mechanismen ein.
Dienste, die unter macOS als LaunchAgent eines Benutzers laufen, hängen in der Regel von dessen angemeldeter Sitzung ab. Prüfen Sie die tatsächlich erzeugte Dienstkonfiguration und den ausführenden Benutzer. Ein gestarteter Mac bedeutet nicht automatisch, dass der Build-Benutzer angemeldet ist. Testen Sie nach einem Neustart, ob der Runner online geht, Pfade stimmen, der Schlüsselbund verfügbar ist und Artefakte exportiert werden können – am besten außerhalb eines Release-Laufs.
Übertragen Sie Build-Zertifikate und Provisioning-Profile ausschließlich über einen vom Team genehmigten sicheren Weg. Ein Zertifikat muss den zugehörigen privaten Schlüssel enthalten; ein öffentliches Zertifikat allein reicht zum Signieren nicht aus. Hinterlegen Sie Entsperrpasswörter und Automatisierungstoken in geschützten CI-Variablen und beschränken Sie den Zugriff auf die erforderlichen Branches und Jobs.
Teams, die fastlane match nutzen, sollten die bestehende Speicher- und Zugriffsrichtlinie beibehalten. Wenn CI bereits vorhandenes Signiermaterial abruft, verwenden Sie nach Möglichkeit den schreibgeschützten Modus. Prüfen Sie Bundle Identifier, Team, Exportoptionen und Gültigkeit des Provisioning-Profils, bevor Sie den Archivierungsbefehl selbst untersuchen.
Unbeaufsichtigte Jobs müssen auf den vorgesehenen Schlüsselbund zugreifen können. Schreiben Sie dauerhafte Klartextpasswörter nicht in Skripte und geben Sie nicht sämtliche Umgebungsvariablen im Log aus. Entfernen Sie vor dem Teilen von Logs private Schlüssel, Token, Passwörter und Inhalte von Signiermaterial.
Prüfen Sie zuerst die aktuelle Umgebung des Macs und installieren Sie nur dann die benötigte Version. Gehen Sie nicht davon aus, dass der im Desktop ausgewählte Xcode auch vom Runner verwendet wird.
Aktuelle Auswahl prüfen; zum Wechseln den tatsächlichen Installationspfad einsetzen
xcodebuild -version
xcode-select -p
xcrun simctl list runtimes
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -checkFirstLaunchStatusVergeben Sie den Xcode-Apps eindeutige Dateinamen. Wenn Projekte auf einem gemeinsam genutzten Mac unterschiedliche Versionen benötigen, setzen Sie vorzugsweise DEVELOPER_DIR im jeweiligen Job, statt bei jedem Build die globale Systemauswahl zu ändern.
Prüfpunkt: Die Ausgabe von xcodebuild -version im tatsächlichen Runner-Job entspricht den Projektanforderungen.
Installieren Sie in den Xcode-Einstellungen die für das Projekt benötigten Runtimes und prüfen Sie anschließend mit xcrun simctl list, welche Geräte verfügbar sind. Legen Sie für UI-Tests das Zielgerät ausdrücklich fest, damit Jobs nicht auf eine nicht installierte Betriebssystemversion oder ein fehlendes Gerät warten.
Prüfpunkt: Starten Sie den Zielsimulator separat, bevor Sie eine kleine Gruppe von UI-Tests ausführen.
Legen Sie für jedes Projekt einen eigenen DerivedData-Pfad fest, behalten Sie benötigte Caches und definieren Sie eine Aufbewahrungsrichtlinie für Build-Artefakte. Beenden Sie vor dem Aufräumen die betreffenden Builds und prüfen Sie zuerst Inhalt und Speicherplatz. Löschen Sie gemeinsam genutzte Arbeitsverzeichnisse nicht rekursiv.
Prüfpunkt: Abhängigkeiten, Caches und IPA-Dateien haben klar definierte Speicherorte und genug Platz für das nächste Archiv.
Installieren Sie alle Komponenten, die Xcode beim ersten Start benötigt, bevor Sie die Automatisierung anbinden. Wenn ein Befehl im interaktiven Terminal gefunden wird, CI ihn aber nicht findet, vergleichen Sie Benutzer, PATH, Arbeitsverzeichnis und Shell-Initialisierung, statt sofort alle Abhängigkeiten neu zu installieren.
Der Browser-Desktop eignet sich für die Ersteinrichtung. Für längere grafische Arbeiten können Sie einen Client vergleichen; unbeaufsichtigte Builds laufen über SSH und Runner. Speichern Sie Quellcode und Artefakte nicht ausschließlich an einem der drei grafischen Zugänge.
| Verbindung | Geeignet für | Einstieg | Bei Ruckeln zuerst prüfen |
|---|---|---|---|
| Browser-Remote-Desktop | Erster Login, Systemeinstellungen, kurzer Blick auf einen laufenden Build | Über die Instanzdetails im Kundenportal öffnen; zunächst einen Bildschirm und eine mittlere Auflösung verwenden | Lokales Netzwerk, Browser-Zoom und mehrere gleichzeitig geöffnete Desktop-Sitzungen |
| VNC-Client | Längere Arbeit in der grafischen Oberfläche, Anpassung von Codec und Bildqualität | Nach den Verbindungshinweisen der Instanz einrichten; zunächst automatische Codierung oder ausgewogene Bildqualität wählen | Bildqualität oder Farbtiefe schrittweise reduzieren und nicht mehrere Einstellungen gleichzeitig ändern |
| macOS-Bildschirmfreigabe | Desktop-Diagnose und unterstützende Arbeiten von einem lokalen Mac aus | Eine von der Instanz unterstützte Verbindung verwenden; mit einem einzelnen Bildschirm bei 1920 × 1080 beginnen | Hohe Auflösung, bewegte Bildinhalte und Netzwerkverbindung; zuerst die Auflösung reduzieren und dann vergleichen |
Nachziehende Fenster bedeuten nicht, dass der Build langsamer läuft. Prüfen Sie über SSH die Build-Ausgabe und Ressourcennutzung, um festzustellen, ob der Job weiterarbeitet. Umgekehrt beweist ein flüssiger Desktop nicht, dass Signierung, Abhängigkeitsdownloads oder der Zugriff auf ein Remote-Repository funktionieren.
Notieren Sie bei Verbindungsproblemen die verwendete Verbindung, Zeitpunkt und Zeitzone, den lokalen Netzwerktyp sowie den SSH-Status. Lassen Sie eine bestehende Sitzung geöffnet, wenn Sie Einstellungen für Remote-Login oder Bildschirmfreigabe ändern, damit Sie sich nicht aussperren.
Konto, Instanzen und Rechnungen verwalten Sie im Kundenportal. Prüfen Sie vor einer Verlängerung oder Konfigurationsänderung die Bestell- und Instanznummer, damit kein Release für einen noch nicht bestätigten Mietzeitraum geplant wird.
Prüfen Sie im Kundenportal Ihr aktuelles Abo, das Ablaufdatum und offene Rechnungen. Kontrollieren Sie nach der Zahlung erneut den Abostatus. Sichern Sie vor dem Ablauf Quellcode, Zertifikats-Backups und Build-Artefakte an einem vom Team verwalteten Speicherort. Nutzen Sie eine auslaufende Instanz nicht als Langzeit-Backup.
Nach Ablauf ohne Verlängerung wird der Dienst beendet und der gesamte Datenträger gelöscht. Sichern Sie wichtige Daten vorher an einem anderen Ort.
Glide M4 bietet Apple Silicon M4, 16GB Arbeitsspeicher und 256GB SSD; Cruise M4 Pro bietet Apple Silicon M4 Pro, 64GB Arbeitsspeicher und 2TB SSD. Klären Sie die Abwicklung eines Tarifwechsels vorab über ein Support-Ticket. Ein Wechsel bedeutet kein sofortiges Speicher-Upgrade auf dem bestehenden Gerät.
Optionen für +1TB SSD, +2TB SSD und Thunderbolt 5 prüfen Sie bei der Konfiguration Ihrer Bestellung. Änderungen an einer bereits gemieteten Instanz müssen Sie zuerst per Ticket bestätigen lassen.
Unterstützt werden ausschließlich USDT-TRC20 und Visa / Mastercard / Amex (über Stripe). Alle Zahlungen werden in US-Dollar abgewickelt. Welche Zahlungswege verfügbar sind, richtet sich nach der Antwort des Zahlungs-Gateways. Die Zuteilung eines physischen Macs beginnt erst nach bestätigter Zahlung.
Wenn sich der Zahlungsstatus nicht aktualisiert, geben Sie die Bestellnummer und den Zahlungsbeleg an. Bei USDT-Zahlungen fügen Sie zusätzlich den Transaktions-Hash bei. Zahlen Sie nicht erneut und senden Sie niemals Ihre vollständige Kartennummer.
Wenn Sie bereits ein Konto haben, erstellen und verfolgen Sie Ihr Ticket im Kundenportal. Geben Sie die Instanznummer, Zeitpunkt und Zeitzone des Fehlers, die Schritte zur Reproduktion sowie bereinigte Log-Auszüge an. Für Fragen vor der Bestellung oder wenn Sie sich nicht anmelden können, finden Sie auf der Kontaktseite die Adresse support@vmfly.com.
Beschreiben Sie sowohl das erwartete als auch das tatsächliche Ergebnis und geben Sie an, ob SSH, Desktop und Runner noch verfügbar sind. Senden Sie keine Passwörter, privaten Schlüssel oder vollständigen Kartendaten.