2026 Remote Mac iOS CI: Xcode Cache Hits & Derived Data Pre-warm Matrix

On Apple platforms, most of what people call “Xcode build cache” is really a bundle of stores under Derived Data: Swift incremental state, Clang module caches, PCH artifacts, index data, and per-workspace SourcePackages when you use Swift Package Manager. A cache hit means the compiler can skip work because inputs (source, flags, SDK, module maps) match a previous fingerprint. On a remote Mac shared by many jobs, misses often come from path churn, Xcode upgrades, switching -derivedDataPath, or cleaning intermediates while leaving metadata inconsistent.

Use the table below as a quick diagnostic: if your symptom matches the left column, the usual miss reason and stabilizing parameter are on the right.

export DEVELOPER_DIR="/Applications/Xcode_16.2.app/Contents/Developer"
export DERIVED_DATA_CI="$HOME/ci-derived-data/${CI_PROJECT_NAME:-myapp}"
mkdir -p "$DERIVED_DATA_CI"
xcodebuild -scheme "MyApp" \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -derivedDataPath "$DERIVED_DATA_CI" \
  -clonedSourcePackagesDirPath "$DERIVED_DATA_CI/SourcePackages" \
  build

Pair this with a cache key that hashes Package.resolved, Podfile.lock (if CocoaPods), .xcode-version or runner image tag, and the Xcode app path. When any of those change, expect a deliberate miss rather than chasing “flaky cache.”

Pre-warm reduces the first-build penalty after a runner image update or cold disk: run one full xcodebuild of your default scheme against the simulator destination you use in CI, then keep the resulting Derived Data directory on fast local SSD. For teams that share a remote Mac, schedule pre-warm after Xcode installation and whenever the default SDK changes.

Cleanup must be automated; manual deletes do not scale across dozens of branches. Prefer LRU-style eviction of ~/ci-derived-data/* by last-modified time rather than wiping everything on each job, unless compliance requires ephemeral disks.

Node stability improves when CPU thermal throttling and disk pressure are rare: keep at least 15–20 GB free on the volume that holds Derived Data and simulators; crossing into single-digit gigabytes free often correlates with mysterious compile timeouts, not compiler bugs.

“Clean build” in the Xcode UI is not the same as a forensic rebuild. Clean Build Folder removes build products for the workspace but may leave other incremental artifacts depending on settings. For CI, express intent with flags and environment variables instead of clicking menus on a headless remote Mac.

# Example: one-line cold vs warm toggle (set CLEAN_CI=1 for cold)
DERIVED_ROOT="${HOME}/ci-derived-data/${CI_PROJECT_NAME:-myapp}"
if [ "${CLEAN_CI:-0}" = "1" ]; then rm -rf "$DERIVED_ROOT"; fi
mkdir -p "$DERIVED_ROOT"
xcodebuild -scheme "MyApp" -destination 'platform=iOS Simulator,name=iPhone 16' \
  -derivedDataPath "$DERIVED_ROOT" build \
  COMPILER_INDEX_STORE_ENABLE=NO

If you need deterministic Swift packages, prefer checking in Package.resolved and passing -disableAutomaticPackageResolution only when you have pre-populated SourcePackages; otherwise resolution errors become hard failures—often desirable on release branches.

Use explicit thresholds so operators and scripts agree when to sacrifice build acceleration for node stability. The numbers below are starting points; graph disk use on your own remote Mac fleet and tighten if you see latency spikes near full disks.

# Disk check snippet for pipeline pre-step (exit 1 blocks the build)
PCT=$(df -P / | awk 'NR==2 {gsub(/%/,"",$5); print $5}')
if [ "$PCT" -ge 90 ]; then echo "Disk use ${PCT}% — refuse build"; exit 1; fi
if [ "$PCT" -ge 85 ]; then echo "WARN: disk use ${PCT}% — trigger cleanup"; fi