Lohnt sich der Remote-Cache Bazel 9? iOS-CI-Auswahl 2026

Symptom: Wiederholte iOS-Builds blockieren Ihre Mac-Knoten, aber niemand kann belegen, ob ein gemeinsamer Cache die Wartezeit wirklich senkt. Schnellste Lösung: Aktivieren Sie den Bazel-9-Remote-Cache nicht sofort für die gesamte Organisation, sondern testen Sie zuerst einen festen Mac-Basispool mit schreibgeschütztem Cache und identischen Builds.

Der Cache ist nur dann eine gute Investition, wenn Ihre Actions reproduzierbar sind, mehrere Mac-Knoten tatsächlich dieselben Eingaben verarbeiten und Netzwerk sowie Zugriffssteuerung stabil funktionieren. Er ersetzt weder Xcode-Ausführung noch Simulator, Codesignierung, Archivierung oder physische Mac-Kapazität.

Für wen dieser Leitfaden gedacht ist: Für Verantwortliche, die große iOS-Projekte bereits mit Bazel bauen und wiederholte Kompilierung reduzieren möchten. Für IT-, FinOps- und Plattformteams, die zwischen zusätzlicher Mac-Kapazität, gemeinsamem Cache und einer Kombination aus beidem entscheiden. Für Security-Verantwortliche, die Schreibrechte, Artefakttrennung und die Nachvollziehbarkeit von Build-Ergebnissen prüfen müssen.

Letzte Aktualisierung: 01.09.2026. Versions- und Funktionsangaben wurden anhand der offiziellen Bazel-Dokumentation, der Bazel-Release-Hinweise, der Repositories von rules_apple und rules_swift sowie der Apple-Systemanforderungen geprüft.

Die erste Entscheidung: Cache aktivieren, verschieben oder Mac-Kapazität erhöhen

Bewerten Sie nicht zuerst die theoretische Beschleunigung, sondern die Ursache Ihrer Warteschlange. Der Remote-Cache speichert und liefert Ergebnisse von Bazel-Actions. Er macht aus einem Linux- oder anderen Nicht-Mac-Knoten jedoch keinen zulässigen Xcode-, Simulator- oder Signierknoten. Welche Actions in Ihrem Projekt überhaupt cachefähig und reproduzierbar sind, muss aus den Build-Logs hervorgehen.

<

Beobachtung im aktuellen iOS CI	Entscheidung	Begründung	Bewertung
Viele identische Actions laufen auf mehreren gleich konfigurierten Mac-Knoten; Eingaben und Toolchains sind stabil	Kontrollierten Cache-Pilot starten	Hohe Wiederverwendung ist plausibel, muss aber mit Logs belegt werden	Gut geeignet
Builds unterscheiden sich durch absolute Pfade, Umgebungsvariablen oder externe Tools	Deployment verschieben	Ein gemeinsamer Cache kann häufig verfehlen oder unpassende Ergebnisse liefern	Kritisch
Die Warteschlange entsteht vor allem bei Signierung, Archivierung, Simulator-Tests oder knapper Mac-Anzahl	Zuerst Mac-Kapazität prüfen	Diese Aufgaben verschwinden nicht durch gespeicherte Bazel-Action-Ergebnisse	Mac-Ausbau priorisieren
Cache-Server und Mac-Knoten liegen weit auseinander; Downloads dominieren die Build-Zeit	Netzwerk messen, nicht raten	Die Übertragung kann den Rechengewinn aufzehren	Nur nach Messung
Schreibende Entwicklerknoten, CI-Knoten und sensible Targets teilen ungefiltert einen Cache	Schreibzugriff sperren und Bereiche trennen	Ein gemeinsamer Schreibpfad erschwert Herkunftskontrolle und Cache-Poisoning-Abwehr	Nicht produktionsreif

Der **Bazel-9-Remote-Cache** ist damit kein Ersatz für einen Build-Server-Pool, sondern eine zusätzliche Optimierungsschicht. Für eine belastbare Entscheidung sammeln Sie zunächst die Wiederholungsquote, die Wartezeit vor dem Build, den Anteil sauberer Builds und die Überschneidung zwischen den verwendeten Mac-Knoten. Ein einzelner schneller Lauf ist kein ausreichender Nachweis.

