Self-hosted macOS Build-Runner für Xcode-Projekte
Für Entwicklungsteams, die unbeaufsichtigte, reproduzierbare iOS- und macOS-Builds brauchen. Sie registrieren einen dedizierten Mac mini als Runner in Ihrem CI-System, und jeder Push liefert einen signierten Build oder ein Testergebnis auf Hardware, die niemand sonst nutzt.
- 01
Repository
Push oder Pull-Request
- 02
Dedizierter Mac-Runner
Self-hosted Agent
- 03
Build & Test
xcodebuild, Simulatoren
- 04
Artefakt
.ipa, Logs, Berichte
Was das löst
Wartezeit auf gemeinsam genutzten macOS-Runnern
Geteilte macOS-Runner starten mitunter langsam und werden pro Minute abgerechnet. Ein dedizierter Runner läuft immer und übernimmt Jobs sofort.
Kalte Caches bei jedem Job
Kurzlebige Runner starten leer. Ein dauerhafter Mac behält DerivedData-, SwiftPM-, CocoaPods- und Homebrew-Caches zwischen Builds.
Kontrolle über Xcode-Versionen
Sie entscheiden, wann eine neue Xcode- oder macOS-Version installiert wird, nicht der Image-Zeitplan eines CI-Anbieters.
Beispiel-Workflow
Vom Pull Request zu TestFlight
- 1
Ein Entwickler öffnet einen Pull Request auf GitHub.
- 2
Der Workflow verlangt die Labels self-hosted, macOS, ARM64 und landet auf Ihrem vBoxx-Mac.
- 3
xcodebuild lädt Pakete aus dem warmen lokalen Cache, baut und führt Unit-Tests aus.
- 4
Beim Merge auf main signiert fastlane die App mit Zertifikaten aus dem Schlüsselbund des Runners und lädt den Build zu App Store Connect hoch.
- 5
Logs und die .ipa werden als Artefakte in Ihrem CI-System gespeichert.
Was auf dem Mac läuft – und was nicht
Nutzen Sie den Mac-Runner für Schritte, die nur auf Apple-Systemen funktionieren. Alles andere kann auf Ihren vorhandenen Linux-Runnern bleiben.
| Pipeline-Schritt | Läuft auf | Warum |
|---|---|---|
| Xcode-Build, Unit- und UI-Tests | Läuft aufMac-Runner | Warumxcodebuild und der iOS-Simulator benötigen macOS. |
| Codesignatur, Notarisierung und Upload zu App Store Connect | Läuft aufMac-Runner | WarumNutzt den Schlüsselbund des Runners und Apple-Tools wie notarytool oder fastlane. |
| Docker-Builds, Container-Actions und Service-Container | Läuft aufLinux-Runner | WarumDocker-Container-Actions laufen auf einem macOS-Runner nicht nativ. |
| Linting, Backend-Tests und Web-Builds | Läuft aufBeides | WarumAuf Linux bleibt der Mac für Apple-Jobs frei. |
Einrichtung und Betrieb
- 1
Bestellen Sie einen Mac und wählen Sie im Konfigurator die macOS-Version. Sie erhalten vollen Admin-Zugriff per SSH.
- 2
Installieren Sie Xcode, die Command Line Tools und Ihre Toolchain (Homebrew, fastlane, Ruby oder Node nach Bedarf).
- 3
Legen Sie einen eigenen macOS-Benutzer ohne Admin-Rechte für den Runner an und installieren Sie den GitHub Actions Runner oder GitLab Runner (Shell Executor) als Launch Service, damit er nach einem Neustart wieder startet.
- 4
Importieren Sie Signierzertifikate in einen separaten Schlüsselbund dieses Benutzers, oder laden Sie sie pro Job mit fastlane match.
- 5
Legen Sie die Parallelität fest
Ein Runner-Prozess pro Mac ist der sicherste Standard für Xcode-Builds. Fügen Sie einen zweiten Runner erst hinzu, wenn Sie CPU, Speicher und Festplatte gemessen haben.
- 6
Planen Sie Wartung
Alte DerivedData und Simulatoren regelmäßig aufräumen und neue Xcode-Versionen zuerst auf einem Branch testen.
Welche Konfiguration passt
Geeignet für
Ein Runner für kleine bis mittlere Apps, ein Build gleichzeitig.
Mac mini M6
- 12-core CPU · 12-core GPU
- Arbeitsspeicher: 16 GB
- Speicher: 512 GB SSD
Wer macht was
vBoxx stellt bereit
- Ein dedizierter Mac mini M6 oder M5 Pro, den nur Ihr Runner nutzt, mit der macOS-Version Ihrer Wahl
- Dauerhafter SSD-Speicher, damit Build-Caches zwischen Jobs und nach Neustarts erhalten bleiben
- Netzwerk: 10-Gigabit-Ethernet-Port · 1 Gbit/s unbegrenzt · öffentliche IPv4 + IPv6
- APC-Fernsteuerung der Stromversorgung, um einen hängenden Runner hart neu zu starten, inklusive
- Optionale JetKVM-Konsole, falls macOS nicht mehr per SSH reagiert
Sie verwalten
- Installation und Updates von Xcode, macOS und Runner-Agent
- Runner-Registrierung, Labels, Tokens und Parallelität
- Signierzertifikate, Provisioning Profiles und Secrets
- Firewall-Regeln, SSH-Schlüssel und Zugriff für Ihr Team
- Backups von allem, was nicht in Git oder Ihrem CI-System liegt
Bevor Sie sich für dieses Setup entscheiden
- Self-hosted Runner in öffentlichen Repositories können Code aus geforkten Pull Requests ausführen. Nutzen Sie sie für private Repositories oder verlangen Sie eine Freigabe für externe Beitragende.
- Ein Mac ist ein Runner-Pool. Brauchen Sie viele kurze parallele Jobs auf jeweils frischen Maschinen, passt ein Dienst mit kurzlebigen Runnern möglicherweise besser.
- Ein verwalteter CI-Dienst oder automatische Xcode-Updates sind nicht enthalten. Den Mac richten Sie selbst ein.