2026 Cross-Region Parallel
Mac Mini M4 · Xcode Parallel Testing, Simulator Budget & Disk Acceptance

Teams scale Apple CI by adding identical nodes in more regions. That works until two jobs fight the same writable tree, or until four destinations look “parallel” on paper while CoreSimulator thrashes and wall-clock stalls. Treat destination fan-out and job-level parallelism as separate budgets: the first is how many simulators one xcodebuild process tries to feed; the second is how many builds you allow on one host before unified memory and disk IO become the governor. Git and filesystem event storms amplify the pain—see the Watchman versus Git and disk waterline guide for throttle knobs that pair with the tables below.

Parameter table: -parallel-testing-enabled, destination count, Simulator concurrency

-parallel-testing-enabled YES asks Xcode to spread test targets across multiple destinations inside one invocation. In a parallel cluster, cap destinations per process and concurrent Simulator boots per node independently. Raising destinations without headroom usually hits CoreSimulator memory, boot contention, or snapshot IO before you see a better p95. Prefer adding nodes and splitting schemes over “always four destinations because four is faster on paper.”

If any step touches a shared database on a shared volume, align writers with the SQLite WAL and single-writer matrix so Parallel Testing does not mask a WAL checkpoint storm.

Build locks

Concurrent xcodebuild processes writing the same Derived Data or product tree can corrupt module caches and produce flaky “missing symbol” failures that disappear on retry. A build lock is the narrow contract that says only one writer may enter the publish window for a given artifact lineage, even when your queue is distributed.

Scheduler-level serialization (for example a single promote allocation in Nomad) and OS-level flock on a small critical section are complementary: the first stops two CI jobs from being scheduled as publishers; the second stops an operator script or rsync from interleaving mid-write. The placement pattern matches the single promotion lane described in Nomad affinity, build locks, and the 1TB/2TB disk matrix—swap Nomad for your orchestrator, keep the lock semantics identical.

LOCK_FILE="/var/tmp/xcode-derived-publish.lock"
flock -n "$LOCK_FILE" bash -c '
  xcodebuild -scheme "$SCHEME" -parallel-testing-enabled YES test
  rsync -a "$LOCAL_DERIVED/Build/Products/" "/Volumes/CIArtifacts/$BUILD_ID/"
' || { echo "lock busy"; exit 17; }

Keep compilation and most Derived Data work outside the lock; only signing, rename-into-place, and canonical tree updates belong inside. Avoid SSHFS for locked trees—use APFS local volumes or network filesystems with documented locking semantics.

Derived Data paths

The default Xcode Derived Data location is convenient on a laptop; on a shared CI host it becomes a multiplayer game unless every job gets an isolated subtree or you strictly separate read caches from write paths. The resilient pattern is a job-scoped -derivedDataPath (for example under a directory keyed by pipeline ID) so parallel invocations never share writable indexes, then archive or rsync only the products you care about.

• CI variables: Derive the path from immutable job IDs; delete failed workspaces aggressively and keep success artifacts under retention policy.
• Simulator data: Track CoreSimulator and runtime directories as first-class metrics—they grow with every Xcode bump independent of your repo size.
• Shared read cache (optional): Mount read-only dependency caches; never let two writers “optimize” into the same mutable cache without the same flock discipline as production binaries.

When you promote binaries across regions, the Derived Data path on the compile node can stay local while artifacts follow your object-store or rsync policy—just document which path is authoritative for debugging a red build.

Disk cleanup thresholds

Parallel Testing increases intermediate artifacts, crash logs, and simulator device data faster than linear CPU scaling suggests. Use utilization bands as operational rails on both 1TB and 2TB nodes: the percentages stay comparable; 2TB buys time, not immunity, especially when multiple iOS runtimes accumulate.

Acceptance checklist (excerpt): Weekly df plus Simulator footprint logged; no collisions on -derivedDataPath; Parallel Testing and destination caps versioned in the runbook; yellow triggers a ticket with owner; crossing red triggers capacity review. When procurement is the answer, use the public pages linked below—no account wall for comparing plans.

FAQ

More destinations did not speed up tests. Simulator, memory, or disk IO is saturated. Split the scheme across nodes or reduce per-node Simulator concurrency before raising destinations again.

flock busy spikes. Your critical section is too wide; shrink the locked window to signing and final publish only.

2TB nodes still hit yellow quickly. Multiple Xcode betas and runtimes are the usual culprit—same percentage thresholds, stricter runtime retirement policy.