Mieten Sie einen dedizierten Mac mini tageweise statt eine geteilte virtuelle Maschine zu nutzen. Folgen Sie den Schritten unten – von der Modellauswahl und den Zugangsdaten bis zum erfolgreichen ersten Build.
Die Bereitstellung erfolgt etwa 15 Minuten nach Zahlungseingang. Wie lange Verbindung und erste Checks dauern, hängt von Ihren Schlüsseln, Ihrem Projekt und der Signierung ab.
Ab 1 Tag Mietdauer; zwei M4-Modelle, wahlweise tage-, wochen-, monats- oder quartalsweise. Die aktuelle Verfügbarkeit sehen Sie in der Konsole.
Wählen Sie bei der Bestellung Modell, Standort, Mietdauer und Zahlungsmethode. Für einen einzelnen Release können Sie mit einem Tag starten. Für kontinuierliche CI-Läufe vergleichen Sie Wochen-, Monats- und Quartalsmieten. Die gewählte Laufzeit wird im Voraus in US-Dollar bezahlt.
Ideal für Xcode-Builds einer einzelnen App, Builds mit fastlane und den Einstieg in SSH, VNC und die Entwicklungstools. Wenn Sie zusätzlich Simulatoren und Container parallel ausführen, prüfen Sie vorher den tatsächlichen Speicherbedarf Ihres Projekts.
Ideal für die parallele Nutzung von Xcode, Simulatoren und Containern oder wenn Sie mehr Platz für MLX-Modelle und Build-Caches benötigen. Bei großen Modelldateien können Sie bei der Bestellung verfügbare SSD-Erweiterungen prüfen.
Zur Auswahl stehen Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste und US-Westküste. Wählen Sie möglichst einen Standort in der Nähe Ihres Teams und Ihrer Code-Dienste, zu dem Sie eine stabile Verbindung haben. Beide Modelle sind an allen sechs Standorten verfügbar.
Als Zahlungsmethoden werden ausschließlich USDT-TRC20 sowie Visa, Mastercard und Amex über Stripe unterstützt. Welche Zahlungswege verfügbar sind, zeigt die Konsole an.
Die Übergabedaten finden Sie in der Konsole. Teilen Sie keine Zugangsdaten, privaten Schlüssel oder Signaturzertifikate in Support-Tickets. Für eine Fehleranalyse genügen die Bestellnummer und eine bereinigte Fehlermeldung.
| Angabe | Verwendungszweck | So prüfen Sie sie |
|---|---|---|
| Host-Adresse | Legt das Ziel für SSH- und VNC-Verbindungen fest. | Kopieren Sie die in der Konsole angezeigte Adresse und prüfen Sie, dass keine zusätzlichen Leerzeichen enthalten sind. |
| Benutzername | Wird zusammen mit der Host-Adresse für die SSH-Anmeldung verwendet. | Verwenden Sie das zur Bestellung gehörende Konto. Raten Sie nicht den standardmäßigen Systembenutzernamen. |
| Öffentlicher SSH-Schlüssel | Erlaubt Ihrem Gerät die Anmeldung per Schlüssel. | Laden Sie den Inhalt der Datei mit dem öffentlichen Schlüssel hoch. Der private Schlüssel bleibt auf Ihrem eigenen Gerät. |
| VNC-Zugang | Öffnet die grafische macOS-Oberfläche. | Folgen Sie den Verbindungshinweisen und Zugangsdaten auf der Übergabeseite. Verwenden Sie VNC nicht als SSH-Port. |
Erstellen Sie zuerst auf Ihrem eigenen Computer ein Schlüsselpaar und laden Sie dann den öffentlichen Schlüssel in die Konsole hoch. Verbinden Sie sich anschließend mit dem privaten Schlüssel auf Ihrem Gerät. Erstellen Sie nicht den einzigen Schlüssel für die Anmeldung auf diesem Host auf dem Remote-Rechner.
Prüfen Sie zunächst Adresse, Benutzernamen und öffentlichen Schlüssel. Stellen Sie danach sicher, dass Ihr lokales Netzwerk das Ziel erreichen kann. Bei einem TCP-Timeout liegt das Problem meist am Netzwerk; bei einer abgelehnten Anmeldung per Schlüssel sollten Sie Identität und Berechtigungen prüfen.
Legen Sie im lokalen Terminal anhand der Übergabedaten die Verbindungsvariablen fest. Prüfen Sie zuerst macOS und Prozessorarchitektur, und ermitteln Sie dann im Projektverzeichnis die verfügbaren Schemes. Führen Sie den Build oder die Archivierung erst aus, wenn Scheme und Signierungskonfiguration des Projekts geprüft sind.
ssh -i ~/.ssh/id_ed25519 "$VM_USER@$VM_HOST"Nach erfolgreicher Verbindung wechselt die Eingabeaufforderung zum Remote-Mac. Prüfen Sie bei der ersten Verbindung den Host-Fingerprint anhand der Übergabedaten.
sw_vers -productName
uname -m
sysctl -n machdep.cpu.brand_stringErwartete Ausgabe: macOS, arm64 und Apple M4. Welche macOS-Version installiert ist, entnehmen Sie der tatsächlichen Ausgabe auf dem bereitgestellten Rechner.
xcodebuild -list
xcodebuild -scheme "$SCHEME" -destination 'generic/platform=iOS' build CODE_SIGNING_ALLOWED=NOEin Build ohne Signierung prüft zunächst, ob sich das Projekt kompilieren lässt. Prüfen Sie bei Erfolg den Exit-Status und BUILD SUCCEEDED; bei einem Fehler beginnen Sie mit der ersten Build-Fehlermeldung.
fastlane gym --scheme "$SCHEME"Für Archivierung und Export benötigen Sie die Zertifikate, Provisioning-Profile und fastlane-Konfiguration des Projekts. Prüfen Sie nach dem Befehl das Exportergebnis und nicht nur die letzte Logzeile.
Hier sind VM_USER und VM_HOST und SCHEME Shell-Variablen. Belegen Sie sie zuerst mit den Übergabedaten und dem tatsächlichen Scheme des Projekts. Wenn Ihr Projekt eine bestimmte Xcode-Version voraussetzt, führen Sie xcodebuild -version zur Prüfung aus, bevor Sie die Version wechseln.
SSH eignet sich für Dateiübertragungen, Builds und Logs. Wenn Sie die Xcode-Oberfläche, Simulatoren oder Systemeinstellungen nutzen müssen, verbinden Sie sich per VNC mit den Angaben aus der Übergabe. Beide Verbindungsarten führen zu demselben dedizierten Mac mini.
Geben Sie im VNC-Client die auf der Übergabeseite angegebene Adresse und die Zugangsdaten ein. Übernehmen Sie nicht einfach SSH-Benutzername, Schlüssel oder Port in den VNC-Client.
Wählen Sie im Client zunächst eine niedrigere Bildschirmauflösung. Sobald Bild und Eingabe stabil laufen, können Sie die Auflösung erhöhen. Bei Verbindungen über größere Entfernungen zählt zuerst die Reaktionsgeschwindigkeit – nicht die höchstmögliche Bildqualität.
Führen Sie den eigentlichen Build weiterhin so aus, dass er sich per SSH-Befehl wiederholen lässt. Wenn die VNC-Sitzung abbricht, sind Builds, Logs und CI-Fehlersuche so nicht von der grafischen Oberfläche abhängig.
Bei einem schwarzen Bildschirm prüfen Sie zuerst, ob Sie mit der richtigen Bestellung und dem richtigen Standort verbunden sind, und kontrollieren Sie dann den Sitzungsstatus. Ändern Sie nicht wiederholt das Projekt und löschen Sie keine Build-Caches, um ein Problem mit der Remote-Anzeige zu beheben.
Wenn Sie einen selbst gehosteten GitHub-Actions-Runner einrichten möchten, erstellen Sie zuerst in den Runner-Einstellungen Ihres Repositorys den Registrierungsbefehl und ein kurzlebiges Token. Führen Sie dann den aktuell von der Plattform bereitgestellten Befehl auf diesem Mac aus. Speichern Sie das Token weder im Repository noch in Screenshots oder Build-Logs.
Registrieren Sie den Runner für das Repository, das Builds benötigt, oder für eine kontrollierte Organisation. Vergeben Sie ein Label, an dem dieser macOS-Host eindeutig zu erkennen ist. Senden Sie den Workflow erst ab, wenn der Runner als online angezeigt wird.
Der Workflow sollte zunächst den Code auschecken und anschließend denselben Xcode-Befehl wie bei der manuellen Prüfung ausführen. Fügen Sie erst nach einem erfolgreichen Build schrittweise Abhängigkeits-Caches, Tests, Signierung und Verteilung hinzu, damit nicht mehrere Fehlerquellen gleichzeitig entstehen.
Der Runner kann auf die Build-Umgebung dieses Rechners zugreifen. Beschränken Sie die Berechtigungen für auslösende Branches und Repositorys und verwalten Sie Signaturdaten sicher. Entfernen Sie nicht mehr benötigte Runner-Registrierungen vor Ende der Mietdauer.
Prüfen Sie zuerst, ob der richtige Runner ausgewählt wird, der Code ausgecheckt werden kann undxcodebuild -version mit der manuellen Prüfung übereinstimmt. Führen Sie danach das geprüfte Scheme aus. Scheme, Zielplattform und Signierungseinstellung im Workflow müssen zum Projekt passen. Übernehmen Sie den Beispielbefehl nicht unverändert als Build-Konfiguration für jedes Projekt.
Die Mietdauer beginnt mit der Bereitstellung. Planen Sie Backups, die Entfernung des Runners und Ihre Entscheidung zur Verlängerung vor dem Ablauf. Lassen Sie die einzige Kopie von Quellcode, Zertifikaten oder Build-Artefakten nicht auf dem Remote-Rechner zurück.
Prüfen Sie den Status Ihrer Quellcode-Commits, holen Sie Archive, Logs, Modelldateien und Konfigurationen ab und verifizieren Sie an Ihrem eigenen Speicherort, dass sich die Dateien öffnen lassen. Bewahren Sie Signaturdaten gemäß den Sicherheitsvorgaben Ihres Teams auf.
Wenn der Build noch nicht abgeschlossen ist, prüfen Sie in der Konsole die Verlängerungsoptionen. Wenn parallele Jobs durch Speicher oder Festplattenplatz begrenzt sind, vergleichen Sie die Ausstattung von Commit 16 und Commit 24 und entscheiden Sie anhand Ihres tatsächlichen Bedarfs.
Prüfen Sie, ob noch Jobs in der CI-Warteschlange liegen und der Runner noch mit einem Repository verbunden ist. Wie Daten nach Mietende behandelt werden, richtet sich nach den Nutzungsbedingungen und den in der Konsole angezeigten Regeln. Erstellen Sie Backups noch während der Mietdauer.
Wenn Sie Verbindungswege, Build-Befehle oder Abrechnungsregeln prüfen möchten, sehen Sie zuerst in der Dokumentation nach. Wenn Sie Ihre Remote-Entwicklungsumgebung systematisch einrichten möchten, suchen Sie im Blog nach „Remote-Mac-Entwicklungsumgebung einrichten“. Maßgeblich sind die aktuell veröffentlichten Blogbeiträge.
Starten Sie mit einem Tag, wählen Sie Standort und Modell und führen Sie nach der Bereitstellung mit dieser Checkliste den ersten Build aus.