Post not yet marked as solved
Deleting caches should not be necessary here. I expect that will just cause the issue to recur later.
There are a few causes we've identified for this issue:
The dyld_sim shared cache fails to map into a process within the watchdog timer because it was just recently created and is still being scanned by the system. Deleting the cache will momentarilary address this problem, but you would hit it again the next time the cache is created. Waiting ~2 minutes should allow the scan to complete. Additionally, if you update to Xcode 15.3 Beta 2 or later (released last week), we now avoid attempting to use the cache until that scan is complete.
There is a performance issue reading from the simulator runtime disk images which can result in boot triggering that watchdog timer, especially if I/O is competing with the process that is generating the dyld shared cache. This performance issue has been addressed in macOS 14.4 Beta and later.
As such, I reccomend that users facing this issue please update to macOS 14.4 Beta or later and Xcode 15.3 Beta 2 or later. If you still see this issue, please collect the following tarballs and attach them to a report at http://bugreport.apple.com:
xcrun simctl diagnose
sudo sysdiagnose
Also, if you're able, please enable debug logging via:
defaults write com.apple.CoreSimulator DebugLogging -bool YES
(you can remove the debug logging later with defaults delete com.apple.CoreSimulator DebugLogging)
Note that we've had multiple reports of this issue over the past 6 months, but triage has been difficult in part becuase we have not been getting the logging requested above and by the time the reporter gets around to responding to the request, they are out of the problematic state (because it usually resolves on its own in a few minutes). Please do not assume that someone else is providing the data.
Thanks!
Post not yet marked as solved
FYI: This is fixed in iOS 17.2, which is in Xcode 15.1
Post not yet marked as solved
This checkbox is not relevant with the new device stack, which is why it is disabled. Apoloties for the confusion with the way the new device support stack is interacting with the UI.
If you connect your device via cables, then you will connect to the device over that cable. You will not be connecting over wifi.
There are known issues with certain VPN software causing issues when interacting with devices. Please reach out to the vendor to report the issue inquire about a timeline for receiving an update.
Post not yet marked as solved
We believe that the primary issue causing this behavior is addressed in Xcode 15.0.1. Please update to Xcode 15.0.1 and see if that addresses the issue for you. If it doesn't, please file a bug report with Feedback Assistant including:
1 - sysdiagnose captured while in the state.
2 - xcrun simctl diagnose captured while in the state
Post not yet marked as solved
This error indicates that the target device is locked. Please unlock the device and try again.
Are you accidentally locking your sim? If not, how are you getting into a state where the device is locked? Can you please provide instructions? As reported, this seems to be behaving correctly. We're surfacing the error from the system (The request cannot be completed as the system is locked) when we try to launch the app.
If the system is locked, this is behaving correctly. If the system is NOT locked, then that represents an issue that needs to be investigated. If that is the case, please file a bug report at bugreport.apple.com indicating that you're getting this error even though the device is not locked and provide tarballs from the following, created in-state:
xcrun simctcl diagnose
sudo sysdiagnose
Post marked as Apple Recommended
With iOS 17+, we are using a new device stack (CoreDevice) to communicate with devices. With this new device stack, there is one DDI per platform (as opposed to per OS release). This same device stack will be shared across all versions of Xcode on your system, and installing a newer version of Xcode will update CoreDevice and its DDIs (just like how CoreSimulator is updated, if you are familiar with that).
This effectively means that you now have a supported way of updating the device stack on your system to support newer target OS devices. With CoreDevice, you should be able to debug devices running future versions of iOS using Xcode 15. This may require first installing a newer Xcode in order to install newer CoreDevice and DDIs, so keep that in mind.
Of course, this also means there is a temporary hiccup in which the old unsupported path doesn't work, but the good news is that future-you will have a supported way of doing this which works out-of-the-box, no need to modify your Xcode.app.
iOS simulator runtimes older than iOS 13.7 are not supported on macOS 13. The simulator runtimes supported are determined by both what Xcode supports and what the host OS supports.
Post not yet marked as solved
The permissions issue for the watch symbols should now be set correctly. Please try again. Sorry for the inconvenience.
Post not yet marked as solved
This usually means that Xcode is busy copying debug symbols from the device. This can be impacted by wifi network condition if debugging wirelessly or by the quality of the lightning cable and hubs used to connect the device. Please be sure to connect your iOS device directly to your host mac with an Apple-brand lightning cable to eliminate those variables.
As others have noticed, this issue was triggered by updating a newer versions of macOS. We have a change to address this performance issue when running on newer versions of macOS available in Xcode 13 Beta, available today.
Post not yet marked as solved
If you can get the Xcode beta that contained the iOS Simulator Beta you are interested in, you can copy the beta runtime out of Xcode.app to /Library/Developer/CoreSimulator/Profiles/Runtimes.
Post not yet marked as solved
The Command Line tools for Xcode 12.0 through 12.4 were missing a MacOSX11.sdk symlink in /Library/Developer/CommandLineTools/SDKs.
The Xcode 12.5 Command Line Tools package contains the MacOSX11.sdk
MacPorts base will also search for the "best" SDK in /Library/Developer/CommandLineTools/SDKs and will use any SDK it finds that matches the major OS version, so it sounds like you need to update MacPorts base.
Post not yet marked as solved
The Command Line Tools from Beta 1 are not compatible with the DTK. Please just use the command line tools that are installed on the system with Xcode.
Post not yet marked as solved
Python3 has never been bundled with macOS. We are now providing shims in /usr/bin which allow you to install it with the Command Line Tools.
Can you explain what you mean by "the launched app doesn't appear to find Python to install"?
Post not yet marked as solved
As Quinn mentioned, the suggested approach for using bash is to install your own copy of it (eg: through MacPorts) and configure your user account to use it. The system bash is really old, but you can still use it from /bin/bash.
