Just following up on this: I managed to fix the issue! As I mentioned, the problem was mostly with updating the outlineView as data changed. I was trying to reload the 'item' when possible, and manually inserting / deleting rows in different sections as the data changed. I was doing this to keep the changes animated, and also to preserve selection. Now I'm just calling 'reloadData' instead... to preserve selection, I save the selected item(s) first, and manually select them after reloadData() is done. Animation wasn't important. Now it solved all the crash problems I had.

Thanks for the feedback. I'm just concerned with the macOS implementation of NSOutlineView. The full story is that I've been using this in my app's sidebar for a number of years, and it's been solid, but starting with macOS15, I've started getting dozens of crashes related to the NSOutlineView implementation, with many different types of crash report signatures, which all seem internal to Swift and/or NSOutlineView. The errors aren't reproducible on my side, but I have received over a 1000 reports in total already, all from devices macOS15, with no change on my side. I made a thread about this here and filed a feedback, but haven't received any response: https://developer.apple.com/forums/thread/767447 I basically need the sidebar to show what on iOS would be done with a sectioned UITableView (which doesn't exist on macOS). It shows a section with some fixed 'filters', a section with a list of 'tags' and more sections with list of 'groups', each with a section group header, and each row showing a name and a 'count'. I use a dictionary to drive the NSOutlineView. It loads fine, but if something changes, I have to update the 'count' of the item (by updating the count property of the item in the dictionary) and call outlineView.reloadItem, which ends up causing the crash in 1% of the cases. So I am considering these options ... keep digging deeper, maybe do something different to find the cause of the crash or to avoid it altogether. But I've been looking at this issue for a few weeks, I can't reproduce the issue on my own, and it's tough to do trial-and-error with a production issue replace the sidebar with diffable data source ... I have a similar implementation on iOS so it would improve consistency as well. But it doesn't seem to be possible with NSOutlineView, only NSTableView (or collection view) replace it with a SwiftUI view. This might be most amount of work, since I would have implement things like reordering and drag-and-drop which the current implementation supports That's the core of it. Any thoughts / feedback would be welcome.

Did you ever figure this out? I have the same issue.

I went to Settings -> Privacy & Security -> Full Disk Access, and enabled the setting there for my app. That stopped all the warnings coming up.

I have a solution that works very well to restoring the old tab bar layout: https://stackoverflow.com/a/78902044 I have it working in my production app already, and haven't had any issues.

It would be great if anyone can chime in to confirm / suggest a workaround. I filed FB14190656 a few months ago, with a reproducible example. Still haven't heard back.

Is there anyone on this thread who is running iOS18.1 Beta 3 on their device that has noted any changes to the iPad tab bar behavior?

FWIW, I recently got a response through Feedback assistant saying that the new UITabBarController behavior is "functioning as intended" and suggests that the best option would be to hide the UITabBarController and create a custom control to get the old functionality again. I personally find it very unreasonable to change the behavior of something that's been working fine for 17 years and replace it with something that's a confusing ill-thought-out mess, and not offer an opt-in / opt-out. But there you go. At least we have a few weeks to come up with alternatives.

Hi, Yes I get the same results on a new project. I have created an example project and attached it here. It's based on a basic Core Data app, with an "Item" entity, that has a one-to-many relationship with a "Tag" entity. When I convert these into "App Entities", I can create a query for the properties of the "Item" entity, and another query for the "Tags" entity, but I can't figure out how to create a query in "Item" that would also look for associated 'tags'. I can't seem to attach a zip file containing the app project to this post for some reason. But the code is fairly simple. This is the Item AppEntity: import Foundation import AppIntents struct ItemsAppEntity: AppEntity { static var defaultQuery = ItemsAppEntityQuery() var id: String @Property(title: "Timestamp") var timestamp: Date @Property(title: "Tags") var tags: [CJTagItemsAppEntity] static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Test Item") var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: "\(timestamp.formatted())") } struct ItemsAppEntityQuery: EntityPropertyQuery { static var sortingOptions = SortingOptions { SortableBy(\ItemsAppEntity.$timestamp) } typealias ComparatorMappingType = NSPredicate static var properties = QueryProperties { Property(\ItemsAppEntity.$timestamp) { LessThanComparator { NSPredicate(format: "timestamp < %@", $0 as NSDate) } GreaterThanComparator { NSPredicate(format: "timestamp > %@", $0 as NSDate) } } // HOW TO ADD SEARCH-BY-TAGNAME ... this does't work Property(\CJTagItemsAppEntity.$tagName, entityProvider: { item in return item.tags.first! }) { EqualToComparator {name in let predicateFormat = "tagName == '\(name)'" return NSPredicate(format: predicateFormat) } } } func entities(for identifiers: [ItemsAppEntity.ID]) async throws -> [ItemsAppEntity] { return [] } func entities(matching comparators: [NSPredicate], mode: ComparatorMode, sortedBy: [EntityQuerySort<ItemsAppEntity>], limit: Int?) async throws -> [ItemsAppEntity] { return [] } } } This is the Tags AppEnttiy: struct CJTagItemsAppEntity: AppEntity { static var defaultQuery = CJTagItemsAppEntityQuery() var id: String @Property(title: "Name") var tagName: String static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Test Tag") var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: "\(tagName)") } struct CJTagItemsAppEntityQuery: EntityPropertyQuery { static var sortingOptions = SortingOptions { SortableBy(\CJTagItemsAppEntity.$tagName) } typealias ComparatorMappingType = NSPredicate static var properties = QueryProperties { Property(\CJTagItemsAppEntity.$tagName) { EqualToComparator {name in let predicateFormat = "tagName == '\(name)'" return NSPredicate(format: predicateFormat) } } } func entities(for identifiers: [CJTagItemsAppEntity.ID]) async throws -> [CJTagItemsAppEntity] { return [] } func entities(matching comparators: [NSPredicate], mode: ComparatorMode, sortedBy: [EntityQuerySort<CJTagItemsAppEntity>], limit: Int?) async throws -> [CJTagItemsAppEntity] { return [] } } } I haven't implemented any methods properly ... I'm just trying to get the syntax right for this. Thanks.

Has anyone checked out if there's something in iOS18 Beta4 that can help out with this issue?

Just for reference: Apple DTS acknowledged a crash issue with SwiftUI Lists (specifically with section headers) that was fixed in iOS16.2. Ideally, this would have been documented or mentioned somewhere so I could've set the minimum deployment target to 16.2.

I managed to avert the problem by adding DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) { ... before deleting the object and saving the context. I guess that gives the underlying view time to coalesce all the updates properly. Still feels like a little hacky, so would be great if there was a better solution to this.

I discovered that the limit is 400 records at a time (just like CKModifyRecordsOperation).

After much time wastage, it turns out that the problem is caused by setting the window's backgroundColor (for some reason). So it works fine after commenting out this line: self.mainWindow.backgroundColor = [UIColor systemBackgroundColor];

After more research, it seems like the issue with 'CKQueryOperations' specifically, whether from the device or from web dashboard. If I fetch using CKFetchOperations, either from the device or from dashboard, with fixed RecordIDs, it works soon after the update is done. So it seems like some issue with indexing on the CloudKit side. How do we that fixed? I have mentioned the containerID in the feedback report that is linked above