Cannot Preview in this file. Simulator was shutdown during an update.

Hi,

Sorry to hear you are having problems getting previews working. There is a known issue with the iOS simulator that shipped with Xcode 26.1 which I am wondering whether you are hitting. If so, using an older sim runtime is the current workaround.

If that is not the version you are seeing this with, then I'd be curious if you are seeing issues also when doing a build+run in Xcode targeting the simulator or if the issues only show up when trying to use previews?

Hi,

I am just a beginner. Currently I have only issues with the preview.

I could not find the option to change the sim runtime of the preview. The only option is to change the target of simulator, not preview. I used the button to change target in top bar and below the preview. But all versions produce the same error.

I have 18.6, 26.0 and 26.1 installed. If I remove 26.1, then the preview complains about missing runtime and I get a download button to install 26.1. Reinstalling 26.1 does not solve the issue.

@Developer Tools Engineer The versions 18.6, 26.0 and 26.1 seem to have the issue. What can I do now?

It looks like the underlying issue is still not resolved, and the only workaround is to give things enough time to complete. My suggestion would be to:

1. build+run your app targeting the iOS simulator. This will launch the simulator app and start booting the simulator
2. wait until the simulator finishes launching and your application is now running in it.

Please note, the bug is that step 2 takes longer than it should so this is where you'll need to exercise patience.

Once that successfully completes you can then quit the simulator, and then try the preview again. This time we'd expect things to work in the preview canvas since the simulator runtime has been "primed".

There are a few different issues that are at play here, so I'll try to untangle it a bit.

Firstly to highlight what I send back to all reports of this symptom. This is what you probably saw in email already, but sharing here for everyone else's benefit:

This symptom ("Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding") occurs when launchd_sim (the principal process that kicks off the simulator) doesn't respond to an initial checkin message within a set time window. It is known to be caused by a variety of issues.

1. Incorrect permissions on system temporary directories:

Some users inadvertently change the permissions on system temporary directories, which can lead to this issue as well as problems in other software. If this is the issue, it can be fixed by running sudo chmod 1777 /private/var/tmp /private/tmp.

1. 3rd Party Security Software:

Some 3rd party security software can cause significant performance delays loading processes from the simulator runtime disk image. To check if this is the cause, you can temporarily disable the security software. If doing so addresses the problem, you should reach out to the vendor for resolution.

1. GateKeeper scanning of the dyld shared cache:

With some versions of Xcode prior to 16.4, the dyld shared cache would be scanned by GateKeeper on OS, simruntime, or weekly Xprotect updates. While being scanned, other processes within the simulator could fail to launch, leading to this error. If you are running an older version of Xcode, please update to Xcode 16.4 or later to have the fix for this issue.

In order for launchd_sim to respond to that initial checkin message, the process itself needs to load and begin execution. This is actually the main point of failure we had been seeing with in #3 above. We could stall out waiting for the process to actually load into memory because one or more dylibs being loaded into memory were not known good / cached.

When we try to load such a dylib, it must be scanned by GateKeeper. Scanning many dylibs can potentially take longer than that timeout window. Also, if the system is scanning the entire simulator runtime (or more specifically creating and/or scanning its dyld shared cache), that long running scan will block the scan of loading an individual one-off dylib. So when we initiate a scan of an entire runtime (which can take 2-3 minutes), that blocks all other GateKeeper activity (loading launchd_sim, mounting a disk image you downloaded from Safari, launching a newly downloaded app, etc). That full runtime scan will happen when the runtime is first installed or when we notice the cached scan has been invalidated (on OS updates or when Xprotect signatures are updated).

With Xcode 16.4+, we should no longer need to scan the entire dyld shared cache.

In addition to the scan time itself, there were a number of I/O performance issues which were impacting reading from the simulator runtime disk image (which itself increased scan time and any other I/O with the disk). These issues were ultimately resolved in macOS 15.6.

So if you're on macOS 15.6+ and using Xcode 16.4+, I would expect the issue to be resolved from the experience perspective.

The remaining work on this front (launchd_sim waiting on dyld shared cache creation / scanning) is focused on increased security hardening while also improving performance.

Note that you can verify that the dyld shared cache is built and ready for use by running xcrun simctl runtime dyld_shared_cache update --all. That will force an update if needed or just return if everything is ready to go. I suggest running xcrun simctl runtime dyld_shared_cache update --all if you run into issues loading launchd_sim and wait for it to finish before trying again.

From your last comment, it seems you're having issues with 26.x as well. Have you verified that you're not hitting one of those other two known causes (directory permissions or kernel extension issues).

Thanks, Jeremy jeremyhu at apple dot com