Desktop iOS Simulator panel crash-loops on macOS 27 beta (BitmapStream Metal/CoreImage abort); SimulatorKit relocated in Xcode 27 beta 4

Summary

The Claude Desktop iOS Simulator panel cannot stream on macOS 27 beta: the claude-ios-sim helper crash-loops (SIGABRT) on its com.facebook.FBSimulatorControl.BitmapStream thread every time a stream starts. The panel shows "Claude Code iOS Simulator is restarting after a crash. Try again in 1s." indefinitely. There are two distinct layers, reported together because the second is only reachable after working around the first.

Environment

• macOS 27.0 beta (build 26A5388g), Apple Silicon (M5, MacBook Air)
• Claude Desktop with the iOS Simulator panel (helper: /Applications/Claude.app/Contents/Helpers/Claude iOS Sim.app, linked SDK 26.1)
• Xcode 27.0 Beta 4 (27A5228h) selected via xcode-select; Xcode 26.6.0 also installed
• Simulators tried: iPhone 17 on iOS 27.0 and iOS 26.5 — identical crash on both

Bug 1 — SimulatorKit relocated in Xcode 27 beta 4 (clean failure)

Xcode 27 beta 4 moved SimulatorKit.framework from Contents/Developer/Library/PrivateFrameworks/ to Contents/SharedFrameworks/. The helper's FBControlCore only looks at the old path, so attach fails cleanly:

Simulator framework failed to load: Error Domain=com.facebook.FBControlCore Code=0
"Attempting to load a file at path '/Applications/Xcode-27.0.0-Beta.4.app/Contents/Developer/Library/PrivateFrameworks/SimulatorKit.framework', but it does not exist"

Independently confirmed by other FBSimulatorControl-based tools: software-mansion/argent#406, lycorp-jp/sim-use. Workaround that restores loading:

mkdir -p "/Applications/Xcode-27.0.0-Beta.4.app/Contents/Developer/Library/PrivateFrameworks"
ln -s ../../../SharedFrameworks/SimulatorKit.framework \
  "/Applications/Xcode-27.0.0-Beta.4.app/Contents/Developer/Library/PrivateFrameworks/SimulatorKit.framework"

Suggested fix: probe Contents/SharedFrameworks/ as a fallback location.

Bug 2 — BitmapStream crash-loop once SimulatorKit loads (the blocker)

With SimulatorKit loading, attach reports success, the stream starts, and the helper aborts within ~1–2 s, every time. The headless screenshot action crashes identically (FBSurfaceImageGenerator.image() → same stack). Faulting stack (from ~/Library/Logs/DiagnosticReports/claude-ios-sim-*.ips):

Thread: com.facebook.FBSimulatorControl.BitmapStream (SIGABRT, uncaught NSException)
CoreFoundation  -[__NSPlaceholderArray initWithObjects:count:]   ← nil object
CoreFoundation  +[NSArray arrayWithObjects:count:]
Metal           __39-[_MTLDevice recordBinaryArchiveUsage:]_block_invoke
Metal           -[_MTLDevice recordBinaryArchiveUsage:]           (dispatch_once)
Metal           -[_MTLBinaryArchive loadFromURL:error:]
Metal           -[_MTLBinaryArchive initWithOptions:device:url:error:]
CoreImage       +[CIKernelLibrary(Internal) internalBinaryArchiveWithName:device:]
CoreImage       CI::PrecompiledUberFunctions::PrecompiledUberFunctions(CI::MetalContext const*)
CoreImage       CI::MetalContext::init
CoreImage       +[CIContext contextWithMTLDevice:options:]
FBSimulatorControl  FBSurfaceImageGenerator.image() / BitmapStream
claude-ios-sim  SimulatorBridge.screenshot(udid:)   (screenshot variant; stream variant crashes in BitmapStream)

Ruled out experimentally

I tried to reproduce the CoreImage/Metal init outside the helper. A minimal CIContext(mtlDevice:) + render succeeds in every variant I could construct:

• unsandboxed, and under the helper's exact sandbox profile (claude-ios-sim.sb, same -D params, exec'd from an allowed path)
• with the helper's exact captured environment (incl. __CFBundleIdentifier=com.anthropic.claudefordesktop, MallocNanoZone=0, minimal PATH)
• linked against SDK 27.0 and SDK 26.5 (via Xcode 26.6.0's toolchain)
• with a fresh binary UUID run sandboxed-first (cold Metal shader cache; no sandbox denials logged)
• with FBSimulatorControl-style options: .workingColorSpace: NSNull(), .outputColorSpace: NSNull()
• against both an iOS 27.0 and an iOS 26.5 simulator (helper crashes on both; repros pass)

So the trigger is specific to the shipped helper's runtime state on this OS — not the sandbox profile, environment, linked-SDK choice, shader cache, colorspace options, or simulator runtime. No public env-var exists to force CoreImage software rendering process-wide (kCIContextUseSoftwareRenderer is an in-code option only), so there is no user-side workaround; the panel is unusable on this OS while build/launch actions work fine.

Happy to provide full .ips files, sysdiagnose, or run an instrumented helper build.