Zielgruppe: Ingenieurinnen und Ingenieure sowie CI/CD-Betreuer in iOS- und Cross-Platform-Teams, die Xcode-Builds auf gemieteten Remote-Mac-Knoten ausführen. Die Kernbegriffe dieses Artikels sind: Remote Mac, Xcode-Kompilierungs-Cache, Derived Data, iOS CI und Build-Beschleunigung. Wir adressieren Suchintentionen rund um reproduzierbare Parameter, Knotenstabilität und nachvollziehbare Schwellen – ohne Marketing-Floskeln. Vertiefung und Navigation: Technik-Blog – Übersicht aller Artikel, MacPull Startseite, Mac CI/CD: Git, Clone & CocoaPods beschleunigen, Remote-Mac-Cache-Strategie für Git & npm.

Kompilierungs-Cache: Prinzip und Trefferbedingungen (Referenztabelle)

Der Xcode-Kompilierungs-Cache lebt primär unter Derived Data: Objektdateien, Swift-Module, Indexdaten und Build-Beschreibungen. Xcode kann Arbeit überspringen, wenn Eingaben (Quellen, generierte Dateien, Flags) und die Toolchain-Signatur stabil zum gespeicherten Zustand passen. Auf Remote-Mac-iOS-CI scheitert die Trefferquote oft daran, dass jeder Job einen neuen temporären Pfad erhält oder Xcode-Versionen zwischen Matrix-Jobs wechseln.

Bedingung Wirkung auf Cache-Treffer Operative Maßnahme
Xcode / Swift-Version Abweichung → nahezu sicherer Fehltreffer xcodebuild -version und swift --version in Cache-Key und Dokumentation fixieren
Fester derivedDataPath Stabilisiert Treffer über Läufe hinweg -derivedDataPath "$CI_DERIVED_DATA" immer setzen, Pfad pro Runner-Pool eindeutig
SwiftPM / Package.resolved Lock-Änderung invalidiert Modul-Cache -clonedSourcePackagesDirPath "$CI_SPM_CLONE" für wiederverwendbare Checkouts
Debug vs. Release Wechsel trennt Artefakt-Räume Separate Unterverzeichnisse unter Derived Data pro Konfiguration
OTHER_SWIFT_FLAGS / Preprocessor Kleine Änderungen invalidieren breit Flags versionieren; generierte Quellen deterministisch halten

Ergänzend zur Versionsdisziplin lohnt sich der Abgleich mit CI Pre-Pull und Versionskonsistenz auf Remote-Mac, damit Toolchain und Repo-Zustand vor dem ersten xcodebuild zusammenpassen.

Remote-Knoten: Derived-Data-Vorwärmung und Aufräumstrategien

Lang laufende Remote-Mac-Runner sind die beste Grundlage für Build-Beschleunigung: einmal aufgewärmte Abhängigkeiten und Module amortisieren sich über viele Pipelines. Vorwärmung bedeutet: Toolchain festlegen, Pakete auflösen, dann einen normalen Build oder Archive-Schritt ausführen. Aufräumen sollte selektiv erfolgen (LRU nach Projektordnern), damit die Knotenstabilität nicht durch vollständiges Löschen aller Derived Data leidet.

export DEVELOPER_DIR=/Applications/Xcode_16.2.app/Contents/Developer
xcodebuild -version
swift --version
xcodebuild -project YourApp.xcodeproj -scheme YourScheme \
  -resolvePackageDependencies
xcodebuild -workspace YourApp.xcworkspace -scheme YourScheme \
  -derivedDataPath "$CI_DERIVED_DATA" \
  -clonedSourcePackagesDirPath "$CI_SPM_CLONE" build

Für CocoaPods-Projekte: pod install oder Wiederherstellung eines gecachten Pods-Verzeichnisses vor dem ersten Compile. Prüfen Sie freien Speicher und Inode-Druck vor dem Start:

df -h /
df -ih /
du -sh "$CI_DERIVED_DATA" 2>/dev/null || true

Checkliste (kurz): (1) DEVELOPER_DIR gesetzt, (2) -derivedDataPath persistent pro Pool, (3) SPM/Pods vor dem Haupt-Build aufgelöst, (4) Cron oder CI-Stufe löscht nur älteste DD-Projektordner oberhalb definierter Schwellen.

Clean Build vs. inkrementell: Parameter und Trade-offs

