Multiple xcodebuild processes on the same Mac

Symptom

More than one xcodebuild (or simctl) process is running at the same time on one Mac, and they start interfering — runs hang, grab the same device, or corrupt each other’s output.

What it usually looks like

• A Makefile target, a script, a watcher, and a manual run all fire xcodebuild concurrently.
• Two runs land on the same simulator (because both used a generic or by-name destination) and fight over it.
• One run boots or erases a device out from under another.
• simctl/CoreSimulator wedges right when several runs overlap. See CoreSimulatorService deadlock.
• A run fails before XCTest attaches with simulator/bootstrap output, even though the build itself completed.
• Failures correlate with how many runs are active, not with any one test.

Why it happens / likely failure classes

The simulator subsystem and default build paths are shared per user, and nothing coordinates independent callers:

• One CoreSimulatorService mediates all simulator work; uncoordinated concurrent operations contend for its locks.
• Devices are global state — one run’s boot/erase/shutdown affects any other run using that device.
• Implicit destinations collide when two runs resolve generic/platform=iOS Simulator or the same device by name. See xcodebuild hangs resolving the destination.
• Shared DerivedData / result paths overwrite each other. See DerivedData contamination.
• No backpressure — nothing stops the Nth run from starting on a saturated host.

Quick checks

# How many simulator-related processes are running right now?
pgrep -lf 'xcodebuild|simctl|Simulator'

# Are multiple runs sharing one booted device?
xcrun simctl list devices | grep -i booted

# Is the subsystem still responsive under the load?
time xcrun simctl list devices available

If failures cluster when several of these are active at once, this is contention, not flaky tests.

Manual mitigations

• Serialize simulator work so one job runs at a time — e.g. a file lock so others queue instead of colliding:

  (
    flock -w 1800 9 || { echo "another run holds the lock"; exit 1; }
    xcodebuild test -scheme YourScheme \
      -destination "platform=iOS Simulator,id=<UDID>"
  ) 9>/tmp/xcsim.lock

• Pin each run to its own device by UDID — never a generic/by-name destination shared across runs.

• Isolate artifacts per run (-derivedDataPath, -resultBundlePath).

• Cap concurrency so the host is not saturated, and clean up between runs.

These work but become a pile of glue to maintain — which is the gap XCSteward aims to fill.

When XCSteward may help

Coordinating concurrent work on one Mac is a core design goal:

• A single controlled execution lane with a queue, so independent callers submit jobs that run in a coordinated order instead of colliding.
• Guardrails that stop two runs from grabbing the same device or hammering CoreSimulator at once.
• Isolated artifacts and deterministic cleanup so overlapping runs do not corrupt each other.
• Legible wait and monitoring commands for humans: submit --wait prints the job id, status/log/watch/follow commands, job directory, and compact updates; status <job-id> --watch [--interval <seconds>] polls until terminal; logs --follow streams the combined log.
• Structured summaries for scripts and agents through --json, phase-aware --progress, status <job-id> --watch --json, explain <job-id> --json, metadata, labels, and repeatable submit --env KEY=VALUE for per-run environment injection.
• Separate bootstrap diagnosis for pre-XCTest failures: if setup fails before the runner attaches, XCSteward reports runner_bootstrap_failure rather than treating it as a real test execution failure.

A strong candidate to test against this class of failure.

When XCSteward probably will not help

• It does not make your tests themselves parallel-safe — shared backends or fixtures are your responsibility.
• It is not a distributed grid; it coordinates work on one Mac, it does not add machines.
• It will not fix genuinely broken tests that fail on their own.

Common questions

What does "Multiple xcodebuild processes on the same Mac" usually mean?

It usually points to concurrent process contention / shared-state collisions. Several xcodebuild/simctl processes run at once on one Mac and start colliding over simulators, destinations, and build state. Start by checking simulator readiness, destination selection, CoreSimulator/simctl responsiveness, and whether another xcodebuild, simctl, or Simulator process is already active before treating it as a test-code failure.

Can XCSteward help with "Multiple xcodebuild processes on the same Mac"?

This is a strong fit when the failure is operational: simulator readiness, destination resolution, CoreSimulator responsiveness, cleanup, timeouts, or local concurrency. XCSteward may help by making those phases bounded, serialized, and easier to inspect. It will not fix broken tests, code signing, missing runtimes, or vendor image bugs.

What should I check first?

Check whether xcrun simctl commands return promptly, whether xcodebuild can resolve a concrete simulator destination, whether the device is truly ready rather than merely Booted, and whether concurrent agents, scripts, or manual runs are touching the same simulator subsystem.

Related failure modes

• Coding agents running iOS simulator tests on one Mac — Coding agents and scripts run xcodebuild/Simulator tests concurrently on one Mac, and runs start colliding, wedging, and failing unpredictably.
• fastlane scan hangs with parallel testing — fastlane scan or xcodebuild hangs once parallel testing spins up multiple simulator clones that contend for the simulator subsystem.
• DerivedData contamination between iOS test runs — Test runs interfere through shared DerivedData, result bundles, or logs — you get stale builds, overwritten .xcresult, or results from the wrong run.