When you standardise a remote bare-metal Apple Silicon pool for iOS and macOS CI, the first fork is almost always the same: install only Xcode Command Line Tools (CLT), or ship the full Xcode.app bundle. CLT looks lean on paper — smaller downloads, fewer GUI packages, faster golden images. Full Xcode pulls in the IDE, SDKs, and simulator runtimes your teams expect for xcodebuild test with destinations, UI automation, and release archive flows that assume the same toolchain layout as a developer laptop. This FAQ grounds the trade-off in what actually happens on shared NVMe under multi-repo parallel Archive jobs, how xcode-select drift breaks unattended hosts, and where disk budgets explode when simulators enter the picture.
1. CLT-only: what you gain, what you still owe Apple
CLT-only nodes are excellent for compile-only lanes: SwiftPM resolution, static analysis, lightweight xcodebuild build without simulators, and many server-side Swift builds. You still depend on Apple’s packaging for compilers and platform SDKs; you are not “smaller Xcode” in every dimension, just without the app bundle and bundled simulator images. The moment a scheme needs -destination 'platform=iOS Simulator,name=…', Instruments, or certain packaging steps that assume /Applications/Xcode.app paths inside scripts, CLT-only hosts start failing in ways that look like flaky CI rather than a missing product decision. Treat CLT as a deliberate lane, not a default, unless release engineering signs off on simulator-free gates.
platform=iOS Simulator and never shells into Xcode.app/Contents/Developer explicitly, CLT may suffice; the first exception usually means you already need Xcode.app.2. Full Xcode.app on bare metal: multi-repo parallel Archive
Full Xcode.app is the conservative choice for xcodebuild archive, export, and notary-adjacent automation that mirrors local developer machines. On a single bare-metal host running parallel jobs across repositories, isolate workspaces with distinct DERIVED_DATA_PATH roots and avoid sharing one global DerivedData directory — otherwise incremental builds collide and you pay full recompilation under load. Use job-level locks or separate working trees so two pipelines never mutate the same checkout concurrently. For how aggressive parallelism interacts with NVMe and remote cache tiers on the same machine, see our companion FAQ on Bazel and Gradle remote caches, same-host xcodebuild parallelism, and high-NVMe nodes — the same caps apply once you stack multiple xcodebuild workers on one disk.
3. Simulator runtimes: disk, RAM, and why CLT cannot fake them
Simulator runtimes and device support files are large, versioned, and multiply quickly when teams pin different iOS minors across apps. They also compete for RAM when several UI test bundles boot concurrently on one host. Full Xcode installs are the straightforward way to keep xcodebuild test destinations aligned with what Xcode Cloud or local QA uses; CLT-only machines either skip simulators entirely or rely on fragile manual runtime installs that drift from your supported matrix. Budget NVMe as working space plus runtime store plus DerivedData, not “binary size of Xcode.dmg” alone — failed jobs, core dumps, and retained simulator states routinely double apparent needs during incident weeks.
4. xcode-select drift: silent breakage on unattended hosts
Multiple Xcode versions side by side are normal in 2026 pools, but xcode-select -s is global. A maintenance script or ad-hoc SSH session that switches the active developer directory can leave launchd-started runners pointing at the wrong SDK until the next reboot or explicit reset. Prefer per-job DEVELOPER_DIR environment variables (for example DEVELOPER_DIR=/Applications/Xcode_16.2.app/Contents/Developer) in runner wrappers instead of mutating the global select. Emit that path into structured logs at job start so “wrong Xcode” incidents are obvious in minutes, not after a dozen red builds. For patterns on keeping remote daemons and paths predictable on long-lived Macs, OpenClaw remote Mac deployment: install paths, Docker versus native daemons, and common errors illustrates the same operational discipline even outside iOS builds.
5. NVMe footprint: compare CLT-only versus Xcode + simulators
Think in three buckets: toolchain, runtimes, and ephemeral churn. CLT-only images shrink the first bucket but do not remove SDK growth across macOS upgrades. Full Xcode expands the first bucket substantially and often dominates the second once several simulator generations are installed. Ephemeral churn — DerivedData, Archives, CoreSimulator data, module caches — scales with parallel job count and branch fan-out, not with whether you installed CLT or Xcode first. On NVMe, queue depth and sustained write matter more than peak sequential throughput; sizing RAM to reduce duplicate work often saves more wall time than buying the largest single SSD without cache discipline.
- CLT-only baseline: smaller golden image, faster bake times, easiest compliance story if simulators are forbidden — risk is feature gaps for real device and Archive parity.
- Full Xcode without aggressive runtime pruning: largest steady-state disk use, best fidelity to developer laptops — needs automated cleanup of old runtimes and simulators.
- Full Xcode plus heavy multi-repo parallelism: plan separate NVMe volumes or mount points for DerivedData versus toolchain if your orchestrator supports bind mounts; avoids one full disk taking down every lane.
6. Selection checklist for platform owners
Use this list when you document the pool standard for security and finance.
- Does every product line’s CI matrix require simulator destinations or only generic macOS destinations?
- Will multiple Xcode majors coexist on one host, and how will you enforce DEVELOPER_DIR per job?
- What is the worst-case parallel Archive count on a single machine, and what DerivedData layout prevents cross-job corruption?
- After a failed week of builds, do you still have 30–40% free NVMe before paging ops?
- Who owns runtime installation and pruning so simulator disk use stays inside SLO?
Why bare-metal Apple Silicon CI belongs on Mac mini–class hardware
Whether you standardise on CLT lanes, full Xcode pools, or a mix, the underlying host should offer predictable Apple Silicon performance, unified memory bandwidth for linker-heavy archives, and very low idle power for queues that sit mostly idle between bursts — strengths that Mac mini hardware and macOS deliver without the driver lottery common on repurposed PCs. Native toolchains, Gatekeeper, System Integrity Protection, and FileVault give security teams a familiar posture for unattended build machines, while SSH and optional VNC keep the same workflows you use on desk machines.
If you are sizing remote bare-metal nodes for multi-repo xcodebuild and simulator-heavy matrices, Mac mini M4 remains a practical starting point: pair it with explicit DEVELOPER_DIR discipline and NVMe headroom before you scale out horizontally. When you are ready to add dedicated capacity, open the Macstripe home page to compare regions and models against the checklist above.
