Update: still fails on beta 4 with the custom content type and using .draggable(containerItemID:containerNamespace) and .dragContainer(for:in).

Interesting. Changing only the contentType argument to .json makes it work correctly: CodableRepresentation(contentType: .json) Not sure if that helps localize the bug or if I'm not handling a custom content type correctly.

It's not shown in the repro, but I need to do additional things on drop than just reorder the array of items. In the real version, users can drop items onto other items and the items are merged. The frustrating part is that the WWDC25 demo and examples only show how to use the new .draggable(containerItemID:) and .dragContainer(for:) modifiers to drag items to the trash. So there's no demonstration of a drop target working with the new container-based modifiers...

Yes macOS 26.0 Beta (25A5306g)

@Developer Tools Engineer thanks. The FB you linked is the right one. @darkpaw Here's a simpler repro without bindings that still crashes. import SwiftUI struct MyItem: Identifiable { var id = UUID() var label: String } struct HelloView: View { let element: MyItem var body: some View { Text(element.label) } } struct ForEachSubView: View { @State var elements: [MyItem] = [ MyItem(label: "hello"), MyItem(label: "world"), ] var body: some View { List { ForEach(elements, id: \.id) { element in HelloView(element: element) // crash // Works ok: // Text(element.label) } } } } #Preview("ForEachSubViewRepro") { ForEachSubView() } Seems SwiftUI is internally invoking an "OutlineList" and then crashing when trying to walk a tree, despite the fact that MyItem has no children and no children keypath is specified in the List constructor. Thread 0 Crashed: 0 libswiftCore.dylib 0x1a9b458f0 _assertionFailure(_:_:file:line:flags:) + 176 1 SwiftUI 0x1cab7e9c8 ViewListTree.visitItem(_:force:) + 5232 2 SwiftUI 0x1cab8948c OutlineListCoordinator.outlineView(_:child:ofItem:) + 980 3 SwiftUI 0x1cab895cc @objc OutlineListCoordinator.outlineView(_:child:ofItem:) + 128 4 AppKit 0x19a88a694 loadItemEntryLazyInfoIfNecessary + 340 5 AppKit 0x19b14ae50 -[NSOutlineView itemAtRow:] + 48 6 AppKit 0x19b14e63c -[NSOutlineView _delegate_isGroupRow:] + 48 7 AppKit 0x19b642f14 -[NSTableRowData _cacheGroupRowIndexesWithinRange:] + 92 8 AppKit 0x19b642e74 -[NSTableRowData isGroupRowIndex:] + 144 9 AppKit 0x19b0d636c -[NSTableView _spacingPrecedingRow:] + 44 10 AppKit 0x19b5747c4 -[NSTableRowHeightData _cacheRowSpansInRange:heightProvider:] + 612 11 AppKit 0x19b572d30 -[NSTableRowHeightData _cacheRowSpansInRange:] + 100 12 Foundation 0x197c1b3b8 __NSINDEXSET_IS_CALLING_OUT_TO_A_RANGE_BLOCK__ + 24 13 Foundation 0x1985faee8 __NSIndexSetEnumerateBitfield + 340 14 AppKit 0x19b574a04 -[NSTableRowHeightData _estimatedSpanForRow:cacheIfNecessary:] + 256 15 AppKit 0x19b571ee4 -[NSTableRowHeightData _estimatedSpanForRowsInRange:] + 48 16 AppKit 0x19b572018 -[NSTableRowHeightData computeTotalRowsSpan] + 68 17 AppKit 0x19b572224 -[NSTableRowHeightData _estimatedRowAtOffset:] + 36 18 AppKit 0x19b2df190 -[NSTableView rowAtPoint:] + 204 19 AppKit 0x19b63eb60 -[NSTableRowData _keepTopRowStableAtLeastOnce:andDoWorkUntilDone:] + 192 20 AppKit 0x19a895474 -[NSTableRowData _updateVisibleViewsBasedOnUpdateItems] + 1340 21 AppKit 0x19a8897cc -[NSTableRowData endUpdates] + 348 22 AppKit 0x19b2dfc34 -[NSTableView _endUpdateWithTile:] + 108 23 AppKit 0x19a8e2c4c -[NSTableView endUpdates] + 28 24 SwiftUI 0x1cab6dc20 OutlineListCoordinator.diffRows(of:to:) + 112

Simpler repro without generics. import SwiftUI struct MyItem: Identifiable { var id = UUID() var label: String init(_ label: String) { self.label = label } } struct HelloView: View { let label: String var body: some View { Text(label) } } struct ForEachBindingRepro: View { @State var elements: [MyItem] = [ MyItem("hello"), MyItem("world"), ] var body: some View { List { ForEach($elements, id: \.id) { $element in HelloView(label: element.label) // crash // Works ok: // Text(element.label) } } } } #Preview("ForEachBindingRepro") { ForEachBindingRepro() }

Found a workaround by adding a Spacer to the left of the WebView. The Spacer seems to respond to the sidebar and push the WebView out from under the sidebar. struct OccludingNavSplitView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { HStack { Spacer() WebView(url: URL(string: "https://www.google.com")!) } } } } This was hinted at in the description of ScrollView behavior underneath the sidebar in the docs here. Interested in if this is working as intended or if there is some other configuration option needed.

Here is a screenshot of the WebView remaining in place after the sidebar opens on top of it.

Yes I'm still getting the same error under the same conditions. It also occurs when updating the test runners to Xcode 26 beta (17A5241e) and macOS 26 beta (25A5279m).