What I found
The app runs two navigation mechanisms at the same time, and they compete for the same window chrome. All three points below are read from main, not from a fork:
SidebarView.swift drives selection: List(selection: $appState.selectedSidebarItem).ServiceView.swift and ToolView.swift additionally wrap every row in NavigationLink(destination:). Inside a NavigationSplitView sidebar this pushes onto the detail column's navigation stack, and that stack brings its own title bar on top of the split view's chrome.ContentView.swift builds detail from Defaults[.startPage], not from the selection, so the declared detail content and the visible content come from two different sources.
Consequences
- The system-inserted sidebar toggle changes position when switching sections, because each detail view declares its own toolbar with a different placement:
.automatic in ScanHistoryView, none in LogView, id: in FileView, URLView and FileBatchView.
- An extra frame / title bar appears on some screens.
- The window title is squeezed into the sidebar titlebar area and gets clipped, which invites AppKit workarounds like hiding the title outright. I had exactly such a workaround in a branch of mine and removed it, because it papers over this instead of fixing it.
I observed the symptoms in a Debug build based on main with my own feature branches on top, so the screenshots would not be clean evidence — the code structure above is the part I can point at directly.
Separately: Liquid Glass is not adopted
The project targets macOS 14.5 and uses no Liquid Glass API — no glassEffect, no GlassEffectContainer; the only material in the project is .regularMaterial in UploadProgressView.swift. On macOS 26 the system styles standard controls automatically while hand-drawn elements keep the old look, so a window mixes both appearances. Worth deciding deliberately rather than by accident.
Suggested direction
Pick one navigation mechanism — selection-driven detail, dropping the NavigationLink wrappers — give the detail column a real navigationTitle, and normalise toolbar placements across the detail views. Happy to prepare a PR if you want it done this way.
What I found
The app runs two navigation mechanisms at the same time, and they compete for the same window chrome. All three points below are read from
main, not from a fork:SidebarView.swiftdrives selection:List(selection: $appState.selectedSidebarItem).ServiceView.swiftandToolView.swiftadditionally wrap every row inNavigationLink(destination:). Inside aNavigationSplitViewsidebar this pushes onto the detail column's navigation stack, and that stack brings its own title bar on top of the split view's chrome.ContentView.swiftbuildsdetailfromDefaults[.startPage], not from the selection, so the declared detail content and the visible content come from two different sources.Consequences
.automaticinScanHistoryView, none inLogView,id:inFileView,URLViewandFileBatchView.I observed the symptoms in a Debug build based on
mainwith my own feature branches on top, so the screenshots would not be clean evidence — the code structure above is the part I can point at directly.Separately: Liquid Glass is not adopted
The project targets macOS 14.5 and uses no Liquid Glass API — no
glassEffect, noGlassEffectContainer; the only material in the project is.regularMaterialinUploadProgressView.swift. On macOS 26 the system styles standard controls automatically while hand-drawn elements keep the old look, so a window mixes both appearances. Worth deciding deliberately rather than by accident.Suggested direction
Pick one navigation mechanism — selection-driven detail, dropping the
NavigationLinkwrappers — give the detail column a realnavigationTitle, and normalise toolbar placements across the detail views. Happy to prepare a PR if you want it done this way.