I even do not get an error by the "Thread Performance Checker" but keeping the option enabled in Xcode 15.3 results in horrible performance of the app during the full utilization of the app (I'm making intensive use of background threads). The only option currently possible is deactivate this feature in Debug Scheme. (Filed bug report: FB13681777)

I'm observing the same issue. Execution of code is performed within backgroundContext.performAndWait{} Accessing the parentObject in the backgroundContext.performAndWait is not an issue here, but as soon as I access fetchedProperties?.first I observe the error stated by @vinicius_likeappro Did you manage to solve this issue?

I’m experiencing the same issue. As suggested earlier, switching to MKMultiPolyline helps, but it is not a proper solution and results in losing functionality of my app… As a side note: it seems that the issue only occurs iOS 16.2 but not on iPadOS 16.2

Unfortunatley using Xcode 13.4.1 & iOS 15.5 I can still reproduce this issue. The problem only occurs, when change affects the sorting, e.g. change "A1" to "AB82" will return to DetailView when closing the modal change "A1"to "K84" will return to ContentView when closing the modal

The problem may even result in fully crashed CoreData stack with data loss (iOS 15.1). I submitted a case (FB9744735) including sysdiagnose and crash logs. From my point of view an absolutely critical bug.

I'm having the same issue without having solved it yet. In my case I'm performing different background tasks (without audio interactions). Did you use any animations in your SwiftUI views?

I'm facing a the same problem. In my case I'm collecting data in background mode. If internet connection gets lost, large amount of data might be sync when the device gets back on the internet. If data collection is still active, the background mode seems to keep NSPersistentCloudKitContainer alive resulting in the iCloud sync not being terminated and the app getting killed due to high CPU pressure. What framework are you using? I'm using SwiftUI. I'm also still looking for a solution.

Unfortunately still having this issue in iOS 14.5. Appears to be some kind of race condition. Applying .id(UUID()) onto List{} solves the issue by forcing a new @FetchRequest, but also resets the view in case of any ObservedObject changes (... so not really practical solution).