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.
Fribi
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
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.