2026 short-cycle cloud Mac CI: remote build caches vs node-local disk

Short-cycle cloud Mac CI in 2026 is rarely CPU-bound for the whole hour. After you pin Xcode and lock CocoaPods / SPM, the dominant variance becomes where caches live and how much you pay to move them on every job: cold restores from object storage, rsync over a regional link, or a warm slice on the runner SSD. This note compares three practical venues—remote shared cache, node-local ephemeral disk, and hybrid staging—and ends with a reuse decision matrix plus copy-paste parameters you can drop into scripts.

What actually moves: DerivedData, Pods, sccache

For Apple-platform CI, three directories dominate bytes and inode churn. DerivedData holds module caches and intermediates; it is high-impact for incremental builds but fragile across Xcode minors. CocoaPods (often Pods/ plus ~/Library/Caches/CocoaPods) is large yet more stable when Podfile.lock is enforced. sccache (or similar distributed compilers) shifts repeated C/C++/Rust work to a shared backend—valuable when your graph is mixed-language or you compile the same third-party blobs across many branches.

Runner topology matters as much as compression. If you are bursting self-hosted macOS runners, see our companion piece on elastic pools versus always-on nodes before you size cache sync; elastic pools amplify cold starts, while always-on favors sticky local disks.

Cold start vs warm slice

A cold start here means the worker has no useful cache for the checkout you are about to build—either a fresh VM, a wiped $RUNNER_TEMP, or a branch that invalidates your fingerprint. A warm slice means at least one of {DerivedData, Pods cache, sccache objects} is already on fast local storage or reachable with a small delta.

Rule of thumb we use internally: if median job length is under ~12 minutes and you spin machines frequently, optimize for predictable restore time over maximum incremental hit rate. A slow restore that blocks xcodebuild erases M-series CPU wins. When you need interactive triage on the same host, pairing SSH automation with occasional GUI checks is covered in remote cloud Mac: SSH or VNC for dev and CI triage.

Sync bandwidth and tail latency

Remote caches shine when many runners share identical blobs; they hurt when every job walks a deep tree over high-latency links. Prefer tools that preserve modification metadata and can skip unchanged files quickly (rsync --delete-delay, object-store sync with multipart uploads, or dedicated cache appliances). Watch egress symmetry: downloading Pods to every ephemeral worker can dwarf Git fetch if your CDN path is cold.

For sccache, measure server RTT separately from disk IO. A sub-millisecond NVMe on the runner cannot compensate for a 40 ms round trip if your compile graph fans out thousands of small cache lookups.

Reuse decision matrix (practical)

Copy-paste parameter checklist

Use the block below as a script skeleton: fill endpoints, swap in your secret handling, and keep paths macOS-native (~ expands differently in launchd vs interactive shells).

# Fingerprint namespace
export CACHE_NS="${XCODE_VERSION}_${PODFILE_LOCK_SHA}"

# Xcode module cache isolation
export CLANG_MODULE_CACHE_PATH="$PWD/.ci_modcache/$CACHE_NS"

# CocoaPods deterministic + cache dir
export COCOAPODS_DISABLE_STATS=1
export CP_HOME_DIR="$PWD/.cocoapods/$CACHE_NS"

# Restore / publish (tune compression vs CPU)
rsync -aH --numeric-ids --delete-delay --partial \
  "cache:$REMOTE_DERIVED/$CACHE_NS/" "~/Library/Developer/Xcode/DerivedData/"

# sccache (example)
export SCCACHE_BUCKET="your-org-sccache"
export SCCACHE_REGION="auto"
export RUSTC_WRAPPER=sccache

Close each job with an conditional publish: only upload when tests passed and the fingerprint matches, so bad states never poison the shared prefix. Trim old namespaces with lifecycle rules tied to your branch retention policy.