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.

I have three core data entity types which are subclasses of a shared parent class, but which do not inherit from a shared parent entity type in Core Data. Let's call the three types businesses, customers, and products. Every entity type has the possibility of many-to-many relationships with each of the other entity types. e.g., a business could have relationships with multiple other businesses, customers, and products. A product could be sold by multiple businesses and have been purchased by multiple customers, and be related to other products. These are Core Data many-to-many relationships. There are two contexts in which I am presenting these entities: as results from a search, and to display the other entities that are in relationship with a specific entity that the user has selected. Currently, I have implemented both of these contexts as being entity-type specific—at any one time you search for products, or businesses, or customers. You change to a different scope within a UISearchBar to swap between entity types. Likewise, when viewing details of a specific entity, you can view lists of the items related to that entity separately for each of the three types. Results are fetched with an NSFetchResultsController in both cases, with an appropriate predicate. Some users have 10,000 entities in total across the categories. Few or none will have 100,000. I want to present collections that instead intermix items from all three of these types in the displayed results or lists. As far as I am aware, this is not possible with an NSFetchedResultsController unless I redesigned my Core Data model to have them all inherit from a base entity type, and that seems to have significant downsides on an ongoing basis, in addition to the necessary complex migration. What is the best way to achieve this? I am open to any technology, any approach, and am willing to raise the required iOS version to iOS 13 or even iOS 14 in order to be able to use the most ideal approach.