To add more context: the same callout view works fine in UIKit on iOS26. I filed FB20975128 with a reproducible project, if that helps. Please suggest some workaround that might work.

Hi. Sorry I didn't specify, but I'm using UIKit. I figured I can use UIMainMenuSystem.Configuration().documentPreference = .removed and that removes the unnecessary File menu items. It still shows a 'Close Window' command instead of a 'Quit' command though.

Same issue in Beta 3. Filed FB18411347

Nevermind ... I was checking the wrong CKRecord's fields.

Pause / continue still crashes. Just removing the breakpoint helps.

Hi, I have the same issue. It was there in Beta1 as well, and I spoke to someone in the WWDC labs and they acknowledged it was an issue they were working on, but doesn't look they have fixed it for Beta 2. Happens when building in Xcode Beta 2 on macOS26 Beta 2 as well. I filed FB18411347

Thanks for that. I tried it, and now I can save / fetch the NSData from Core Data after transforming it ... BUT it doesn't get rendered as an attributed string (i.e. the formatting gets lost). This is the code for the next TextEditor in iOS26 that takes an AttributedString for its binding. Is there something wrong that I'm doing? struct AttributedDetailView: View { @ObservedObject var item: Item @State private var notesText = AttributedString() var body: some View { VStack { TextEditor(text: $notesText) .padding() .onChange(of: notesText) { item.attributedString = NSAttributedString(notesText).toNSData() } } .onAppear { if let nsattributed = item.attributedString?.toAttributedString() { notesText = AttributedString(nsattributed) } else { notesText = "" } } .onDisappear { item.attributedString = NSAttributedString(notesText).toNSData() do { try item.managedObjectContext?.save() } catch { print("core data save error = \(error)") } } } }

I'm also having this problem! Just posting some SwiftUI code with some code sample.

Just to follow up on this (as it's still an issue in macOS 15.4), based on your feedback, the following should be equivalent in performance (but they're not): // 1. the 'fast' version struct ContentView: View { @Environment(\.managedObjectContext) private var viewContext @FetchRequest( fetchRequest: Item.myFetchRequest(), animation: .default) private var items: FetchedResults<Item> var body: some View { NavigationStack { List { ForEach(items) { item in Text("\(item.itemNumber ?? "None")") } } } } } // 2. The 'slow' version struct ContentView: View { @Environment(\.managedObjectContext) private var viewContext @FetchRequest( fetchRequest: Item.myFetchRequest(), animation: .default) private var items: FetchedResults<Item> var body: some View { NavigationStack { List { ForEach(items) { item in ContentItemView(item: item) //Text("\(item.itemNumber ?? "None")") } } } } } // extracted subview struct ContentItemView: View { let item: Item var body: some View { Text("\(item.itemNumber ?? "None")") } } If you add 5k rows here, and try to drag the window scrubber up and down to scroll through the list, you can see the performance problems in the 2nd version. The number of subviews in each row are equal in both implementations. Your explanation makes sense for iOS but not for macOS, where there's some performance problem under the hood.

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.