My app just got rejected for this issue as well. I'm considering using the URL mentioned above as well. Actually, since my app uses RevenueCat, they offer a property called managementURL that will take the user to the subscription management screen. So I will probably use that instead. It's not a hard-coded URL like the one above and it supposedly works on Android as well. Unfortunately, I'm not allowed to post that link here but just google "RevenueCat managementURL" and it should be the top result.

Apple replied to my feedback ticket on this issue saying they think it's fixed in macOS 15.2 Beta 2. I currently don't have the 15.2 beta installed on a Mac to confirm. Does anyone have the beta installed to see if this issue is fixed?

I was able to confirm Quinn's suggested work-around does indeed work! I created a separate copy of the entitlements file for macOS and changed just the com.apple.security.application-groups setting in the macOS version so that the first part of the string is our team ID (instead of "group"). Then I added a macOS variant for both Debug and Release for the "Code Signing Entitlements" in build settings and set the new values to the macOS version of the entitlements file I just created. Now I'm no longer getting that annoying alert when I run the macOS version! I also confirmed that the iOS version of my app still works as before.

Seeing this too. It first happened to me yesterday and I re-downloaded them which took a while but it fixed it temporarily until this morning when I opened up Xcode and it was saying they were missing again! Found a Reddit post (not allowed to link here) where someone said the following command fixed it for them and it fixed it for me too: sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService

Having similar performance problems here too. Discovered that it only happens when the "Debug executable” checkbox in the run scheme is turned on (the default). The performance degradation becomes really obvious when accessing SwiftData properties repeatedly such as when sorting objects from a one-to-many relationship using a sortOrder property, for example. Hitting pause when it is hung for a while almost always shows up in the getter for that property inside the sort. Also the temporary hangs get longer and longer each time that sort code is run again and memory ramps up each time too so there is some kind of memory leak. Ironically, there are no performance issues at all when running the app in Instruments or when running independently of Xcode or with the Debug executable checkbox turned off (but then breakpoints don't work and the builtin CPU, memory, etc. graphs don't show). I wrote an Apple feedback ticket for it: FB13707023. On the plus side, I spent the last few days optimizing my app (lazy getters for the relationship sorting, algorithm tuning, etc.) because this issue really amplifies/exaggerates the less efficient areas of your code and now it runs lightning fast when it's not connected to Xcode! 🙃

I started seeing this bug in beta 2 of iOS 16. I remember it actually worked in the first beta but broke in beta 2 and has been broken ever since. I wrote a feedback ticket back then on it as well (FB10516559). And yes, once you start typing the scope bar shows up. This is an unacceptable UX though as the user should see all the scopes and be able to change them as soon as the search bar is tapped, not after the first character is typed. It's also jarring to the user to have the scope bar animate during typing.

I'm also seeing this or something similar starting with beta 5. I have a NavigationLink/navigationDestination with a NSManagedObject item in one view and another NavigationLink/navigationDestination combo in the destination view using another NSManagedObject item. When the outer NavigationLink is tapped, it just sits there and hangs with 100% CPU and running up memory like crazy. Putting a breakpoint in the upper navigationDestination reveals it getting called over and over so it's probably some kind of recursion in the SwiftUI framework. If I change the upper NavigationLink to the older-style without an item or navigationDestination modifier, it works. This however reveals another SwiftUI bug that I already wrote a feedback ticket for in an early beta (FB10260549) where mixing the old style NavigationLink at a higher level with the new style links with items at a lower level results in the lower links not working. So I've been trying to isolate the problem in a simpler sample app to attach to a new feedback ticket but I can't seem to reproduce it in the sample app. It's driving me crazy. I hope someone else has better luck and submits a feedback ticket for this.

I had same error but in my own code and I wrote another feedback ticket for that: FB10260549 with my own sample project to reproduce it. I didn't look at the demo code but in my case its when you have a NavigationLink(value:) in a List with valid .navigationDestination modifier code but that is inside a destination view of a parent List with NavigationLinks that use the old style without values.