iOS Simulator tool: claude-ios-sim crashes 100% of the time on first Metal/Core Image init (macOS 27 beta)
claude-ios-sim crashes 100% of the time on first Metal/Core Image init (macOS 27 beta)
Summary
The iOS Simulator helper binary bundled with Claude Code (claude-ios-sim,
bundle ID com.anthropic.claude.ios-sim) crashes with SIGABRT every
single time it is used on this machine. The crash happens during Core
Image's lazy Metal initialization, inside Apple's own Metal framework
internals — but it is reproducible only with this specific binary;
no other app on the same machine (Xcode, Safari, other third-party
Metal/Core Image users) is affected.
This makes the "attach simulator panel" / live screenshot feature of the
iOS Simulator tool completely unusable — every screenshot call (and
anything else routed through this helper) fails immediately.
Environment
- Mac: Mac Studio, Apple M4 Max, 64 GB RAM
- macOS: 27.0, build 26A5425a (beta)
- Xcode: Xcode-beta.app only installed,
xcode-selectcorrectly
pointed at it
- Claude Code: desktop app, iOS Simulator tool
Reproduction
- Use the Claude Code iOS Simulator tool's
attachorscreenshot
action against any booted simulator (reproduced on iPad Pro 11-inch
(M5) and iPad Air 11-inch (M4), so it isn't device-specific).
claude-ios-simcrashes immediately, every time.
Frequency: 45 separate crash reports for this exact process,
spanning 2026-09-04 17:28 through 2026-09-05 23:10 (i.e., it
predates this specific session by at least a day and has never
succeeded once in that window). A full OS reboot and re-granting
Screen Recording/Accessibility permissions (both plausible suspects)
had no effect on this crash — those fixed a separate, unrelated
CoreSimulatorService issue but not this one.
Crash signature
- Process:
claude-ios-sim - Signal:
SIGABRT(EXC_CRASH) - Uncaught Objective-C exception thrown from inside Apple's Metal
framework while Core Image lazily initializes its Metal context.
Key frames (crashing thread, most relevant portion, newest-first):
__pthread_kill
pthread_kill
abort
__abort_message
demangling_terminate_handler()
_objc_terminate()
std::__terminate(void (*)())
__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*)
__cxa_throw
objc_exception_throw
-[__NSPlaceholderArray initWithObjects:count:]
+[NSArray arrayWithObjects:count:]
__39-[_MTLDevice recordBinaryArchiveUsage:]_block_invoke
_dispatch_client_callout
_dispatch_once_callout
-[_MTLDevice recordBinaryArchiveUsage:]
-[_MTLBinaryArchive loadFromURL:error:]
-[_MTLBinaryArchive initWithOptions:device:url:error:]
+[CIKernelLibrary(Internal) internalBinaryArchiveWithName:device:]
CI::PrecompiledUberFunctions::PrecompiledUberFunctions(CI::MetalContext const*)
CI::new_uber_functions(CI::MetalContext const*)
CI::MetalContext::init(id<MTLCommandQueue>, char const*)
Why this looks like a claude-ios-sim-specific issue, not a system/OS bug
- Searched all crash reports in
~/Library/Logs/DiagnosticReports
(including Retired/) for the same _MTLBinaryArchive /
recordBinaryArchiveUsage signature — every single match is
claude-ios-sim. No system process or other third-party app
(several other Metal-using apps are installed and in active use on
this machine) shows this crash.
- This strongly suggests
claude-ios-simships or references a
precompiled Metal binary archive that is incompatible with the
Metal/Core Image runtime on macOS 27 (beta), rather than a
general OS-level Metal regression.
Impact
The simulator panel (attach) and screenshot/interactive-input
actions are entirely non-functional as a result — every call fails
with "Claude Code iOS Simulator is restarting after a crash." The only
usable workaround is driving the simulator directly via xcrun simctl
from the command line, which doesn't go through this helper at all.
Suggested next step
Since this is 100% reproducible and isolated to one binary, it should
be straightforward to repro directly against a macOS 27 beta + Apple
Silicon (M4) environment. Given the age of the crash reports (starting
before this diagnostic session), it likely affects any user on this
OS/Xcode beta combination, not just this machine.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