iOS Simulator panel unusable on Xcode 27: hardcoded PrivateFrameworks path + Metal abort in claude-ios-sim helper

Status Closed — not planned
Maintainer reply None cached
Activity 4 comments · opened Jul 22, 2026 · closed Jul 23, 2026

iOS Simulator panel unusable on Xcode 27 — two distinct bugs

Two independent defects block the in-app iOS Simulator on a stock Xcode 27 / macOS 27 machine.
Bug 1 has a working local workaround; Bug 2 does not.

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.1 |
| Helper | /Applications/Claude.app/Contents/Helpers/Claude iOS Sim.app/Contents/MacOS/claude-ios-sim |
| macOS | 27.0 (26A5388g) |
| Hardware | Mac16,8 — Apple M4 Pro, 16 cores, Metal 4 |
| Xcode | 27.0 beta, build 27A5228h, installed at /Applications/Xcode.app (bundle renamed from Xcode-beta.app, which is why the path says Xcode.app) |
| iOS runtimes | 27.0 (24A5380i) and 27.0 (24A5390f) — both reproduce |
| SIP | enabled |

---

Bug 1 — attach fails: hardcoded pre-Xcode-27 framework path

Symptom

Every attach fails immediately:

Could not attach simulator panel: Failed to read the device's state:
Simulator framework failed to load: Error Domain=com.facebook.FBControlCore Code=0
"Attempting to load a file at path
'/Applications/Xcode.app/Contents/Developer/Library/PrivateFrameworks/SimulatorKit.framework',
but it does not exist"

Cause

Xcode 27 relocated its private frameworks. Contents/Developer/Library/PrivateFrameworks/
no longer exists; SimulatorKit.framework, DVTFoundation.framework,
DVTDeviceFoundation.framework and siblings now live in Contents/SharedFrameworks/.

Xcode 27's actual Contents/Developer/Library/ contains only:

Frameworks
Previews
Xcode

FBControlCore still derives the old $DEVELOPER_DIR/Library/PrivateFrameworks path.

Reproduction

  1. Install Xcode 27.0 beta (27A5228h) as the only Xcode.
  2. Boot any simulator.
  3. Call attach.

Workaround (confirmed working)

ln -s ../../SharedFrameworks /Applications/Xcode.app/Contents/Developer/Library/PrivateFrameworks

attach then succeeds and the panel opens with the device bound and correct point dimensions.
This modifies the Xcode bundle, so it is not a fix we can ship to users — and Xcode updates drop it.

Verification that the iOS runtime is NOT the variable

Tested with the symlink removed against a freshly created device on the newly released
24A5390f runtime
— identical failure. Expected, since the frameworks ship in Xcode.app,
not in the runtime. Both runtimes behave the same.

---

Bug 2 — helper aborts in Metal on connect (no workaround)

Symptom

With Bug 1 worked around, attach succeeds and the panel renders (device name, controls,
Encoding: H.264, black screen), then the helper aborts after ~1–2s. Every subsequent call returns:

screenshot failed: Claude Code iOS Simulator is restarting after a crash. Try again in 1s.

…in a permanent loop. 9+ crash reports generated across attempts, all with an identical signature.

Crash signature

Termination:  SIGABRT — Abort trap: 6   (asi: "abort() called")

libsystem_c.dylib      abort
libc++abi.dylib        demangling_terminate_handler()
libobjc.A.dylib        _objc_terminate()
libc++abi.dylib        __cxa_throw
libobjc.A.dylib        objc_exception_throw
CoreFoundation         -[__NSPlaceholderArray initWithObjects:count:]
CoreFoundation         +[NSArray arrayWithObjects:count:]
Metal                  __39-[_MTLDevice recordBinaryArchiveUsage:]_block_invoke
libdispatch.dylib      _dispatch_client_callout
libdispatch.dylib      _dispatch_once_callout
Metal                  -[_MTLDevice recordBinaryArchiveUsage:]

An uncaught ObjC exception — a nil entering +[NSArray arrayWithObjects:count:] inside Metal's
binary-archive bookkeeping. Loaded images at crash: SimulatorKit, CoreSimulator,
CoreSimulatorUtilities, FBControlCore, FBSimulatorControl, DVTDownloads, Metal.

Key finding: NOT encoding-related

Initially suspected the H.264 path, since the panel defaults to Encoding: H.264 while the app's
own feature flags report iosSimulatorH264: unsupported — "iOS Simulator is disabled by its
rollout flag"
. Ruled out:

  • Selecting JPEG in the panel's Encoding dropdown — same crash. The setting also does not

persist across relaunch (not in Local Storage; only tile layout is), so it resets to H.264.

  • Calling screenshot with the panel fully detached and no video stream at all — same crash.

The dispatch_once frame confirms this is a one-time Metal init on the device-connect path,
before any encoding choice is consulted.

Ruled out

  • Endpoint security interference — Sophos is present, but the crash is a self-inflicted

SIGABRT from an uncaught ObjC exception with a full in-process backtrace, not an external
SIGKILL/SIGTERM. The helper also loads all its frameworks successfully first.

  • iOS runtime version — reproduces on both 24A5380i and 24A5390f.
  • Device model / device state — reproduces on a brand-new, never-booted device.
  • Stale Xcode-select stateDEVELOPER_DIR corrected to the live Xcode before all tests.

What we could not try

The helper exposes no lever: only --print-path as a CLI flag, no preferences domain
(com.anthropic.claude-ios-sim does not exist), and no encoding/Metal keys in the app's
defaults or Local Storage. It's code-signed inside Claude.app, so it can't be patched locally.

Suggested fix

-[_MTLDevice recordBinaryArchiveUsage:] throwing on a nil suggests a MTLBinaryArchive
created with a nil or unset URL, on the helper's first MTLDevice use. Likely worth guarding
the archive setup and/or wrapping the connect-path Metal init in an exception handler so a
Metal failure degrades to no-video rather than aborting the process.

---

Attachments

crash-logs/ — 3 representative claude-ios-sim .ips reports (username replaced with USER).
All 9 share the identical signature above.

Net effect

On a current Xcode 27 machine the in-app simulator is fully unusable: Bug 1 blocks attach
outright, and past it Bug 2 blocks every action. simctl drives the same simulators fine,
so the simulators themselves are healthy.

---

Correction (edited): this report originally said Xcode 27.0 release. That was wrong — it is Xcode 27.0 beta, build 27A5228h. The bundle had been renamed from Xcode-beta.app to Xcode.app locally, so the path was misleading. Everything else stands; Bug 1 is a real framework-layout change in this seed regardless.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