I have the same problem. Has anyone found any workarounds for this? For example if you roll back your deployment target to iOS 14?

Ok, I have also reached out to Developer Technical Support and they recommend I file a bug so I did as well. My app is dependent on this functionality so I am stuck until they can resolve.

Just checking in to see if there has been any update on this issue? I am experiencing this in 18.2 simulator but this is slowing down my app testing and I spent about 3 hours trying to debug this. :/

Filed Feedback: FB17663195

In your SceneDelegate... import CloudKit then add this func... func windowScene(_ windowScene: UIWindowScene, userDidAcceptCloudKitShareWith cloudKitShareMetadata: CKShare.Metadata) { // Call your function that accepts the share and pass it the metadata that is passed in. acceptShare(with: cloudKitShareMetadata) }

In this case I was using "vend" to mean "give" or "make available to" my app.

I also have this problem and I am going crazy, did a full macos restore (didn't wipe the HD yet) and it keeps doing that. Also noticed every 11 seconds a new SimRuntimeBundle is created in Macintosh HD > Library > Developer > CoreSimulator > Cryptex > Images > mnt folder very strange indeed.

Here is a summary of my findings so far working with AI: The Bug: macOS Tahoe 26.4 triggers a loop in the CoreSimulator subsystem where a new SimRuntimeBundle is created in /Library/Developer/CoreSimulator/Cryptex/Images/mnt/ every 11 seconds. This accumulates thousands of files and bloats the images.plist manifest. Why Xcode Hangs: When Xcode launches, it starts CoreSimulatorService, which spawns a helper daemon called simdiskimaged via XPC. simdiskimaged is responsible for managing simulator disk images and runtimes. On startup, it tries to load and validate the entire contents of images.plist and the Cryptex directory. Because of the runaway loop, there are now 7,000+ files and a bloated manifest to parse. simdiskimaged exceeds its hardcoded 20MB jetsam memory limit and gets killed by the system (SIGKILL/-9). CoreSimulatorService sent a synchronous XPC message to simdiskimaged and is now waiting for a reply that will never come — it hangs forever on mach_msg2_trap. Everything downstream hangs: xcrun simctl, Xcode's SDK detection, simulator availability — all of it. The Evidence: simdiskimaged was killed 1,165 times with exit reason JETSAM_REASON_MEMORY_PERPROCESSLIMIT Its jetsam limit is 20MB active / 15MB inactive The CoreSimulatorService stack trace shows a single thread blocked on SimDiskImageManager serviceVersionWithError: → xpc_connection_send_message_with_reply_sync → mach_msg2_trap The service is programmatically submitted by CoreSimulatorService (no on-disk plist), so the memory limit can't be user-configured

Ok, here is my step by step (what I think is) a solution guide... (worked for me) Fix: Xcode Hangs on macOS Tahoe 26.4 (SDKs "Status Unavailable") The Problem macOS Tahoe 26.4 introduces a bug where a CoreSimulator subprocess (simdiskimaged) repeatedly exceeds its 20MB memory limit and gets killed by the system. This causes CoreSimulatorService to hang indefinitely, which in turn causes Xcode to freeze, SDKs to show "status unavailable," and all simulators to become inaccessible. The root cause is a runaway loop that creates new SimRuntimeBundle files every 11 seconds in /Library/Developer/CoreSimulator/Cryptex/Images/mnt/, bloating the state that simdiskimaged must load on startup beyond its jetsam memory limit. The Fix Step 1 — Grant Terminal Full Disk Access The files that need to be deleted are protected by TCC (Transparency, Consent, and Control). Without this step, sudo rm will return "Operation not permitted." Open System Settings → Privacy & Security → Full Disk Access Click the + button Add Terminal (located in /Applications/Utilities/) Toggle it on Quit and relaunch Terminal Step 2 — Force Quit Xcode Close Xcode completely. Force Quit if necessary. Step 3 — Delete the Corrupted CoreSimulator State Run the following commands in Terminal: sudo rm /Library/Developer/CoreSimulator/Images/images.plist sudo rm -rf /Library/Developer/CoreSimulator/Cryptex Step 4 — Reboot Restart your Mac. Step 5 — Verify the Fix Open Terminal and run: xcrun simctl list devices This should return a list of devices (marked "unavailable") without hanging. If it responds, the daemon is healthy again. Step 6 — Clean Up Stale Runtime Data Before re-downloading runtimes, clear any stale references that may cause duplicate errors: xcrun simctl runtime delete all sudo rm -rf /Library/Developer/CoreSimulator/Images/ sudo rm -rf ~/Library/Developer/CoreSimulator/Devices/ Step 7 — Re-Download Simulator Runtimes Launch Xcode Go to Xcode → Settings → Platforms Download the simulator runtime(s) you need (e.g., iOS 26.4) Xcode should now function normally. Notes You do not need to reinstall Xcode or downgrade macOS. Consider filing a Feedback with Apple referencing the 20MB jetsam limit on simdiskimaged and the uncapped SimRuntimeBundle creation loop. This fix was developed by diagnosing the issue from the ground up: identifying the deadlocked XPC call in CoreSimulatorService, tracing it to the killed simdiskimaged daemon, and discovering the jetsam memory pressure caused by accumulated runtime state. You may want to remove full disk access from your terminal when you are done.