iOS Simulator control tool: attach/boot times out on Xcode 27 — targets legacy Simulator.app, which no longer exists (replaced by DeviceHub.app / com.apple.dt.Devices)

Status Fixed / completed
Maintainer reply None cached
Activity 1 comment · opened Sep 17, 2026 · closed Sep 29, 2026

What happens

mcp__Claude_Code_iOS_Simulator__control attach (and the launch action's
implicit boot step) fails to open the live simulator panel on Xcode 27, even
when the target device is genuinely booted and healthy:

Could not attach simulator panel: Failed to boot the device: Simulator
'<UDID>' did not finish booting within 120s. It may still be booting.
Try attaching again in a minute.

This happens regardless of how long you wait, or how many times you retry —
xcrun simctl bootstatus <udid> -b confirms the device is fully booted
(SpringBoard running, CoreSimulator reports Booted) the entire time. The
tool's own boot/attach step never reaches that state from its side.

Root cause: the tool's attach/boot path targets the legacy Simulator.app
(bundle id com.apple.iphonesimulator), which no longer exists on this
Xcode release. That specific problem is called out (and ruled out as their
cause) in #94554 — this issue is filing the DeviceHub-identity problem they
set aside, since it's a distinct root cause with its own repro and evidence.

Environment

  • Claude Desktop / Claude Code (Code tab), current as of 2026-09-17
  • macOS 27 (Darwin 27.0.0), Apple silicon
  • Xcode 27.0 (build 27A266a)
  • iOS 26.5 simulator runtime, iPhone 17 Pro

Evidence

  1. xcrun simctl boot <device> + bootstatus -b both succeed and report

Booted immediately; ps aux shows the device's SpringBoard running.

  1. attach still times out after 120s with the message above, every time.
  2. Legacy Simulator.app is completely unregistered:

``
$ /System/Library/.../lsregister -dump | grep -i com.apple.iphonesimulator
(no output)
$ find /Applications /Library/Developer -iname "Simulator.app"
(no output)
``

  1. Xcode 27 ships a replacement at the exact path the old app used to occupy,

under a different bundle id and app architecture:
``
/Applications/Xcode.app/Contents/Applications/DeviceHub.app
CFBundleIdentifier: com.apple.dt.Devices
CFBundleDisplayName: DeviceHub (alt names: "Devices", "Device Hub")
CFBundleExecutable: DevicesTrampoline (thin launcher)
`
DeviceHub is no longer a standalone simulator app — it's a unified
device-management shell (links
DeviceKit.framework, CoreDevice.framework,
CoreDeviceUtilities.framework) that also covers physical devices. iOS
Simulator support itself now lives one level deeper, as an in-process
plugin:
`
.../DeviceKit.framework/Versions/A/PlugIns/SimulatorDeviceKitPlugin.devicekitplugin
``

  1. Manually launching the new app doesn't help either — open -a DeviceHub

(or open -b com.apple.dt.Devices) before retrying attach still times
out the same way, confirming the tool isn't just failing to find the
app, it's driving a boot/attach protocol the new app doesn't answer to
(different args/IPC surface than the old -CurrentDeviceUDID convention).

  1. xcrun simctl help has no subcommand to open/attach a GUI window to a

device in this Xcode release either — that responsibility has always
lived in the external app, and that app's identity is what changed.

Impact

On Xcode 27, attach/launch are unusable for opening the live panel —
100% reproducible, not a race or a flaky timeout. Headless actions that
don't need the panel (screenshot, tap, inspect, etc. — per the tool's
own docs) may still be unaffected since they don't depend on this boot path,
but I did not get far enough to verify that split once attach itself never
succeeds.

Ask

Update the simulator-panel attach/boot logic to target DeviceHub.app
(com.apple.dt.Devices) instead of (or in addition to, for older Xcode
versions) Simulator.app (com.apple.iphonesimulator) when running on
Xcode 27+.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