This issue might be back when using SwiftData and CloudKit. On iOS 17.5.1 I'm getting multiple warnings before the app crashes after idling for a while. Could this be a regression? Background Task 1793 ("CKScheduler-com.apple.coredata.cloudkit.activity.export.F7AC7CB7-21C8-4443-BB52-49B93441C5E3"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.

I have a follow up question on this topic. According to the documentation, startAccessingSecurityScopedResource() "returns true if the request to access the resource succeeded; otherwise, false" This works fine for when called from .fileImporter. However when called from .dropDestination(for: URL.self) { urls, _ in ... then url.startAccessingSecurityScopedResource()will always return false. I'm importing the same files using these two methods. if url.startAccessingSecurityScopedResource() == true { let data = try Data(contentsOf: url) // works for .fileImporter url.stopAccessingSecurityScopedResource() } else { throw EmbeddingsError.noAccess // but calls from .dropDestination(for: URL.self) { urls, _ in end up here } What does work is to ignore the return value of url.startAccessingSecurityScopedResource() like so: _ = url.startAccessingSecurityScopedResource() let data = try Data(contentsOf: url) // works for .fileImporter url.stopAccessingSecurityScopedResource() But that can't be the way it's supposed to work. Is there anything I'm missing?

I have a similar issue where the app crashes on iOS while in the background and found this discussion via Google. Thanks for posting the solution. I will try it and confirm if it solved the issue. Here's my crashlog: Thread 0 name: Thread 0 Crashed: 0 libswiftCore.dylib 0x0000000191f758c0 _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:144) 1 libswiftCore.dylib 0x0000000191fe3d14 swift_unexpectedError + 664 (ErrorType.swift:188) 2 _SwiftData_SwiftUI 0x000000023368fd78 one-time initialization function for empty + 300 (ModelContainer+Extensions.swift:5) 3 libdispatch.dylib 0x000000019b526dd4 _dispatch_client_callout + 20 (object.m:576) 4 libdispatch.dylib 0x000000019b528654 _dispatch_once_callout + 32 (once.c:52) 5 _SwiftData_SwiftUI 0x000000023368fdf8 one-time initialization function for empty + 124 (ModelContainer+Extensions.swift:12) 6 libdispatch.dylib 0x000000019b526dd4 _dispatch_client_callout + 20 (object.m:576) 7 libdispatch.dylib 0x000000019b528654 _dispatch_once_callout + 32 (once.c:52) 8 _SwiftData_SwiftUI 0x00000002336a5170 key path getter for EnvironmentValues.modelContext : EnvironmentValues + 140 (<compiler-generated>:0) 9 libswiftCore.dylib 0x00000001920a0628 RawKeyPathComponent._projectReadOnly<A, B, C>(_:to:endingWith:) + 1012 (KeyPath.swift:1701) 10 libswiftCore.dylib 0x000000019209fddc KeyPath._projectReadOnly(from:) + 1036 (KeyPath.swift:331) 11 libswiftCore.dylib 0x00000001920a4348 swift_getAtKeyPath + 24 (KeyPath.swift:2029) 12 SwiftUI 0x0000000197eb0814 EnvironmentBox.update(property:phase:) + 872 (Environment.swift:273)

I might have the same issue. The first version of my Mac app was approved last week, but the subscriptions weren't. So the app is currently in the Mac App Store without any subscription options. I don't even created an error message for this, so the upgrade screen is just blank. Not a great user experience. I requested a phone call today but there wasn't anything they could do since the iOS version of the app is currently in review. What I understand from support is that subscriptions should be approved or rejected alongside the app itself. So the state that an app is approved but the subscriptions aren't shouldn't happen. Support advised me to wait until the iOS version of the app is approved and then follow up if the subscriptions still aren't approved. Until then there is apparently nothing they can do, or so they told me.

MacOS 12.4 release still has this issue. Let's hope it will be fixed in MacOS 13.