Plus one. I have the same issue on all my physical test devices. You can tap on a star and then a cancel and submit button appears. These buttons are responsive again. Not sure if this only happens in debug mode though. At least I have not yet received any complaints from users.

Xcode 16.2 beta 3 finally documents this issue and mentions the compiler flag. https://developer.apple.com/documentation/xcode-release-notes/xcode-16_2-release-notes @HZApps : are you sure that your lazy loading is not triggered by your view. Maybe you have embedded your view in AnyView yourself, which will then lead to the same result. You could post some code so others can help.

Trying this option in a small example program shows, that this indeed fixes the issue. That has cost me a lot of time looking at my code and wondering why it is so slow! Just to be sure if I understood that right. This option is set to YES in DEBUG and set to NO in release builds if you do not override it? So the only downside in setting it to NO would be that the Previews will be slower, with the upside that it behaves normal again?

Anyone found a solution to this yet? I set the store to read only, I disabled migrations (and I did not have migrations for years), yet this is the number one reason for crashes in my app by factors. As it is not reproducible locally, I will never get any information on what the failure reason is that is reported in this assertion.

That makes sense. The official Apple doc does not mention anything, but I see that when you navigate to the class in Xcode directly it is explained. Thanks for that!

After reading the documentation for .fileImporter I saw that they describe that you need to start a security-scoped access with a note. I wonder when they started to request this. It used to work differently and it has been changed at one point in time. This explains, why after a recompile it just stopped working.

After investigating further I found out that when using NSOpenPanel directly, this issue does not occur. No need to start a security-scoped access there. But with SwiftUI this problem occurs. This was working in earlier releases and I would expect that it behaves the same way as NSOpenPanel because this is what is being used in the background.

You are right. This is a very subtle error that I have run into. Thanks for pointing this out.