Using PlainButtonStyle works for the immediate problem, but introduces another problem: while typing in the TextField, pressing spacebar doesn't work, it seems to trigger the Button action handler instead.

Hi. This doesn't explain why the subview version works fine on iOS, but is very slow on macOS. Also, the branching is the same in both cases ... the conditional is wrapped in an HStack in both cases. Also, I filed a feedback a few months ago regarding this issue: FB15645433

So I realized that the primaryAction closure has a closure parameter, and using that gets the row item that the user tapped on. List(selection: $selectedItems) { ForEach(items) { item in Text("Item \(item.number) - \(item.timestamp)") } } .contextMenu(forSelectionType: TimedItem.ID.self, menu: {_ in Button(action: { print("button called - count = \(selectedItems.count)") }) { Label("Add Item", systemImage: "square.and.pencil") } }, primaryAction: {items in print("primaryAction called - count = \(items.count)") // not selectedItems.count }) Hopefully this is 'expected behavior' and isn't expected to change any time soon

Hi, Why is it 'expected behavior' in iOS18.4 if it's behaved differently all this time? It's been working this way since iOS16 I believe. Was that just a bug? This API was the most convenient way to handle both row selection AND provide a context menu to the user. The problem I run into is that if I add the contextMenu(forSelectionType: menu: primaryAction:) as a view modifier, then it eats the onChange(of: selectedItems) change handler. Both don't seem to exist together. Is there another way to track which item the user is selecting? So now I'm stuck ... either I don't provide a context menu for the items in the list, or I can't handle the row selection at all (without completely breaking the UI by putting the list in Edit mode). Please consider keeping the existing pre-iOS18.4 behavior. If it's been working fine in production since iOS16, then I don't see what the eagerness to change it is.

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.