Erster Prüfpunkt: Reproduzierbarkeit vor Trefferquote

Die zentrale Kennzahl ist nicht „Build dauerte weniger“, sondern: Unter welchen unveränderten Eingaben erzeugt Bazel denselben Action-Schlüssel und kann das Ergebnis sicher wiederverwenden? Die offizielle Beschreibung des Bazel-Remote-Caches erklärt, dass Remote-Caching auf gespeicherten Action- und Output-Ergebnissen sowie einem definierten Objektpfad beruht. Verändert sich eine relevante Eingabe, ist ein Cache-Miss korrekt und kein Fehler.

Prüfen Sie deshalb jede der folgenden Ursachen getrennt:

• Umgebungsvariablen: Region, Pfad, SDK-Auswahl oder geheime Variablen dürfen nicht unkontrolliert in die Action-Ausführung einfließen.
• Absolute Pfade: Ein Arbeitsverzeichnis, das nur auf einem bestimmten Mac existiert, kann zwischen Knoten zu unterschiedlichen Schlüsseln oder fehlerhaften Werkzeugaufrufen führen.
• Externe Programme: Shell-Skripte, Generatoren und selbst gepflegte Binärdateien müssen versioniert und auf allen Knoten identisch verfügbar sein.
• Toolchain-Drift: Unterschiedliche Xcode-, SDK-, Swift- oder Bazel-Versionen können die Wiederverwendung verhindern oder die Validierung erschweren.
• Nicht deklarierte Eingaben: Wenn ein Build-Schritt Dateien außerhalb seiner deklarativen Eingaben liest, ist ein Treffer nicht automatisch vertrauenswürdig.

