How can you get the wanted result on macOS 26? I was not able to provide glass icons for macOS26 while setting pre-rendered icons for macOS 15 and earlier. Xcode always forces Icon Composer rendered variants for older macOS versions instead of the icons I provide in the Asset Catalog. https://developer.apple.com/forums/thread/794485 (sorry for the somewhat tangential comment and not being able to help with your original issue - but I think the macOS and watchOS situations are related - Xcode does not seem to allow developers to provide their own icons for older OS versions when an Icon Composer icon is present).

Sadly the current answer is: NO. The latest Xcode will simply disregard your icons in Assets for older OS versions and insists on using the out-of-place Icon Composer rendered variants instead using a corner radius it thinks is suitable for that older OS version (note: you have no way of previewing the resulting icons anywhere, so it "just happens" silently and if you don't test your app on older OS versions, you'll never see it...). Apple even mentions this on the Icon Composer page: "The latest version of Xcode uses the Icon Composer file instead of an existing AppIcon asset catalog in your project." (https://developer.apple.com/documentation/Xcode/creating-your-app-icon-using-icon-composer#Add-your-Icon-Composer-file-to-an-Xcode-project) Here are some other threads about this same issue: https://developer.apple.com/forums/thread/794485 https://developer.apple.com/forums/thread/794567 https://developer.apple.com/forums/thread/788466 I really hope Apple fixes this, I spent many hours trying to get around this limitation, including trying to edit that damned Assets.car file which contains the wrong renders in your app bundle.

For macOS I simply use an .icns file, and keep the Asset Catalog with only iconstack-based icons. If you want proper glass icons, this approach won't work. In Xcode 26 beta3 one could indeed use Image Composer icons for Tahoe and also let an .incs file be generated based on the App Icon image stack in the Asset Catalog. That gave Tahoe full glass icon support while older macOS versions took the icons from the .incs file (instead of the Assets.car file). However this was apparently just a bug, made possible by the fact that Xcode added only the 1024x1024 legacy render of the Icon Composer icon to Assets.car's image stack, leaving room for older macOS versions to fallback to the .incs file which is always generated (even in beta4) using the Asset Catalog App Icon. Since beta4 however if an Icon Composer icon is present, the image stack in Assets.car contains all Icon Composer assets and color data, bundled with all size variants of a rendered version, using the standard legacy icon format (using the old corner radius). Because of this even though the .incs file is there and is still generated based on the Asset Catalog's App Icon image stack, it is not used by legacy macOS versions - macOS always prefers the Asset Catalog icons (no fallback is happening to the .incs file).

+1 on this. Also filed a report a while back - FB19136488 CGSetDisplayTransferByTable does not work on Apple Silicon Macs (MBP) with built-in displays when "Automatically adjust brightness" is on. The issue is present in all macOS Tahoe betas (developer beta1-beta4, including build 25A5316i). Reproduce: Enable "Automatically adjust brightness" in System Settings/Displays try to apply a gamma table using CGSetDisplayTransferByTable Unexpected behavior: gamma table does not get applied Then: Disable "Automatically adjust brightness" in System Settings/Displays gamma table gets applied after about a second The issue affects many popular apps like BetterDisplay, MonitorControl, f.lux, Lunar etc that rely on CGSetDisplayTransferByTable() for some features.

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!

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

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).

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.

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

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.

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

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.

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

FB21879057

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.