Richten Sie mit mehreren dedizierten physischen Macs eine iOS-Build-Farm ein. Verteilen Sie unterschiedliche Schemes auf macOS Runner und erledigen Sie Archivierung, Signierung und TestFlight-Uploads getrennt – statt alle Jobs auf einem Arbeitsrechner zu bündeln.
ArmRDP stellt Ihnen einen vollständigen Mac mini bereit, keine VM. Drei Konfigurationen, fünf Standorte, ab $21.1/Tag. Verlagern Sie zunächst eine Pipeline und erweitern Sie dann nach Bedarf.
Für nächtliche Builds müssen Runner, Signierung und Upload zuvor eingerichtet sein. Die Dauer hängt von Projekt, Abhängigkeiten und Warteschlange ab.
Jobs nach Scheme trennen, Artefakte standortübergreifend zusammenführen.
Registrieren Sie den Cloud-Mac als macOS Self-Hosted Runner für GitLab oder GitHub Actions. Verwalten Sie das Repository wie gewohnt im Team und leiten Sie nur macOS-spezifische Jobs an diesen physischen Rechner weiter.
Dokumentieren Sie die vollständige Xcode-Version, SDKs, den Pfad der Command-Line-Tools und Lockfiles für Abhängigkeiten. Verwalten Sie mehrere Xcode-Versionen mit xcodes und legen Sie für jeden Job DEVELOPER_DIR fest, damit Projekte nicht dieselbe globale Auswahl verwenden.
Runner-Tags sollten mindestens Betriebssystem, Toolchain und Einsatzzweck abbilden, zum Beispiel macos, xcode-pinned und ios-release. Weisen Sie Release-Jobs nur vertrauenswürdigen Runnern zu. Ungeprüfte Branches dürfen nicht in einer Umgebung laufen, in der Signaturmaterial hinterlegt ist.
Weisen Sie anfangs jedem Rechner nur einen rechenintensiven Build-Job zu. Beobachten Sie Clean Builds, Cache-Treffer, Speicherauslastung und wachsenden Speicherbedarf, bevor Sie die Parallelität erhöhen oder weitere Knoten hinzufügen. Die Anzahl der Rechner ist nicht der einzige Faktor: Auch Caches und die Aufteilung der Jobs beeinflussen die Warteschlange.
xcodebuild -version
xcode-select -p
xcrun --sdk iphoneos --show-sdk-version
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-archivePath artifacts/App.xcarchive \
archiveErsetzen Sie den App-Arbeitsbereich und das Scheme durch die tatsächlichen Projektnamen. Speichern Sie Build-Artefakte, Logs und Testergebnisse für jeden Job separat. Lassen Sie nicht zwei Jobs in dasselbe Ausgabeverzeichnis schreiben.
Bereiten Sie die Veröffentlichung im App Store vor und verknüpfen Sie Build-Artefakte mit dem jeweiligen Commit, der Toolchain und der Signaturkonfiguration. Der Cloud-Mac stellt die Build-Umgebung bereit; Veröffentlichungsrechte und Prüfunterlagen verwaltet weiterhin Ihr Team.
Bewahren Sie .xcarchive, Exportoptionen und dSYM-Dateien auf. Prüfen Sie vor dem Export Release-Konfiguration, Versionsnummer und Build-Nummer. Bewahren Sie nicht nur die fertige .ipa-Datei auf – ohne Symboldateien wird die Analyse von Abstürzen erschwert.
Abnahmekriterium: Jedes Artefakt lässt sich einem eindeutigen Commit und einer Build-Nummer zuordnen.
Importieren Sie Distributionszertifikate und Provisioning-Profile über einen kontrollierten Prozess und verwenden Sie für Build-Jobs einen separaten Schlüsselbund. Wenn Sie fastlane match einsetzen, beschränken Sie den Repository-Zugriff und speichern Sie Entschlüsselungsmaterial im CI-Secret-Store statt im Skript.
Abnahmekriterium: Nicht interaktive Jobs können codesign ausführen.
Laden Sie Artefakte mit den vom Team autorisierten Zugangsdaten hoch. Prüfen Sie Simulatoransichten in der grafischen Oberfläche und erstellen Sie Prüfmaterial. Kontrollieren Sie Zielgerät, Sprache und Version. Upload und Freigabe sind zwei getrennte Schritte.
Abnahmekriterium: Upload-Ergebnis, Prüfmaterial und Logs werden gemeinsam archiviert.
Beschränken Sie Release-Jobs auf festgelegte Branches und Personen. Abgelaufene Zertifikate, nicht passende Provisioning-Profile und fehlende Upload-Berechtigungen müssen anhand der Logs getrennt behoben werden. Eine leistungsstärkere Maschine löst diese Probleme nicht.
Der dedizierte physische Rechner führt macOS nativ aus. Metal und Simulatoren eignen sich für die entsprechenden Entwicklungsaufgaben. SSH ist für Skripte und Logs gedacht, Bildschirmfreigabe per VNC für Xcode, Simulatoren und die Prüfung der Benutzeroberfläche. Beide Zugriffswege haben ihren eigenen Zweck.
Builds mit festgelegten Versionen, automatisierte Tests, Simulator-Screenshots und die Installation von Abhängigkeiten lassen sich unabhängig vom lokalen Arbeitsrechner ausführen. Bei interaktiver Fehlersuche reproduzieren Sie das Problem zuerst in der GUI und übernehmen wiederholbare Schritte anschließend in ein Skript.
Prüfen Sie zuerst, ob Zielsystem, Simulator-Runtime und Xcode-Version zusammenpassen.
Die Reaktion der Remote-Anzeige hängt von Netzwerkverbindung, Auflösung und Kodierung ab und entspricht nicht der eines lokalen Bildschirms. Bei Arbeiten mit externen Geräten, bestimmter Peripherie oder häufiger Interaktion sollten Sie echte Aufgaben zunächst tageweise ausführen und erst danach über den Umzug entscheiden.
ArmRDP M4 Pro bietet einen M4 Pro, 64 GB gemeinsamen Speicher und eine 2-TB-SSD. Die dedizierte Umgebung eignet sich zum Laden lokaler Modelle, zum Vergleich quantisierter Varianten und zum Testen von Inferenz-APIs – als Grundlage für die Entscheidung, ob sich weitere Investitionen lohnen.
Die Dateigröße eines Modells entspricht nicht dem benötigten Arbeitsspeicher. Neben den Gewichten müssen KV-Cache, Kontextlänge, Laufzeit und weitere Prozesse berücksichtigt werden. Starten Sie mit einem kurzen Kontext für das Zielmodell, erfassen Sie Spitzenspeicher und Speicherdruck und erhöhen Sie dann schrittweise die Zahl der Anfragen.
Verwenden Sie ein Inferenz-Framework mit Apple-Silicon-Unterstützung und prüfen Sie die Kompatibilität der konkreten Operatoren und Modellformate. Gemeinsamer Speicher garantiert nicht, dass jedes Modell ausgeführt werden kann, und erlaubt keine direkten Rückschlüsse auf die Generierungsgeschwindigkeit. Testen Sie mit Ihren eigenen Prompts, Kontexten und Ausgabelängen.
Planen Sie Inferenzexperimente möglichst getrennt von Release-Builds, damit konkurrierender Speicherbedarf die Ergebnisse nicht verfälscht. Sichern Sie Remote-APIs mit Authentifizierung und beschränktem Zugriff ab, statt Ports direkt öffentlich erreichbar zu machen.
Verlagern Sie nicht gleich das gesamte Release-System. Wählen Sie ein Scheme mit klaren Abhängigkeiten, das lokal zuverlässig Builds erzeugt. Verwenden Sie das lokale Ergebnis als Vergleich und durchlaufen Sie anschließend die folgenden drei Abnahmeschritte.
Rufen Sie das Repository mit schreibgeschützten Zugangsdaten oder den geringstmöglichen Berechtigungen ab. Prüfen Sie Submodule, private Abhängigkeiten und große Dateien. Verwalten Sie Zertifikate, Provisioning-Profile und Entschlüsselungsschlüssel getrennt und legen Sie sensible Dateien nicht im Code-Repository ab.
Abnahmekriterium: Quellcode und Abhängigkeiten für denselben Commit sind vollständig vorhanden.
Installieren und fixieren Sie die benötigte Xcode-Version mit xcodes. Halten Sie Homebrew-Abhängigkeiten und Package-Lockfiles fest, installieren Sie die benötigte Simulator-Runtime und dokumentieren Sie Umgebungsvariablen und Ausführungspfade.
Abnahmekriterium: Manuelle Ausführung erzeugt die erwarteten Artefakte.
Registrieren Sie den Runner, legen Sie Tags und Repository-Berechtigungen fest und leiten Sie die erste Pipeline an den Cloud-Mac weiter. Ergänzen Sie nach erfolgreichem Test Signierung und Upload und erweitern Sie die Einrichtung anschließend auf weitere Schemes und separate Knoten.
Abnahmekriterium: Unbeaufsichtigte Jobs lassen sich wiederholt erfolgreich ausführen.
Behalten Sie während der Migration die vorhandenen Runner bei, bis Clean Build, Signierung, Upload und Wiederholungen nach Fehlern geprüft sind. Exportieren Sie die benötigten Daten vor Ablauf der Mietdauer und verwenden Sie den Knotenspeicher nicht als einziges Archiv.
Die folgenden Empfehlungen orientieren sich an der täglichen Job-Anzahl und sind weder Durchsatzmessungen noch Zusagen zur Build-Dauer. Ein großer vollständiger Build kann mehr Ressourcen beanspruchen als mehrere inkrementelle Builds. Erfassen Sie Dauer, Cache-Treffer und Spitzenspeicher, bevor Sie aufrüsten oder weitere Rechner hinzufügen.
| Richtwert: Jobs pro Tag | Einstiegsmodell und Ausstattung | Was zuerst geprüft werden sollte | Tageweise mieten |
|---|---|---|---|
| 1–5 Einzeltests und Einstieg mit einem Projekt |
ArmRDP M4 Base M4 / 16 GB / 256 GB |
Zuerst Archivierung und Signierung durchgängig testen. Beobachten Sie den Speicherbedarf für Abhängigkeitsinstallation, DerivedData und Build-Artefakte. | $21.1/TagM4 Base mieten |
| 6–20 Kontinuierliche Integration, häufige Iterationen |
ArmRDP M4 Plus M4 / 24 GB / 512 GB |
Prüfen Sie den Speicherdruck, wenn Builds und Tests gleichzeitig laufen. Optimieren Sie zuerst den Cache und entscheiden Sie dann, ob weitere Runner nötig sind. | $41.4/TagM4 Plus mieten |
| Ab 21 Mehrere Targets, ressourcenintensive Jobs |
ArmRDP M4 Pro M4 Pro / 64 GB / 2 TB |
Prüfen Sie den Ressourcenbedarf großer Projekte oder von Modellexperimenten. Wenn die Warteschlange der Engpass ist, verteilen Sie unabhängige Jobs auf mehrere Knoten. | $59.5/TagM4 Pro mieten |
Fünf Standorte sind verfügbar: Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und der Westen der USA. Alle drei Modelle gibt es an jedem Standort. Vergleichen Sie bei grafischer Arbeit die Verbindung zwischen Ihrem Team und dem Knoten. Bei unbeaufsichtigten Builds sollten Sie auch die Wege zu Repository, Abhängigkeitsquellen und Upload-Ziel prüfen. Die tatsächliche Verfügbarkeit wird in Echtzeit über die Konsole angezeigt.
Beginnen Sie in der Testphase mit einer tageweisen Miete. Bei regelmäßigem Release-Rhythmus können Sie Wochen-, Monats- und Quartalspreise vergleichen. Unterstützt werden USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Die Abrechnung erfolgt in US-Dollar; welche Zahlungswege verfügbar sind, zeigt das Backend an.
Bringen Sie ein Scheme, eine Signaturkonfiguration und klare Abnahmekriterien mit. Sobald Archivierung, Signierung und Bereitstellung funktionieren, können Sie weitere Jobs auf zusätzliche Knoten verteilen.