v0.7.5 — Settings Toolbar Restored on macOS 26

Scene V0.7.5 is a single-bug hotfix for macOS 26 (Tahoe): every button in the Settings toolbar was missing, so layouts and workspaces could be edited but never created, duplicated, or deleted. If you're on Tahoe and running V0.7.2, V0.7.3 or V0.7.4, this is the release you want. macOS 14 and 15 were never affected.

What's new

• The Layouts toolbar is back — +, + Custom, delete, reset-to-default and Restore Default Presets.
• The Workspaces toolbar is back — New, Duplicate and Delete.
• Nothing else changed. No layout geometry, hotkey, workspace, or update-checker changes. The Liquid Glass window still looks exactly the same.

Why this matters

Creating and deleting layouts and workspaces happens only through those toolbar buttons. Without them the app still tiled windows correctly from the menu bar and hotkeys, but its entire authoring surface was unreachable — new users on Tahoe opened Settings, found no way to add anything, and reasonably concluded the app was half-finished. Thanks to @nphxexp-create for reporting it (#4).

Under the hood

• Root cause. V0.7.2's whole-window translucency made an NSVisualEffectView container view controller the window's contentViewController and nested the SwiftUI NSHostingController inside it as a child. NSHostingController only publishes its .toolbar content into view.window.toolbar when it is the window's content view controller; as a child it publishes nothing, with no warning and no compile error. The window ended up with window.toolbar == nil — no empty toolbar, no toolbar at all — so nothing the tabs declared could ever render.
• How it was isolated. All four combinations of (hosting controller wrapped in a container vs. as the window's root) × (Tahoe transparent-title-bar chrome vs. plain chrome) were built and their window.toolbar inspected. Only the two wrapped cases produced nil. The transparent title bar, the prime suspect, was innocent.
• Fix. The hosting controller is the window's root contentViewController again, and the .underWindowBackground material moves into SwiftUI as a background layer via a small NSViewRepresentable. The two-branch window construction collapses into one path shared by all macOS versions.
• Tests: 394/394, unchanged. The defect lives in AppKit/SwiftUI window plumbing inside SceneApp, which swift test (SceneCore only) structurally cannot reach — so no unit test would have caught it and none is added to pretend otherwise. Verified against the running app instead: the Layouts toolbar now reports Add, square.on.square.squareshape.controlhandles, Bin, arrow.counterclockwise, Restore Default Presets, and Workspaces reports New, Duplicate, Bin. The code path now carries a comment naming this trap.
• Universal binary (arm64 + x86_64), macOS 14+, Apple notarized.

Install

Download Scene-0.7.5.dmg below or via brew install --cask chifunghillmanchan/tap/scene. Drag Scene.app to /Applications, then follow docs/INSTALL.md for the one-time Accessibility-permission step.

Upgrade notes

V0.5.6+ users: click Update available in the menu bar and Scene swaps itself for the new bundle and relaunches; Accessibility permission survives the swap. No data migration — your layouts, hotkeys and workspaces are untouched.