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.

This solution no longer works in 26.1, --enable-icon-stack-fallback-generation=disabled seems to do nothing. Is there an alternate solution?