Post

Replies

Boosts

Views

Activity

Reply to WARNING: Application performed a reentrant operation in its NSTableView delegate. This warning will become an assert in the future.
Still reproducible in October 2026 (macOS 26.7.1, Xcode 27.0) with plain SwiftUI and no custom NSTableView delegate, so this does not appear to be app-specific. Minimal repro: a List(selection:) with ForEach over an @State array that goes from empty to N items in a single state change. No custom NSTableView delegate, NSViewRepresentable or AppKit code is involved. On my machine (260x600 pt list, two-line rows), 200 rows is silent and 225 or more logs the warning once at the moment of insertion, in both Debug and Release builds. LLDB breakpoint on NSLog shows the warning is raised from inside AppKit, with no app frames in the stack: SwiftUI OutlineListCoordinator.diffRows(of:to:) -> NSTableView endUpdates -> NSTableRowData endUpdates / _updateVisibleViewsBasedOnUpdateItems -> NSTableView rowAtPoint: -> NSTableRowHeightData _cacheRowSpansInRange: -> _adjustRowSpansStartingAtRow: -> NSTableView _updateTableViewSize -> _totalHeightOfTableView -> _cacheRowSpansInRange: (re-entered) -> NSLog So AppKit appears to re-enter its own row-height cache while the first call is still computing heights. That is my reading of the stack, not a confirmed root cause. I filed this as FB25126440 (Developer Technologies & SDKs / SwiftUI / macOS) with a standalone Xcode project, the full backtrace and a sysdiagnose. If you can reproduce it, please file your own report and reference the FB number, since duplicates help Apple prioritise.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
1w
Reply to WARNING: Application performed a reentrant operation in its NSTableView delegate. This warning will become an assert in the future.
Still reproducible in October 2026 (macOS 26.7.1, Xcode 27.0) with plain SwiftUI and no custom NSTableView delegate, so this does not appear to be app-specific. Minimal repro: a List(selection:) with ForEach over an @State array that goes from empty to N items in a single state change. No custom NSTableView delegate, NSViewRepresentable or AppKit code is involved. On my machine (260x600 pt list, two-line rows), 200 rows is silent and 225 or more logs the warning once at the moment of insertion, in both Debug and Release builds. LLDB breakpoint on NSLog shows the warning is raised from inside AppKit, with no app frames in the stack: SwiftUI OutlineListCoordinator.diffRows(of:to:) -> NSTableView endUpdates -> NSTableRowData endUpdates / _updateVisibleViewsBasedOnUpdateItems -> NSTableView rowAtPoint: -> NSTableRowHeightData _cacheRowSpansInRange: -> _adjustRowSpansStartingAtRow: -> NSTableView _updateTableViewSize -> _totalHeightOfTableView -> _cacheRowSpansInRange: (re-entered) -> NSLog So AppKit appears to re-enter its own row-height cache while the first call is still computing heights. That is my reading of the stack, not a confirmed root cause. I filed this as FB25126440 (Developer Technologies & SDKs / SwiftUI / macOS) with a standalone Xcode project, the full backtrace and a sysdiagnose. If you can reproduce it, please file your own report and reference the FB number, since duplicates help Apple prioritise.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
1w