Trying to examine performance issues in Xcode Instruments using the Animation Hitches instrument in Xcode 16.0 beta 6 (16A5230g). When connected to my iPhone 15 Pro Max and I try to start a run with my app, it has an error “Failed to split user provided arguments: working directory doesn't exist” with timestamp “(Before Run Started)”. When running the app on an iOS simulator, the instrument runs fine—but I want to profile on a real device.
 Instruments > Settings, Recording Location set to Default and that directory does exist.

I have a SwiftUI list that is backed by a @FetchRequest to Core Data. To display the items in the list it is necessary to traverse relationships on the originally fetched objects and currently the fetch is a little bit slow, while a number of the objects being displayed require images to be rendered, so overall it is a heavy view at present. I am working to make both the view rendering and the fetch more efficient, but alongside that I tried to improve the user experience by debouncing the connection between the user's search text and when the predicate would be updated on the @FetchRequest. This was quite simple to do, and meant the source data would only be re-fetched when the user had stopped typing for at least 0.5 seconds. However, what this demonstrated was that with a .searchable attached to the list, all items in the list were being updated on every keystroke, with printing changes revealing it was because their identity itself was changing, rather than any content. I found this was still the case even if I completely removed my updating of the predicate, so the text binding from the .searchable was stored in an @State value on the view, or stored in a @Binding to some other location, but was not being read nor used for anything else. Is this intended as a "feature" of .searchable, that it is intentionally triggering a view update on the assumption that when the .searchable text is changed that the view will want to change? If so, this is definitely a bug in SwiftUI from the perspective of how I was wanting to use it. Alternatively, any pointers to how I might be triggering this issue would be appreciated!

Using an @FetchRequest in my SwiftUI-redesigned app, I was looking to improve performance of my search and filtering on a List that has potentially a large amount of data. One of the things I was asking about was how to load some data initially and then fetch additional objects as the user scrolls. In a WWDC lab today, while viewing my code the Apple engineer noted I had set a .fetchLimit on my FetchRequest, and suggested that I should be setting a .fetchBatchSize. It sounded like that was designed to do exactly what I wanted. However, having attempted this, I can see from the console output that when I set a .fetchBatchSize of 50 and go to the view, it immediately loops through the entire collection of thousands of objects, attempting to load them into memory, and as some contain images this eventually crashes with an out of memory error. This data is presented in a List. Originally, inside that list there was a ForEach inside that list but the same problem was seen when I removed the ForEach and used: List(entries) { entry in if let entryData = viewModel.entryData(for: entry) { TimelineEntryView(entryData: entryData) } } Can you advise on what might be going on here? I recall that in the previous iteration of my app, in UIKit and using an NSFetchedResultsController I had the exact same symptom: setting a fetch batch size immediately traversed the whole collection in the datastore, leading to terrible performance rather than the hoped-for good performance. So I did not set a batch size then either. Am I holding this wrong? Is there something that might be triggering this?

The com.apple.developer.icloud-container-environment provides the option to set "the development or production environment to use for the iCloud containers." My app uses Core Data, and I have implemented NSPersistentCloudKitContainer. When I am not working on schema changes, I would like my local development builds to still access the production Core Data store. However, setting this entitlement to "Production" has not produced this result... the container is still listed as 'Staging' and I can see in the CloudKit Console that the Development container is being used. Does this entitlement only apply to direct use of CloudKit, and not to NSPersistentCloudKitContainer? If it doesn't apply to the latter, is there another way to direct NSPersistentCloudKitContainer to use the Production container? This is an iOS app though I am beginning work on a macOS version and would like to be able to do this in both environments.