Ratgeber

Eine iOS-CI/CD-Pipeline auf der eigenen Maschine betreiben

Die meisten Tipps zu iOS-CI optimieren das Falsche. Der Build-Schritt ist selten der Ort, an dem die Minuten verloren gehen. Hier steht, was in einer echten Pipeline wirklich etwas bewirkt. Und wie dedizierte Hardware die Rechnung verändert.

Wohin die Minuten wirklich gehen

Auf einem gehosteten Runner verbringt ein typischer iOS-Job viel Zeit, bevor er eine einzige Zeile Ihres Codes kompiliert. Er löst Abhängigkeiten auf und lädt sie herunter, füllt ein leeres DerivedData-Verzeichnis, installiert Tools und bootet einen Simulator. Diese Arbeit wiederholt sich bei jedem Lauf, weil die Maschine danach verworfen wird.

Auf einer dedizierten Maschine ist diese Arbeit größtenteils schon erledigt. In unserem Benchmark mit der Wikipedia-iOS-App war ein sauberer Build auf einem M6 mini 53 Prozent schneller als auf dem Standard-Runner von GitHub. Ein typischer CI-Job sank von 269 Sekunden auf 27. Der dedizierte Mac hatte seinen Build-Ordner behalten und baute nur neu, was sich geändert hatte.

Eine Pipeline, die sich lohnt

Teilen Sie die Arbeit auf. Lint, Tests für gemeinsame Swift-Pakete und Release-Automatisierung können auf Linux laufen. Nur Simulator- und Gerätearbeit gehört auf den Mac.
Cachen Sie die richtigen Pfade. DerivedData, SwiftPM, CocoaPods und Gems. Auf einer dedizierten Maschine bleiben sie kostenlos erhalten.
Nutzen Sie fastlane für die langweiligen Teile. Lanes für Build, Test, Screenshots und Upload geben Ihnen lokal und in der CI dieselben Befehle.
Halten Sie die Signierung berechenbar. fastlane match mit einem privaten Zertifikate-Repository ist weiterhin der zuverlässigste Weg. MacRun verwaltet die Signierung nicht für Sie. Dafür gibt es auch keine Überraschungen.
Verkleinern Sie die Matrix. Volle Geräte- und OS-Matrizen gehören auf main und in nächtliche Läufe, nicht in jeden Pull Request.

Beispiel-Workflow

name: iOS
on: [pull_request]

jobs:
  test:
    runs-on: [self-hosted, macOS, macrun-unit-01]
    steps:
      - uses: actions/checkout@v4
      - run: sudo xcodes select 26.6
      - run: bundle install
      - run: bundle exec fastlane test

Weil der Runner dediziert ist, gibt es hier keinen Schritt zum Wiederherstellen des Caches. Die Abhängigkeiten und DerivedData vom vorigen Lauf liegen schon auf der Platte.

Was das nicht löst

Dedizierte Hardware repariert keine langsame Testsuite, keinen Modulgraphen, der komplette Neubauten erzwingt, und keine wackligen Simulator-Tests. Sie beseitigt die wiederholte Einrichtung und den Minutenzähler. Der Rest bleibt Entwicklungsarbeit auf Ihrer Seite.

Häufige Fragen

Wie mache ich iOS-Builds in GitHub Actions schneller?

Streichen Sie wiederholte Einrichtung, bevor Sie die Kompilierung optimieren. Behalten Sie die Caches für DerivedData, SwiftPM und CocoaPods, verschieben Sie Arbeit ohne Mac auf Linux-Runner, verkleinern Sie die Gerätematrix bei Pull Requests und legen Sie eine Xcode-Version fest. Auf dedizierter Hardware bleiben die Caches zwischen Läufen automatisch erhalten.

Kann ich fastlane auf einem self-hosted macOS Runner nutzen?

Ja. fastlane, CocoaPods, Ruby und Node sind auf MacRun-Maschinen vorinstalliert. Sie rufen sie genauso auf wie lokal. Signieren mit fastlane match funktioniert wie auf jedem Mac.

Übernimmt MacRun die Code-Signierung für mich?

Nein, und das ist Absicht. Sie behalten die Kontrolle über Ihre Zertifikate und Provisioning-Profile, meist mit fastlane match und Ihrem eigenen privaten Repository. Wir stellen die Maschine, keinen verwalteten Signierdienst.

Kann ich iOS-UI-Tests auf einem dedizierten Runner ausführen?

Ja. Simulatoren laufen ganz normal. Weil die Maschine nicht neu aufgesetzt wird, bleiben Boot-Zustand des Simulators und DerivedData zwischen den Läufen warm. Das spart bei einem UI-Test-Job meist mehrere Minuten.