UPDATE: The "NSStatusItem does not receive mouse hover/movement events on macOS" (FB23329983) seems to be fixed in macOS 27 dev beta 5 (build 26A5406e). The following issues still remain: inability to set NSStatusItem button highlight cannot be set programmatically (B23330269), for which expandedInterfaceDelegate gives a partial solution. NSStatusItem window occlusionState no longer reflects hidden menu bar visibility (FB23349447) Additionally, there is a somewhat serious design issue/oversight with expandedInterfaceDelegate and expandedInterfaceSession when it comes to implementing touch support. With a custom menu bar extra window implementation (when one uses a custom NSWindow or NSPanel and for the menu bar extra app's window together with the new expandedInterface..., instead of relying on the traditional NSMenu or NSPopover attached to a menubar extra status item) there is no mechanism at all to detect touch tap gesture outside of the window. This would be essential to figure out when the user wants to dismiss the menubar extra window. Previously, the normal pattern was to use a global event monitor to act when the user clicks outside of the window - with this the app could trigger closing the menubar extra window. Touch events are not covered by this mechanism and there is no alternate API of any kind. So menubar extra apps (which do not use NSMenu or NSPopover or the basic SwiftUI menubar extra solution) simply don't have any means to detect the user intent to close the menubar extra window (when the user taps outside of the window). A less than ideal workaround may be to track loss of key window status maybe, but that is not fool-proof, especially if one designs an app in a way that the menubar extra window does not grab key status or focus at all.

Related to this: FB23688090 https://github.com/feedback-assistant/reports/issues/821

But of course the expandedInterfaceDelegate does not solve the issue of programmatically creating a highlight (for the purposes of programmatically showing the menubar app window or showing an OSD interface tied to the menubar extra icon), so this is not a complete replacement - it just helps to fix the lack of highlight when an user starts interacting with the NSStatusItem.

Update: to solve the button highlight issue, one should use NSStatusItem's new expandedInterfaceDelegate. https://developer.apple.com/documentation/appkit/nsstatusitem/expandedinterfacedelegate Mouse tracking and occlusion detection of an NSStatusItem (or its button) is still an unresolved issue, there is no modern alternative afaik.

All these seem to be broken in macOS 27 dev beta 3 (26A5378j) as well.

No, it does not seem to be possible. It would be great to have design elements or rendering options depend on macOS version (legacy vs 26+) in Icon Composer - this would eliminate all problems of course. But this feature is missing and by this time it is very unlikely Apple will improve the functionality in this regard.

No solution afaik. I am still on Xcode 26.0.1 because of this. My plan is to simply drop pre-Tahoe (and Intel) support for newer versions of my stuff when macOS 27 lands and leave all this mess behind. :)

An other, related issue with CGSetDisplayTransferByTable() - this is probably not the best place to note this, but since macOS Tahoe there is an inconsistency in how the API works. The 26.4 RC is also affected. Before macOS Tahoe CGSetDisplayTransferByTable() redefined the color table of the SDR range and clipped the HDR range (much like custom color profiles in macOS usually do the same). In macOS Tahoe it does the same thing for most displays – except for the built-in XDR displays, when auto brightness is enabled and the display is in EDR mode (meaning: there is some HDR content on screen). When this happens (XDR + auto brightness + EDR mode), the contents of the CGSetDisplayTransferByTable is being used to multiply the entire EDR (SDR+HDR) gamma range instead of overwriting the SDR range and clipping the HDR range. This might be a blessing in disguise for some apps (that use this feature for color adjustments or brightness upscaling like BetterDisplay - as this allows avoiding HDR clipping when a custom color table is being used for image adjustments), but since the behavior is inconsistent (with auto brightness disabled the very same function does affect only the SDR range and clips the enitre HDR range at 1.0 - peak SDR - luminance level as it used to do pre-Tahoe), this is probably just a bug, not a feature. Additionally, when a custom color table is applied to a built-in XDR display while in EDR mode is active, when the user turns of auto-brightness, the color table usually ends up in an inconsistent state (and the screen looks permanently bad until the user changes presets or do something similarly drastic) even after the app using CGSetDisplayTransferByTable() is terminated. I do not have an FB filed for this one as honestly I saw very low chance of it reaching the appropriate engineers (being such an edge-case) - just wanted this to be out in case somebody in the team working on these things can do something about it. :)

Once again, CGSetDisplayTransferByTable appears to be broken, but specifically for the latest Macs - the Neo, the M5 Pro and M5 Max. Happens on 26.3 and 26.4 beta4. Received multiple reports about this. Involved Macs were tested with multiple apps that rely on this, like BetterDisplay, MonitorControl and f.lux.

Yes, fixed! Nice!

This is about the same issue - Apple confirmed the problem. https://developer.apple.com/forums/thread/814798?answerId=875058022#875058022

I am super relieved it's not only me hallucinating all this and others encountered this as well. :) I narrowed down the issue to .styleMask.remove(.titled). Depending on other styleMask flags and NSWindow properties, this can result in (1) an inability to resize the window or (2) a kind of click-thru effect - the content does not seem to capture mouse events but the window acts as if it would be transparent to user interaction.

FB21879057

Update: BBEdit devs stick to Xcode 26.0.1 for now, there is still no known workaround to the problem.

Interestingly the latest version of BBEdit has an Assets.car that contains both the icon composer vector components for a Tahoe icon and different, clearly non-icon composer rendered legacy icons. Wonder how they did it.