I hope this time the developer forums are not going to "ignore" my response... But anyway I will make it short:There is a solution which I've found today: Make sure in your targets Run Scheme, the option "Debug XPC services used by this application" is disabled!

Just to let you know: I do have the exact same problem with Xcode 12 beta 5.

I have the same problem here and now with Xcode 12 GM! When launching a debug session on a device it takes more than 75 seconds until the UI appears on the device. Clearing ~/Library/Developer/Xcode/iOS DeviceSupport/ does help indeed! I will try to keep in mind: beside clearing out DerivedData it may also be helpful to clear the content of iOS DeviceSupport. Is this a broken system?

Is this on a physical device? If yes, the slow launch times might be the same problem as in this three Xcode 12 Beta 4, long time for Debug launch on iOS 14 b4 - https://developer.apple.com/forums/thread/656609. What helped for me: Deleting the content of ~/Library/Developer/Xcode/iOS DeviceSupport/ (This seems to be a cache of installed dynamic libraries and frameworks. Probably to be able to "symbolicate" the call stacks.)

Hmm... even though I had the problem for a long time, I have now found the solution myself: do not take a screenshot from the app/XCUIApplication but from screen/XCUIScreen.main So I changed takeScreenshot to be func takeScreenshot(name: String = "Screenshot") {     let screenshot = XCUIScreen.main.screenshot()     let attachment = XCTAttachment(screenshot: screenshot)     attachment.name = name     attachment.lifetime = .keepAlways     add(attachment) }

Hi Alex I'm also annoyed by this bug and filed a feedback >2 weeks ago (FB9208491). Today I went to tracking down the problem and even found a doable workaround (later more on this). First, the Spotlight process is spilling a lot of warnings to the log. You can check the "Console" app and see the logs for your simulator device: Thousands of "No system placeholder found with identifier ...". It seems that Spotlight is stuck in some strange loop, trying to find some placeholders and generating logs. One way to resolve this: Kill the Spotlight process in Activity Monitor. But whenever Spotlight is triggered in the Simulator, it will start again. Also when you restart the simulator instance, this will start again. Therefore I tracked down the root cause for the error and found it in "Siri suggestions": It seems that for an unknown reason, Siri suggests on Simulator devices the use of "Mail" and "Tips" app. But those apps do not exist in the Simulator environment! Therefore Spotlight cannot find the apps icon... So the real workaround which works for me: Go to "Settings" > "Siri & Search" Disable anything related to "Siri suggestions". Restart the device After restarting, the Spotlight search can be triggered without any issue. No more CPU cycles wasted to logging about missing placeholders. I filed this as a new feedback (FB9335101) to Apple, in the hope somebody fixes it soon. One caveat: It is not possible to apply this workaround for the Simulator devices used by SwiftUI previews. So if you use SwiftUI previews, you will have to stop/kill the Spotlight process yourself using the Activity Monitor app. If somebody finds a solution to configure the SwiftUI Preview simulator instances (which can be found ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices) I would gladly learn about it. Kind regards Philipp

As I haven't found a way to edit my first answer above: I have found a solution to fix the SwiftUI Preview simulators Find all com.apple.suggestions.plist files in ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices/ Set the key SuggestionsAppLibraryEnabled to NO The following script does the job nicely: cd ~/Library/Developer/Xcode/UserData/Previews/Simulator\ Devices/ find . -name com.apple.suggestions.plist -exec plutil -replace SuggestionsAppLibraryEnabled -bool NO {} ";"      This approach also works for regular Simulator instances. Instead of opening "Settings" and disabling "Suggestions on Home Screen", you can use below script to do the job: cd ~/Library/Developer/CoreSimulator/Devices  find . -name com.apple.suggestions.plist -exec plutil -replace SuggestionsAppLibraryEnabled -bool NO {} ";"

Just to let everybody know who stumble over your example: it does work perfectly fine. (I was looking for an example and found yours :-))

The problem still appears in macOS Monterey beta 6. You cannot handle double-click without loosing/breaking the built-in List functionality. I filed a feedback too: FB9595044. The issue with the gesture handler in the listRowBackground() is that it strangely resizes the items when they are moved. I haven't found a workaround for that either... but at least this bug has been fixed in macOS Monterey.

It's a sporadic issue for me. But restarting the iPhone and freshly connecting it to my Mac does resolve the problem reliably! I'm running many days without rebooting my iPhone and I suppose there are some "debugging/development related" iOS processes which "get stuck" after such a long time... Or perhaps it is somehow related to not having properly disconnected the devices during as debugging session? I have no idea. It just happens and I don't know why.

If you want to modify the configuration of the simulator instance used by Xcode Playgrounds you have to switch to the ~/Library/Developer/XCPGDevices directory before executing the find command above. Basically there are at the moment three locations where Xcode is storing simulator related container data: Regular Simulators (created within Xcode's "Devices & Simulators" window): ~/Library/Developer/CoreSimulator/Devices Preview Simulators (automatically created based on the currently selected device): ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices Playgrounds: ~/Library/Developer/XCPGDevices All of those locations can also be accessed through the command line utility xcrun simctl by specifying the --set <PATH> argument

Same here for a Swiss German keyboard: CMD+SHIFT+7 would be equivalent to CMD+/... unable to type on macOS Monterey with Xcode 13.1... but it worked fine on Big Sur! I've created feedback FB9770204.

See a possible workaround in https://developer.apple.com/forums/thread/693416

I have the same question. Did you find a solution for yourself? I tried using a UIManagedDocument from a SwiftUI ReferenceFileDocument (which under the hood is using UIDocument)... but this FileWrapper based saving is a headache, so I'm using it only to create the initial document structure. (UIManagedDocument needs an URL to open, which we only have after the document has been read.) I've also tried now to instantiate my own NSPersistentContainer within the my ReferenceFileDocument based class. But I see some "warnings" whenever a save is triggered: 2021-12-17 17:29:40.855047+0100 CDDocument[35156:1542568] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode linked while in use: /Users/philipp/Library/Developer/CoreSimulator/Devices/9A35CF23-0961-46BE-9F29-41C974BD6E08/data/Containers/Shared/AppGroup/7170A731-86C9-4340-988B-BDD0FDB4CFAA/File Provider Storage/Untitled.example/StoreContent/persistentStore 2021-12-17 17:29:40.855105+0100 CDDocument[35156:1542568] [logging] invalidated open fd: 6 (0x10) According to my understanding the SQLite files are moved away when the document is saved and replaced with those returned by the FileWrappers. So currently I'm returning the existing FileWrapper (which is the documents root directory)... nevertheless I get those errors. I personally do not have experience with file coordination, so I'm wondering if there is really something I can do as I'm not really managing the files of my document myself.

I've seen this issue twice in the last few weeks on my 14-inch 2021 MacBook Pro with 12.1, working in Xcode with SwiftUI and Life-Preview enabled. OK, Safari was also running in the background but I was not interacting with it. So I cannot say for sure what the reason is. Can you share some information on when this happens for you? (I reported my problem in FB9849777)