I’m seeing a macOS 26 AppKit issue with a sidebar + full-size content window + titlebar accessory setup.
The main problem is that an NSTitlebarAccessoryViewController can visually cover the first item in the sidebar when System Settings > Accessibility > Display > Reduce Transparency is enabled. In my app this made the first sidebar/menu item look blacked out/covered by the titlebar/accessory area.
While investigating possible workarounds, I also compared NSTitlebarAccessoryViewController with NSSplitViewItemAccessoryViewController and found two related issues that make the split-view accessory hard to use as a replacement.
I could not attach the full sample project directly, so I included the two relevant Swift files below. The screenshots were taken from the same minimal AppKit repro with Reduce Transparency enabled.
Repro setup
The sample project shows:
- a fixed-width sidebar
- one content pane using
NSTitlebarAccessoryViewController - one content pane using
NSSplitViewItemAccessoryViewController - both accessories use the same custom view
- both custom views request the same intrinsic height
- each accessory displays its requested and actual height
Issue 1: titlebar accessory can cover sidebar content
With Reduce Transparency enabled, the titlebar/accessory area can visually cover content at the top of the sidebar. This is the original issue I’m trying to solve.
Expected: the sidebar content should not be covered by the titlebar accessory/material.
Actual: the top sidebar item can appear blacked out/covered.
In the first attached screenshot, "First sidebar row" is hidden/covered while "Second row" and the following rows are still visible.
Issue 2: split-view accessory does not get the same hard separator
As a possible workaround, I tried using NSSplitViewItemAccessoryViewController instead of NSTitlebarAccessoryViewController.
Both controllers are configured with:
if #available(macOS 26.1, *) {
accessory.preferredScrollEdgeEffectStyle = .hard
}
The titlebar accessory shows the expected hard boundary/separator behavior, but the split-view item accessory does not appear to get the same hard edge treatment.
The second attached screenshot shows the workaround comparison between the titlebar accessory and the split-view accessory.
Expected: preferredScrollEdgeEffectStyle = .hard should produce a comparable hard separator for the split-view accessory.
Actual: the split-view accessory still looks visually different and does not show the same hard boundary.
Issue 3: split-view accessory is inset differently
The NSSplitViewItemAccessoryViewController also appears to be laid out with spacing/insets around it. In the repro, the accessory custom view has a faint red background.
Both accessory views request and receive the same height:
requested 36 pt, actual 36.0 pt
So the mismatch does not seem to be caused by the accessory view’s own intrinsic height. Instead, the split-view accessory appears to be hosted inside an inset container, with spacing around it, while the titlebar accessory is flush with the titlebar/content edge.
Expected: if both accessories host the same view with the same intrinsic height, their effective placement should be comparable, or there should be a documented way to remove/control the split accessory insets.
Actual: the split-view accessory is visually inset on multiple sides, making it unsuitable as a drop-in workaround for the titlebar accessory issue.
The second attached screenshot also shows this: the split-view accessory has the same requested and actual height as the titlebar accessory, but it is still visually inset and does not align the same way.
Question
Is this expected behavior on macOS 26, especially with Reduce Transparency enabled? If so, what is the recommended AppKit approach for placing a filter/search accessory below the toolbar/titlebar without covering sidebar content, while still getting a hard separator and predictable layout?