iOS 27 & watchOS 27 Simulator runtimes download but never register (signatureState never becomes "verified")

Question

Sheharyar_rr OP

Created 1w

Replies 1

Boosts 1

Participants 1

Environment

Xcode 27.0 (Build 27A5194q)
macOS 27.0 (Build 26A5353q), Apple Silicon
Command Line Tools 27.0

Summary The iOS 27.0 (24A5355p) and watchOS 27.0 (24R5289n) Simulator runtimes download and mount successfully, but never register as usable. Both fail in exactly the same way. Every older runtime (e.g. iOS 26.2 / 23C54) works fine.

What I see xcrun simctl list runtimes does NOT list iOS 27 or watchOS 27. They appear only under xcrun simctl runtime list (disk images), as:

iOS 27.0 (24A5355p)
    State: Ready
    Image Kind: Patchable Cryptex Disk Image
    Signature State: Unknown
    Mount Path: /private/var/run/com.apple.security.cryptexd/mnt/...

They never get promoted to /Library/Developer/CoreSimulator/Volumes/ the way working runtimes do.

Where it actually breaks

simdiskimaged finds and mounts the runtime with no error: "Found runtime bundle on disk image at: .../iOS 27.0.simruntime" "Got supported architectures back ... arm64"
The runtime IS present in /Library/Developer/CoreSimulator/Images/images.plist, and its cryptex personalization manifest exists in /Library/Developer/CoreSimulator/Cryptex/Personalization/.
BUT iOS 27 (24A5355p) and watchOS 27 (24R5289n) are the ONLY two images in the index whose signatureState is not verified. Every other runtime shows signatureState => verified. CoreSimulatorService therefore never registers them.

So the cryptex mounts and the personalization ticket is present, but signature verification against that manifest never completes for these two new runtimes.

Things I have already tried (no change)

Deleted and re-downloaded the runtime via xcodebuild -downloadPlatform iOS (fresh image, identical result)
Restarted CoreSimulatorService; ran sudo xcodebuild -runFirstLaunch
Full reboot (cryptex re-mounts at boot but is still never verified/promoted)
Deleted images.plist and let it rebuild
Verified: system clock correct; gs.apple.com and ppq.apple.com reachable on 443; ~85 GB free disk; iphoneos27.0 SDK build (24A5355p) matches the downloaded runtime; simctl runtime match list shows 24A5355p as the chosen/default runtime.

The standalone Simulator runtime .dmg for iOS 27 is not yet on Developer Downloads, so xcrun simctl runtime add isn't an option.

Questions

Is anyone else seeing iOS 27 / watchOS 27 runtimes stuck at Signature State: Unknown / signatureState != verified on this beta?
Is there a way to force re-verification of an already-downloaded cryptex runtime without a standalone .dmg?
Is this a known issue in the current beta? (FB filed.)

Thanks!

Answered by Sheharyar_rr in 890981022

UPDATE — SOLVED (workaround found, with an assist from Claude)

I'd been throwing this at Claude Code for a while with Opus 4.8 on max effort and it kept dead-ending at "beta bug, file Feedback and wait." Retried with the new Fable 5 model and it diagnosed and fixed it end-to-end in one session. After ruling out the usual suspects (re-download, reboot, runFirstLaunch, images.plist rebuild, clock, disk space), it found the real error:

xcrun simctl runtime verify <image-uuid>
→ Signature verification failed: -67054 "a sealed resource is missing or invalid"

So the new arm64-only "patchable cryptex" delivery path is what's broken on this beta — the runtime content itself is fine. It then noticed the MobileAsset download contains a plain .dmg inside it, and feeding that to the old staged-disk-image pipeline bypasses the broken path entirely:

xcrun simctl runtime add /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/<hash>.asset/AssetData/Restore/<file>.dmg

Result: runtime registers as Verified, the full iOS 27 device fleet auto-creates, and an iPhone 17 Pro sim boots fine. The watchOS 27 runtime had the identical bug — same fix via com_apple_MobileAsset_watchOSSimulatorRuntime.

(The APFS clone means it uses ~no extra disk. The old broken cryptex image stays listed as "Unusable - Cryptex Mount Preferred" — harmless; delete it by UUID if a reboot ever regresses the registration.)

Honestly impressed — Opus 4.8 on max effort couldn't crack this after multiple attempts, but Fable 5 went from "simulator won't show up" to root-causing a cryptex code-signing failure and finding a working bypass in one session. FB filed with the -67054 error so Apple can fix the patchable path.

Answer 1