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?

Amazing! Thanks @superpixel! Adding the secret undocumented --enable-icon-stack-fallback-generation=disabled to the ASSETCATALOG_OTHER_FLAGS build setting does work on Xcode 26 beta 6. What I do is enable this, disable "Include all app icon assets" and copy a separately compiled AppIcon.incs (with the legacy icons) to the Resources folder while making sure the CFBundleIconFile is in the Info.plist pointing to this file - this results in the correct icon showing up on older macOS versions, while Tahoe uses the Icon Composer variant. This should work on macOS (not sure if works for App Store, but my app is not an App Store app, so it does not matter). An other way is to have "Include all app icon assets" which generates the proper variants in Assets.car, but it bloats the bundle size somewhat (especially as I have some assets that depend on build configuration and this option makes all those into the bundle) - this might be the proper way though. Hope Apple fixes this properly though or add least adds a proper, documented build setting with a guarantee that this (rather hacky) solution won't go away suddenly in a future Xcode update.

Sadly nothing changed in Xcode 26 beta6 it seems. :(

I still couldn't make .scrollEdgeEffectStyle(.soft, for: .top) work in macOS Tahoe ever - even though we are at beta6 now. The .default (.hard) works fine though. Glad to see that the .soft option at least do something on iOS (even if the effect is evolving). I get around this bug (?) by using all kinds of hacks to mimic the intended blur effect. UPDATE: I was trying to use .soft with .safeAreaInset. Apparently with .safeAreaBar the .soft effect works in Tahoe, while with .safeAreaInset it does nothing (only .hard works). This is somewhat counter-intiutive and I don't remember the documentation implies that it should behave like this.

I received a note to FB19118531 saying Apple Engineers will look into the issue. In Xcode 26 beta 5 there is a slight change - now the .incs file also has the icon composer generated icon (under Resources in the app bundle) with the wrong corner radius (that matches older macOS versions), making any icon that relies on the proper corner radius look bad. This means that the developer supplied Assets app icons are entirely disregarded. I still feel that either if the developer supplies a legacy App Icon, it should be used for older macOS versions both for the .incs file and Assets.car. Or at least have the option to have the icon composer generate icons with the new corner radius even for older macOS versions (imho that does not look out of place as older macOS versions had icons in all kinds of shapes - obviously for iOS this is not a viable solution).

This appears to be fixed and working fine in Tahoe dev beta 5. Closed FB19136488.

Nice! I also tried to replace the generated pngs in the Image Stack found in the CAR file, but gave up after a few rounds. I found that the icon with the same ID has all the Icon Composer assets, and the 16x16, 32x32... png variants of the rendered Icon Composer images (with the wrong corner radius) for older macOS versions. Although I could get these details using assetutil I was not able to replace or remove the images (the assetutil just does not have the right filters to somehow get rid of them). I tried looking at it using a hex editor and although I could locate the images, I don't know how to edit the CAR file in a way that it remains valid. If you have a workflow to replace/update specific images in a CAR file that can be shared with others, or can point to a tool, let us know! :) Thank you!