Ein vollständiger Clean Build maximiert Reproduzierbarkeit und hilft bei kryptischen Linker- oder Modulfehlern, kostet aber Laufzeit und CI/CD-Kapazität. Inkrementelle Builds halten die Trefferquote hoch, erfordern aber klare Regeln, wann Sie bewusst invalidieren. Die folgende Entscheidungsmatrix fasst typische Pipeline-Typen zusammen.

Pipeline-Typ Empfohlene Strategie Typische Flags / Aktionen
Feature-Branch / PR Inkrementell, Cache beibehalten Fester -derivedDataPath; kein globales rm -rf ~/Library/Developer/Xcode/DerivedData
Release / App Store Geplanter Clean oder frischer DD-Pfad Separates CI_DERIVED_DATA_RELEASE; optional xcodebuild clean im Release-Job
Nach Toolchain-Upgrade Einmaliger Voll-Clean oder neuer Pfad Neuer Cache-Key; alte Derived-Data-Ordner archivieren oder löschen
Verdacht auf korrupten Modul-Cache Selektives Löschen Nur Unterordner des betroffenen Projekts oder ModuleCache.noindex des Jobs

Als Daumenregel: PR-Builds optimieren Zeit, Release-Builds optimieren Determinismus. Dokumentieren Sie im Runbook, welcher Job welche Stufe der Invalidierung auslöst, damit On-Call nicht raten muss.

Fehlerrückfall, Knotenstabilität und Festplatten-Schwellen (FAQ)

Die häufigsten Störungen entstehen, wenn der Datenträger voll läuft, gleichzeitig aber noch hohe Erwartungen an Cache-Treffer bestehen. Kombinieren Sie Metriken (df, du, Alarme) mit einem gestuften Fallback: zuerst kleinere Bereiche löschen, dann Pfade wechseln, zuletzt global bereinigen.

Ab welcher Belegung soll ich eingreifen?
Pragmatisch: 85 % Belegung als Warnstufe loggen, 90 % oder freier Speicher unter 15–25 GB als harte Eskalation für selektives Aufräumen oder Job-Drosselung. Passe die Werte an SSD-Größe und parallele Jobs an.
Was ist der schnellste Fallback bei „seltsamen“ Compile-Fehlern?
Zuerst den projektbezogenen Ordner unter Derived Data entfernen und den Job wiederholen. Hilft das nicht, einen neuen -derivedDataPath verwenden. Ein vollständiger Clean bleibt der letzte Schritt und sollte an Release-Jobs gebunden sein.
Wie schütze ich die Stabilität des Remote-Knotens?
Gleichzeitige Archive-Jobs begrenzen, I/O-Watchdogs setzen und nach großen Builds immer df -h prüfen. Kombinieren Sie das mit allgemeinen Pull-Stabilitäts-Tipps aus Remote-Mac Pull-Stabilität: Git, Homebrew & npm.
Welche Umgebungsvariablen sollten in jedem iOS-CI-Job gesetzt sein?
Mindestens DEVELOPER_DIR, ein eindeutiger CI_DERIVED_DATA, optional CI_SPM_CLONE, sowie – bei Proxy – konsistente HTTPS_PROXY/NO_PROXY-Werte, damit Paketdownloads nicht die Konsistenz der Checkouts zerstören.

Zusammenfassung: Hohe Trefferquote des Xcode-Kompilierungs-Caches auf Remote Mac hängt an festen Pfaden, stabilen Toolchains und sauberen Cache-Keys – nicht an „mehr SSD wünschen“. Derived Data gezielt vorzuwärmen und selektiv zu reinigen sichert iOS CI und Build-Beschleunigung, während Clean-Build-Entscheidungen bewusst der Release-Ebene vorbehalten bleiben sollten.

Nächste Schritte (ohne Login): Auf der Seite „Kaufen“ – Remote-Mac-Pakete wählen finden Sie geeignete Apple-Silicon-Knoten für dauerhafte Runner-Pools. Für Netzwerk und Zugang: Hilfe-Center – Anbindung & FAQ. Überblick Leistungen: MacPull Startseite. Weitere How-tos: Technik-Blog – alle Artikel, Mac CI/CD mit Git & CocoaPods.

Remote-Mac für iOS-CI auswählen Hilfe & Anbindung

Vorgeschlagene Ankertexte für interne Verlinkung: „Technik-Blog – Übersicht“, „MacPull Startseite“, „Remote-Mac-Cache-Strategie (Git/npm)“.