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)

Hmm... I just found out that I can set the "Build Configuration" to "Release" in the "Test" action and the pause is disappearing. Might be some default option which is set in the "Debug" configuration? Sorry... it seems that if you simply fiddle around enough, Xcode is somehow caching stuff... at least it is definitely not consistent in speed. Whenever I modify the tests (e.g. add an XCTFail in a different place) it takes again 5s to show up.

I've now encountered the same issue when I try building from Xcode Cloud: ITMS-90334: Invalid Code Signature Identifier - The identifier 'bla-bla-someNumbersAndcharacters' in your code signature for 'Bla-Bla' must match its Bundle Identifier 'bla-bla' I don't know where the part "someNumbersAndcharacters" (numbers and characters which seems to be some identifier) are coming from.

Check out the tab views used in Apples apps: Podcast, Music, Files... Switching between tabs is always instantaneous, by design. Personally I don't think a transition animation between the tabs would add any benefit. It could even get annoying for a user. If you really want to trigger some animation, you could use the onAppear of each tab to build some illusion... but this would mean that your views (within the TabView) would really need to know what view is being drawn left/right of it. I think you will end up writing your own version of TabView, not a good idea. See also the HIG to learn why and when to use tab bars (https://developer.apple.com/design/human-interface-guidelines/tab-bars) in iOS. But if you really need an animation... there is a possible way using the TabView in .page mode. The TabView will take care of the animation and will allow swiping between the screens, but you will have to add the bottom bar with all the buttons to switch between the pages. See the example below. struct ContentView: View { @State private var selectedScreen = 0 var body: some View { TabView(selection: $selectedScreen) { Text("Home") .tag(0) Text("Calendar") .tag(1) Text("Settings") .tag(2) } .tabViewStyle(.page(indexDisplayMode: .never)) .toolbar { ToolbarItem(placement: .bottomBar) { HStack { Button(action: { withAnimation { selectedScreen = 0 } }) { VStack { Image(systemName: "house") Text("Home").font(.caption2) } } .foregroundColor(selectedScreen == 0 ? .accentColor : .primary) .frame(maxWidth: .infinity) Button(action: { withAnimation { selectedScreen = 1 } }) { VStack { Image(systemName: "calendar") Text("Calendar").font(.caption2) } } .foregroundColor(selectedScreen == 1 ? .accentColor : .primary) .frame(maxWidth: .infinity) Button(action: { withAnimation { selectedScreen = 2 } }) { VStack { Image(systemName: "gear") Text("Settings").font(.caption2) } } .foregroundColor(selectedScreen == 2 ? .accentColor : .primary) .frame(maxWidth: .infinity) } .buttonStyle(.plain) .labelStyle(.titleAndIcon) } } } }

I've also seen this problem since the early Xcode 15 betas and I never understood why and when it happened. Today I've been investigating more in depth, trying to reproduce the problem. The problem After starting an iPhone simulator using iOS 17 (either by running an app or by triggering SwiftUI Previews), CPU consumption goes very high and does not come back to "background level" even after many minutes of wait. Beside the SpringBoard process we can see the following 5 other processes with high CPU consumption: PhotosPosterProvider ExtragalacticPoster CollectionsPoster two instances of diagnosticd (background processes which are consuming the logs generated by the processes?) My current setup Xcode Version 15.0 (15A240d) Simulator running iPhone 14 using iOS 17.0 (21A328) Reproducible steps Version 1: simulator using iOS 17 Create a new iPhone simulator using iOS 17. Start it up (either from "Simulator") or by running an app. Wait and see... You will see that most of the processes consuming a lot of CPU, will come down after a few minutes. But SpringBoard will stay up. Version 2: Switching languages Start "Settings" app, go to "Language & Region" and add/switch to another Language, for example to "German". Poster processes will get restarted and SpringBoard will automatically start logging messages again. Version 3: "The real cause" Until now we have never tried to understand what those "Poster" processes are. The following steps will indicate clearly where the bug lies: With the Simulator running (with no CPU hog running) lock the iPhone by pressing CMD+L (or the side-button in the UI). Wake up the iPhone by touching the screen or tapping CMD. Tap and hold the screen to go to the FrontBoard configuration screen. Swipe to the left and select "Add new". The "Add New Wallpaper" screen will appear, starting to populate the prepared examples to select from. ==> SpringBoard will again start to log Workaround I use the following workaround to remediate. In the end, it is always about killing the Poster processes. Variant 1: The annoying restart Restart the device and hope for the best... If after a few minutes the high CPU persists, restart the device again. Variant 2: targeted kill of the problematic processes Use "Activity Monitor" to kill the "Poster" processes which consume CPU. Search for "Poster" check CPU consumption and stop the process. Use the following shell command to kill all processes being part of "CoreSimulator" and having "Poster" in the name. ps aux | grep -E '[C]oreSimulator.+Poster' | sort -r -k3 | awk '{if ($3>0.0) { print $2}}' | xargs kill -1

Might be related to the problem described here? https://developer.apple.com/forums/thread/734573?page=2#771879022 Some "Poster processes" which generate previews for the iOS 17 front screen are buggy. Above I've described a way to kill them, to get CPU down.