Mieten Sie einen exklusiven physischen Apple-Silicon-Mac und prüfen Sie Verbindung, Toolchain und Build Schritt für Schritt. Bringen Sie zunächst ein Projekt zum Laufen und binden Sie danach Ihre Team-CI an.
Zwei Modelle, fünf Standorte, ab $21.2/Tag. Exklusiver physischer Mac statt virtueller Maschine. Lieferstatus und Verfügbarkeit richten sich nach der aktuellen Anzeige in der Konsole.
Für reine Builds und erste Tests starten Sie mit Arm Line M4. Für Modellinferenz und höheren Bedarf an gemeinsam genutztem Speicher eignet sich Arm Grid M4 Pro. Der Speicherbedarf lässt sich nicht allein an der Projektgröße ablesen: Berücksichtigen Sie auch parallele Jobs und den Ressourcenbedarf der Toolchain.
M4 / 16GB / 256GB
Geeignet für erste Xcode-Builds, eine einzelne CI-Build-Pipeline und gelegentliche iOS-Builds. Prüfen Sie Installation der Abhängigkeiten, Cache-Größe und Build-Ablauf mit einem echten Projekt.
$21.2/Tag
Arm Line M4 mietenM4 Pro / 64GB / 2TB
Geeignet für Modellinferenz, größere Build-Caches und speicherintensive Workflows. Ob ein bestimmtes Modell darauf läuft, hängt auch von Quantisierung, Kontextlänge und Laufzeitparametern ab.
$59.8/Tag
Arm Grid M4 Pro mietenSingapur, Japan (Tokio), Südkorea (Seoul), Hongkong und US-Ostküste. Für interaktive Nutzung zählt die Netzwerkverbindung vom Teamstandort zum Mac. Bei unbeaufsichtigten Builds spielen außerdem Codeabruf, Downloads von Abhängigkeiten und die Rückübertragung von Build-Artefakten eine Rolle. Die geografische Entfernung ist nur ein erster Anhaltspunkt, keine Aussage zur gemessenen Latenz.
Für die erste Miete bietet sich ein Tag an. Führen Sie den vollständigen Ablauf mit demselben Projekt durch und entscheiden Sie danach über eine längere Laufzeit. Alle Preise für vier Laufzeiten und Zusatzoptionen finden Sie auf der Tarifseite.
Zahlung nur mit USDT-TRC20 oder Visa / Mastercard / Amex (über Stripe), Abrechnung ausschließlich in US-Dollar (USD). Welche Zahlungsoptionen tatsächlich verfügbar sind, zeigt die Antwort des Backends.
Prüfen Sie Modell, Laufzeit, Standort und Zusatzoptionen. Für USDT muss das TRC20-Netzwerk ausgewählt sein. Vergleichen Sie die Empfängerdaten und den Betrag auf der Zahlungsseite sorgfältig und verwenden Sie keine Zahlungsdaten einer früheren Bestellung erneut.
Bei Zahlungen on-chain ist eine Bestätigung erforderlich; die Dauer hängt vom Netzwerk ab. Bei Kartenzahlungen sind das Zahlungsergebnis und der Bestellstatus maßgeblich. Zahlen Sie nicht erneut, nur weil die Seite noch nicht aktualisiert wurde. Eine erfolgreiche Zahlung bedeutet nicht automatisch, dass der Mac bereits bereitgestellt ist.
Prüfen Sie den Bereitstellungsstatus in der Konsole. Sobald der Mac verfügbar ist, kontrollieren Sie IP-Adresse, Anmeldename, temporäres Passwort und Verbindungsport. Stimmen Zahlungsbeleg und Bestellstatus nicht überein, eröffnen Sie ein Support-Ticket mit Bestellnummer und Transaktions-Hash oder Zahlungsbeleg.
Führen Sie die folgenden Befehle im lokalen Terminal aus. Verwenden Sie die in der Konsole angezeigte Adresse, den Port und den Benutzernamen. Die Beispielwerte in dieser Anleitung sind keine Zugangsdaten.
read -r -p "Node IP: " NODE_IP
read -r -p "SSH port: " SSH_PORT
read -r -p "Login user: " NODE_USER
ssh -p "$SSH_PORT" "$NODE_USER@$NODE_IP"Beim ersten Verbindungsaufbau wird der Host-Fingerprint angezeigt. Prüfen Sie ihn über einen vertrauenswürdigen Kanal, bevor Sie ihn akzeptieren. Ändert sich ein bereits gespeicherter Fingerprint, klären Sie zunächst, ob der Mac neu installiert oder ausgetauscht wurde, statt die Prüfung zu überspringen.
whoami
hostname
passwdpasswd Führen Sie den Befehl in der SSH-Sitzung des Cloud Mac aus. Geben Sie auf Aufforderung das alte und das neue Passwort ein; während der Eingabe werden keine Zeichen angezeigt. Verwenden Sie das Passwort nicht für andere Dienste und schreiben Sie es nicht in Build-Logs.
| Feld | Eintrag | Prüfung |
|---|---|---|
| Serveradresse | Die in der Konsole angezeigte IP-Adresse des Mac | Muss zur aktuellen Bestellung gehören, nicht die Adresse Ihres lokalen Rechners. |
| Port | Der in der Konsole angezeigte VNC-Port | Falls der Client ein separates Portfeld anbietet, tragen Sie den Port dort ein. Raten Sie den Port nicht. |
| Anmeldedaten | Die in der Konsole angezeigten Zugangsdaten für die grafische Verbindung | Gehen Sie nicht davon aus, dass VNC- und SSH-Passwort immer identisch sind. |
| Erste Anzeigeeinstellungen | Mit niedriger Auflösung beginnen | Prüfen Sie zuerst, ob Bild und Eingabe funktionieren. Passen Sie anschließend die Bildqualität an Ihre Bandbreite an. |
Unter macOS können Sie auch die Bildschirmfreigabe verwenden. Prüfen Sie nach einer Änderung des Anmeldepassworts anhand der Bereitstellungshinweise, ob die Zugangsdaten für die grafische Verbindung ebenfalls aktualisiert werden müssen. Machen Sie den VNC-Dienst nicht direkt aus einem nicht vertrauenswürdigen Netzwerk erreichbar.
Führen Sie die folgenden Befehle auf dem Cloud Mac aus. Prüfen Sie zuerst das System und die vorhandenen Tools, und installieren Sie nur fehlende Komponenten. Überschreiben Sie nicht die von Ihrem Team festgelegten Xcode-, Ruby- oder Abhängigkeitsversionen, nur um die Beispiele zu übernehmen.
sw_vers
uname -m
df -h /
ls /Applications
xcode-select -p
xcodebuild -versionxcode-select Wenn der Pfad auf die eigenständigen Command Line Tools zeigt, ist damit noch nicht bestätigt, dass Xcode vollständig verfügbar ist. Ist Xcode nicht installiert, verwenden Sie zunächst ein vom Team freigegebenes Installationspaket. Entpacken Sie es und verschieben Sie es nach /Applications; der verfügbare Speicherplatz muss auch für das Entpacken, Abhängigkeiten und Build-Artefakte ausreichen.
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license
sudo xcodebuild -runFirstLaunch
xcodebuild -version
xcodebuild -showsdksIm Beispiel heißt die App Xcode.app . Bei mehreren Versionen verwenden Sie den tatsächlichen Pfad. Lesen Sie die Lizenzbedingungen, bevor Sie sie akzeptieren. Damit die Toolchain anderer Aufgaben unverändert bleibt, können Sie für einen einzelnen Build auch DEVELOPER_DIR auf die gewünschte Version setzen.
command -v brew
brew --version
ruby --version
bundle --versionFalls Homebrew noch nicht installiert ist, verwenden Sie das vom Team geprüfte Installationsverfahren. Fügen Sie keine Installationsskripte aus unbekannten Quellen ein. Auf Apple Silicon liegt Homebrew üblicherweise unter /opt/homebrew; maßgeblich ist die tatsächliche Ausgabe. Ist Homebrew installiert, aber in der aktuellen Sitzung nicht auffindbar, laden Sie die Umgebung:
eval "$(/opt/homebrew/bin/brew shellenv)"
brew install ruby
export PATH="$(brew --prefix ruby)/bin:$PATH"
gem install bundler
bundle install
bundle exec fastlane --versionDie letzten vier Befehle führen Sie im Projektverzeichnis aus. Dabei wird vorausgesetzt, dass das Repository bereits ein Gemfile mit festgelegten Fastlane-Abhängigkeiten und eine Lockdatei enthält. Fehlen diese Dateien, legen Sie zunächst im Team die Abhängigkeitsversionen fest und committen Sie die Lockdatei. Installieren Sie Build-Abhängigkeiten nicht gesammelt mit Administratorrechten in das System-Ruby.
read -r -p "Workspace path: " WORKSPACE
read -r -p "Shared scheme: " SCHEME
xcodebuild -list -workspace "$WORKSPACE"
xcodebuild \
-workspace "$WORKSPACE" \
-scheme "$SCHEME" \
-destination 'generic/platform=iOS' \
-archivePath "$HOME/BuildArtifacts/FirstBuild.xcarchive" \
CODE_SIGNING_ALLOWED=NO \
archiveWechseln Sie zunächst in das Projektverzeichnis, installieren Sie die im Projekt angegebenen Abhängigkeiten und prüfen Sie, ob das Scheme freigegeben ist. Bei Projekten mit ausschließlich einer .xcodeproj -Datei verwenden Sie statt -project den Parameter -workspace. Mit diesem Befehl prüfen Sie Build und Archivierung. Er erzeugt kein signiertes, verteilbares Paket und garantiert nicht, dass alle Signierung voraussetzenden Build-Skripte erfolgreich laufen.
Wählen Sie GitHub Actions oder GitLab Runner passend zu Ihrer Codeplattform. Testen Sie den Job zunächst auf einem vertrauenswürdigen Branch. Prüfen Sie Dienstbenutzer, Umgebungsvariablen und Schlüsselbundzugriff, bevor die produktive Pipeline übernimmt.
Wählen Sie in den Runner-Einstellungen des Repositorys oder der Organisation macOS und ARM64. Laden Sie das Paket gemäß den aktuellen Plattformanweisungen herunter, prüfen Sie es und entpacken Sie es in ein eigenes Verzeichnis. Führen Sie die folgenden Befehle dort aus. Registrierungs-URL und kurzlebiges Token finden Sie in den aktuellen Einstellungen.
read -r -p "Repository or organization URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh \
--url "$RUNNER_URL" \
--token "$RUNNER_TOKEN" \
--labels armvnc,macos,arm64
unset RUNNER_TOKEN
./svc.sh install
./svc.sh start
./svc.sh statusVerwenden Sie im Workflow runs-on: [self-hosted, macOS, ARM64, armvnc]und prüfen Sie, ob die Plattform dieselben Labels anzeigt. Der Start des Benutzerdienstes hängt von der Anmeldesitzung ab. Testen Sie nach der Installation, ob der Dienst nach einer erneuten Anmeldung und einem Neustart wieder läuft. Eine erfolgreiche Registrierung garantiert nicht, dass Jobs in jedem Zustand ausgeführt werden.
Erstellen Sie zunächst in den Projekt- oder Gruppeneinstellungen einen Runner und rufen Sie das Authentifizierungstoken ab. Sobald Homebrew eingerichtet ist, können Sie den Runner installieren und den Anweisungen zur Registrierung folgen. Der Dienst läuft unter dem aktuellen Benutzer; auch Build-Dateien und Zugangsdaten müssen diesem Benutzer zugeordnet sein.
brew install gitlab-runner
read -r -p "CI server URL: " CI_SERVER_URL
read -r -s -p "Runner authentication token: " RUNNER_TOKEN
printf '\n'
gitlab-runner register \
--url "$CI_SERVER_URL" \
--token "$RUNNER_TOKEN" \
--executor shell \
--description "ArmVNC macOS ARM64"
unset RUNNER_TOKEN
gitlab-runner install
gitlab-runner start
gitlab-runner status
gitlab-runner verifyLegen Sie in den Plattform-Einstellungen Labels und Regeln für geschützte Branches fest. Die tags der Pipeline müssen mit den Runner-Labels übereinstimmen. Der Benutzerdienst ist in der Regel an eine Anmeldesitzung gebunden. Prüfen Sie anhand der Dokumentation Ihrer Runner-Version die LaunchAgent- und Startkonfiguration. Starten Sie dieselbe Instanz nicht zusätzlich über eine andere Dienstverwaltung.
whoami ,xcode-select -p und xcodebuild -versionaus, um sicherzustellen, dass der Job in der erwarteten Umgebung läuft.Der Mac ist 365 Tage im Jahr verfügbar, doch Sie bleiben für den CI-Prozess verantwortlich. Prüfen Sie nach Abmeldung, Systemaktualisierung oder Neustart, ob Runner-Dienst, Netzwerk und Signierungsumgebung wieder funktionieren. Entfernen Sie vor dem Mietende die Runner-Registrierung auf der Plattform, widerrufen Sie Zugangsdaten und übertragen Sie Ihre Artefakte.
Um einzuschätzen, was ein Begriff für Sie bedeutet, fragen Sie sich zuerst, welchen Arbeitsschritt er beeinflusst: Ressourcenzugriff, Verbindung, Job-Ausführung oder Zusammenarbeit mehrerer Macs.
Halten Sie die geprüfte Xcode-Version, die Lockdatei der Abhängigkeiten und den Build-Befehl im Repository fest. Suchen Sie bei Problemen zuerst die Ursache bei Verbindung, Toolchain oder Projekt und wenden Sie sich mit den nötigen Informationen für eine minimale Reproduktion an den Support.
Starten Sie mit einer Tagesmiete und prüfen Sie zuerst Verbindung, Abhängigkeiten und Archive. Zahlung nur mit USDT-TRC20 oder Visa / Mastercard / Amex (über Stripe), Abrechnung in USD.