Für rules_apple und rules_swift sollten Sie nicht aus der Existenz eines Tags oder einer Release-Datei auf Produktionsreife schließen. Prüfen Sie die [Unterstützung und Release-Hinweise von rules_apple](https://github.com/bazelbuild/rules_apple) sowie die [Werkzeugketten-Hinweise von rules_swift](https://github.com/bazelbuild/rules_swift) für genau die Kombination aus Bazel 9, Xcode, SDK und den verwendeten Regeln. Die Veröffentlichung von Bazel 9.1.0 ist in den [offiziellen Bazel-Releases](https://github.com/bazelbuild/bazel/releases) dokumentiert; daraus folgt jedoch nicht automatisch, dass Ihre gesamte Apple-Toolchain produktionsfähig zusammenspielt.

Warum rules_apple zwischen Macs keinen Treffer erzeugt

Wenn ein rules_apple-Projekt auf einem Mac trifft und auf einem zweiten Mac verfehlt, beginnen Sie mit dem Action-Umfeld, nicht mit einer pauschalen Cache-Löschung. Vergleichen Sie den Bazel-Server, die Regelversionen, Xcode und SDK, Hostpfade, verfügbare externe Werkzeuge sowie die tatsächlich an Bazel übergebenen Optionen.

Die Bazel-Anleitung zur Cache-Trefferanalyse ist auch für die Untersuchung des Prinzips relevant: Sie müssen lokale und entfernte Ausführung, Action-Schlüssel und Downloadverhalten auseinanderhalten. Die konkrete Eignung für Bazel 9 bleibt an Ihre geprüfte Version gebunden. Ein vermeintlicher Treffer ist nur dann akzeptabel, wenn das erzeugte Artefakt und seine Herkunft im nachgelagerten Prüfprozess nachvollziehbar bleiben.

Zweiter Prüfpunkt: Netzwerk, Cache-Effizienz und echte iOS-CI-Wirkung

Messen Sie mindestens diese Größen pro Build und nicht nur die Gesamtdauer:

1. Anteil der Remote-Hits und Remote-Misses nach Action-Kategorie.
2. Zeit für Download und Upload getrennt vom lokalen Ausführen.
3. Übertragungsfehler, Wiederholungen und unvollständige Artefakte.
4. Wachstum der Cache-Objekte und Anteil selten verwendeter Objekte.
5. Kaltstartverhalten nach geleertem oder neu aufgebautem Cache.
6. Wartezeit in der Mac-Queue vor und nach dem Cache-Lauf.

Die Werte müssen aus Ihren CI-Logs oder aus einem reproduzierbaren Benchmark stammen. Offizielle Dokumentation bestätigt das Protokoll und die Cache-Objekte, liefert aber keine allgemeingültige Trefferquote, Beschleunigung oder Speicherkosten für Ihr Projekt. Deshalb wäre eine pauschale Aussage wie „der Cache macht iOS-Builds um einen bestimmten Prozentsatz schneller“ nicht belastbar.

Vergleichen Sie drei Netzsituationen: Cache und Mac-Knoten im selben Rechenzentrumsstandort, Cache und Knoten in getrennten Regionen sowie Zugriff durch verteilte Remote-Teams. Ein Treffer ist nur wirtschaftlich, wenn die Übertragung schneller und verlässlicher ist als die erneute Action-Ausführung. Große Artefakte, geringe Wiederholung und instabile Verbindungen sprechen gegen einen zentralen Cache als erste Investition.

Die Frage, wie stark der Bazel-9-Remote-Cache einen iOS-Build beschleunigt, beantworten Sie daher mit einer Verteilung: Welche Action-Klassen treffen, welche laden große Ergebnisse herunter, und welche Aufgaben bleiben vollständig auf dem Mac? Dokumentieren Sie Median und Ausreißer aus Ihren Unternehmenslogs; verwenden Sie keine Einzelmessung als Leistungsversprechen.

Dritter Prüfpunkt: Schreibrechte wie eine Lieferkette behandeln

Ein Cache mit globalem Schreibzugriff ist für eine Unternehmensumgebung die falsche Standardeinstellung. Trennen Sie mindestens diese Rollen:

• Nur-lesende Entwicklerknoten: Sie dürfen geprüfte Ergebnisse abrufen, aber keine gemeinsamen Objekte veröffentlichen.
• Kontrollierte CI-Schreibknoten: Nur reproduzierbare, geprüfte Jobs dürfen Ergebnisse in einen abgegrenzten Namespace schreiben.
• Signier- und Release-Knoten: Für signierte, sensible oder regulatorisch relevante Targets sollte die Cache-Nutzung ausdrücklich erlaubt oder verboten werden; ein pauschaler Treffer darf die Freigabe nicht ersetzen.
• Administrations- und Bereinigungsknoten: Sie verwalten Lebensdauer, Sperrung, Löschung und Auditdaten, führen aber nicht automatisch normale Builds aus.

Sichern Sie die Verbindung, verwalten Sie Identitäten außerhalb der Build-Skripte und protokollieren Sie, welcher Knoten welches Objekt gelesen oder geschrieben hat. Prüfen Sie außerdem, ob Logs Pfade, Token, Zertifikatsnamen oder Quelltextfragmente offenlegen. Die Cache-Sicherheit ist nicht nur eine Frage der Verschlüsselung während der Übertragung: Entscheidend sind auch Herkunft, Namespace, Zugriff nach Projekt und Reaktion auf einen verdächtigen Treffer.

**Erfahrungshinweis:** Wenn ein Artefakt unerwartet erscheint, deaktivieren Sie nicht nur den Cache-Schalter. Isolieren Sie zuerst den betroffenen Namespace, sichern Sie Logs und vergleichen Sie denselben Commit in einem kontrollierten, cachefreien Lauf. So bleibt die Ursache unterscheidbar von einem gewöhnlichen Cache-Miss.

So prüfen Sie eine mögliche Cache-Verunreinigung

Ein brauchbarer Nachweis besteht aus demselben Commit, derselben Toolchain und derselben Mac-Konfiguration in einem cachefreien Lauf sowie einem Lauf mit Cache. Vergleichen Sie nicht allein die Exit-Codes. Prüfen Sie Ausgabedateien, Hashes, Metadaten, Signaturstatus und die Herkunft des verwendeten Objekts.

Bei einem unerwarteten Unterschied sperren Sie den Schreibpfad, markieren das Objekt und wiederholen den Build mit einem neuen, isolierten Cache-Bereich. Erst wenn die Abweichung reproduzierbar erklärt ist, darf der betroffene Bereich wieder in den Regelbetrieb. Eine erfolgreiche Pipeline ist kein Beweis dafür, dass der Cache nicht kontaminiert wurde.

Vierter Prüfpunkt: Cache oder zusätzliche Mac-Knoten?

Die wirtschaftliche Gegenüberstellung muss die Aufgaben trennen. Ein Cache senkt möglicherweise wiederholte Bazel-Ausführung. Zusätzliche Mac-Knoten erhöhen dagegen die parallele Kapazität für alle Aufgaben, die einen echten Mac benötigen: Xcode, Simulator, Codesignierung, Archivierung und Werkzeugkettenprüfung.

Rechnen Sie für beide Optionen mit denselben Variablen:

• Anschaffung oder Mietkosten der Mac-Knoten,
• Cache-Speicher, Netzwerk und Datentransfer,
• Betriebs- und Bereitschaftsaufwand,
• Pflege der Bazel-, Xcode- und Regelversionen,
• Sicherheits- und Auditaufwand,
• Kosten der verlorenen Entwicklerzeit durch Warteschlangen,
• Wiederherstellung nach Cache-Ausfall oder fehlerhaftem Artefakt.

Die Entscheidung lautet nicht „Cache gegen Mac“, sondern häufig „Cache für wiederholbare Actions plus Mac-Kapazität für nicht ersetzbare Aufgaben“. Wenn die Queue überwiegend aus Signierung und Simulator-Tests besteht, ist zusätzliche Mac-Kapazität der direkte Hebel. Wenn identische Kompilierungs-Actions auf mehreren stabilen Knoten wiederholt werden, kann ein Cache-Pilot die vorhandene Kapazität wirksamer machen.

Für eine neutrale Kapazitätsplanung können Sie die Informationen zu verfügbaren Mac-Optionen als Grundlage für Ihre eigene Beschaffung oder Mietbetrachtung heranziehen. Eine konkrete Preis- oder Einsparungszahl lässt sich ohne Ihre Laufzeit, Region, Auslastung und Konfiguration nicht seriös vorwegnehmen. Genau diese Variablen gehören deshalb in das TCO-Modell.

Fünfter Prüfpunkt: A/B-Test mit drei kontrollierten Zuständen

Führen Sie den Test nicht als zeitliche Einführungskampagne durch, sondern als metrischen Vergleich derselben Eingaben. Verwenden Sie denselben Commit, dieselbe Bazel-Konfiguration, dieselbe Xcode- und SDK-Kombination sowie identische Mac-Knoten.

1. Ohne Remote-Cache: Ermitteln Sie die lokale Referenz für saubere und wiederholte Builds.
2. Nur-lesender Remote-Cache: Messen Sie Treffer, Downloads, Fehler und Queue-Zeit, ohne neue Ergebnisse aus diesem Test zu veröffentlichen.
3. Kontrollierter Lese-/Schreib-Cache: Erlauben Sie Schreibzugriff ausschließlich den definierten CI-Knoten und protokollieren Sie Herkunft und Namespace.

Speichern Sie pro Lauf Commit, Toolchain, Knoten-ID, Cache-Modus, Action-Ergebnis, Download- und Uploaddauer, Queue-Wartezeit sowie den Status der nachfolgenden Tests. Wiederholen Sie jede relevante Build-Art unter denselben Bedingungen; die Zahl der Wiederholungen sollte in Ihrem Testplan begründet sein und darf nicht durch eine einzelne günstige Messung ersetzt werden.

Produktionsfreigabe als Entscheidungsbaum

• Wenn reproduzierbare Actions regelmäßig auf mehreren Knoten vorkommen, Remote-Hits stabil sind, Übertragungsfehler beherrscht werden und kein Unterschied bei Artefaktprüfung oder Signierung entsteht, dann führen Sie den Cache stufenweise mit getrennten Schreibrechten ein.
• Wenn die Trefferquote nur bei einer Toolchain-Kombination funktioniert oder absolute Pfade und externe Werkzeuge ungeklärt bleiben, dann reparieren Sie die Reproduzierbarkeit und testen erneut.
• Wenn der Cache häufig große Ergebnisse über eine langsame Verbindung überträgt und die Queue trotzdem durch Mac-exklusive Aufgaben entsteht, dann stoppen Sie die Cache-Ausweitung und priorisieren zusätzliche Mac-Kapazität.
• Wenn Herkunft, Löschung, Zugriff oder Wiederherstellung nicht auditierbar sind, dann bleibt der Cache außerhalb der Produktion.
• Wenn der Cache ausfällt, dann muss jeder Build auf einen definierten cachefreien Pfad zurückfallen können, ohne Signier- oder Release-Prozesse unkontrolliert zu verändern.

Planen Sie zusätzlich einen Wiederherstellungstest für Cache-Ausfall, fehlerhafte Objekte und den Neuaufbau eines Mac-Knotens. Ein Cache, der im Normalbetrieb schnell ist, aber bei einer Störung die gesamte iOS-CI blockiert, erhöht Ihr Betriebsrisiko.

Was Bazel 9 nicht ersetzt

Remote-Caching, Remote-Execution, Xcode-eigene Kompilierungs-Caches und zusätzliche Mac-Knoten sind vier verschiedene Maßnahmen:

• Remote-Cache: Wiederverwendung bereits erzeugter Bazel-Action-Ergebnisse.
• Remote-Execution: Ausführung von Actions auf einem anderen Worker; dadurch entstehen zusätzliche Sicherheits-, Toolchain- und Apple-Lizenzfragen.
• Xcode-Cache: Apple-spezifische lokale Wiederverwendung innerhalb der Xcode-Werkzeugkette; sie ist nicht dasselbe wie Bazel-Remote-Caching.
• Zusätzliche Mac-Knoten: Mehr parallele echte Mac-Arbeitsplätze für Builds, Tests, Archivierung und Signierung.

Prüfen Sie deshalb weiterhin die [Apple-Systemanforderungen für Xcode](https://developer.apple.com/xcode/system-requirements/). Ein Remote-Cache kann keine inkompatible macOS-, Xcode- oder SDK-Kombination reparieren. Ebenso kann er keine fehlende Simulatorinstanz, kein Zertifikatsproblem und keine überfüllte Signierwarteschlange ausgleichen.

Wenn Sie für einen kurzfristigen Kapazitätstest zusätzliche Apple-Silicon-Knoten benötigen, können Sie neben einem Eigenkauf auch eine zeitlich begrenzte Mac-Mietoption für Unternehmensprojekte in die TCO-Rechnung aufnehmen. Entscheidend bleibt, ob der Knoten isoliert, mit Ihrer geprüften Toolchain und ohne gemeinsame Schreibrechte als Baseline betrieben werden kann.

Die belastbare Entscheidung für Ihr Team

Der Bazel-9-Remote-Cache lohnt sich nicht wegen der Versionsnummer, sondern nur bei nachgewiesener Action-Wiederverwendung, reproduzierbarer Apple-Toolchain und kontrollierbaren Übertragungskosten. Starten Sie mit festen Mac-Knoten und einem schreibgeschützten Pilotbereich; erweitern Sie erst nach belegten Treffer-, Fehler-, Queue- und Artefaktwerten.

Wenn Ihre heutige Lösung ausschließlich auf lokalen Mac-Knoten beruht, entstehen bei Spitzenlast Wartezeiten, bei jeder zusätzlichen Entwicklerin und jedem zusätzlichen Entwickler neue Kapazitätsengpässe und bei eigener Hardware laufender Pflege- sowie Abschreibungsaufwand. Ein zentraler Cache löst diese Probleme nicht vollständig, wenn Signierung, Simulator-Tests oder Toolchain-Validierung die eigentliche Last verursachen. Für isolierte Versuche und zeitlich begrenzte Spitzen kann die Miete eines echten Mac über MACGPU deshalb flexibler sein als eine vorschnelle langfristige Beschaffung: Sie gewinnen eine zusätzliche Baseline oder einen elastischen Build-Pool, ohne den Cache als Ersatz für notwendige Mac-Arbeit zu missverstehen. Prüfen Sie die Option erst nach Ihrem A/B-Test und rechnen Sie sie mit Ihren realen Queue-, Betriebs- und Sicherheitskosten durch.