Killing the Simulator app does not fix xcodebuild

Symptom

The usual reflex — quit or force-kill Simulator.app — does not help. After killing the app, xcodebuild and simctl are still stuck, and a new run wedges the same way.

What it usually looks like

• You killall Simulator (or quit it from the Dock), relaunch, and the hang is exactly as before.
• xcrun simctl list still hangs even with no Simulator window open.
• Devices remain stuck in Booting / Shutting Down regardless of the app.
• Only a logout or reboot seems to clear it — which is heavier than it should be.

Why it happens / likely failure classes

You are killing the wrong process. Simulator.app is just a UI client. The state and lifecycle live in the daemon:

• com.apple.CoreSimulator.CoreSimulatorService is the per-user daemon that actually owns device state, boots, and IPC. If it is wedged, killing the app changes nothing. See CoreSimulatorService deadlock.
• A device stuck mid-transition holds a lock inside the service that the app has no control over.
• launchd relaunches the service on the next simctl call, so a wedged service keeps coming back in the same bad state until it is actually reset.
• The app and the service are different layers — the visible window is not where the hang lives.

Quick checks

# Confirm the hang persists with no Simulator app running
killall Simulator 2>/dev/null
xcrun simctl list devices        # if this still hangs, it's the daemon

# Is the daemon present (and how long has it been up)?
pgrep -lf CoreSimulatorService

# Any devices stuck mid-transition?
xcrun simctl list devices | grep -i 'boot\|shutting'

Manual mitigations

Restart the service, not just the app:

# 1) Quit the UI client
killall Simulator 2>/dev/null || true

# 2) Try a clean shutdown of all devices (may hang if fully wedged)
xcrun simctl shutdown all 2>/dev/null || true

# 3) Restart the actual culprit — launchd respawns it on next use
killall -9 com.apple.CoreSimulator.CoreSimulatorService 2>/dev/null || true

# 4) Verify recovery
xcrun simctl list devices

# 5) Clear stale state once responsive
xcrun simctl delete unavailable

If it re-wedges within minutes, suspect concurrent callers and stop them before retrying. Logging out (the daemon is per-user) clears the most stubborn states without a full reboot.

When XCSteward may help

Knowing what to reset, and doing it deterministically, is part of XCSteward’s design:

• A defined recovery routine that targets CoreSimulatorService — not just the app — so you are not guessing which process to kill under pressure.
• Readiness checks and timeouts that catch a wedged service before a run and turn it into a fast failure plus recovery.
• A single execution lane so the service is not being wedged by concurrent callers in the first place.

Worth testing against this class of failure if “kill the app and retry” has become part of your ritual.

When XCSteward probably will not help

• If the wedge is caused by a bug in a specific CoreSimulator/Xcode build, restarting the service is a workaround, not a fix.
• It cannot resolve host-level resource exhaustion that keeps re-wedging the daemon.
• It does not repair a corrupt simulator installation.

Common questions

What does "Killing the Simulator app does not fix xcodebuild" usually mean?

It usually points to wrong process killed / CoreSimulatorService persistence. You quit or force-kill Simulator.app, but xcodebuild and simctl stay wedged — the hang survives killing the app. 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 "Killing the Simulator app does not fix xcodebuild"?

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

• CoreSimulatorService deadlock and unresponsive simulators — CoreSimulatorService stops responding and the whole simulator subsystem wedges — simctl, Simulator.app, and xcodebuild all block at once.
• simctl commands not responding or hanging — xcrun simctl commands (list, boot, shutdown, spawn) hang indefinitely and never return — even simple ones like simctl list.
• Simulator fails after a previous test run — The first run is fine, but the next test run on the same simulator fails or hangs — state from the previous run leaked into this one.