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!

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

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

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.

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

Should this now work in macOS Tahoe dev beta4 or it's me doing something wrong? I am trying to use the .soft variant together with safeAreaInset. The default .hard works just fine, but .soft does not seem to be doing anything. The documentation does not say anything about safeAreaBar as a requirement.

Note: I also added an issue about it in case an Apple Developer would kindly look into it and give directions on how to get around this limitation: FB19118531 Thank you!

Ok, I did some digging. According to assetutil it seems like Assets.car contains an iconstack that has all the vector layers, color data etc for the glass icon and the traditional MultiSized Image with all the icon size variants for legacy macOS versions. In beta3 however (probably due to a bug) the MultiSized image variants were not created based on the Icon Composer image (only a single 1024x1024 variant was created). This gave way for the .incs file compiled into the app root to be taken as icon image on legacy macOS versions, which feeds from the proper xcassets icon file provided by the developer, not the Icon Composer generated pngs. In beta4 this was "fixed", so now all size variants 16x16, 32x32...512x512 variants of the Icon Composer based MultiSize Image items are compiled into the Assets.car file - so macOS takes these now. Sadly there is no way to somehow replace these variants with the proper, developer supplied image or remove them (so the .incs file could be taken by legacy macOS versions instead) - the only tool assetutil that is given to manipulate .car files is extremely limited. I really hope Apple will fix this. I don't see why it would be beneficial to entirely disregard the developer supplied App Icon asset and instead render (somewhat oddly looking) variants based on Icon Composer icons meant for glass (it should happen only if the developer does not provide custom App Icons suitable for older macOS versions). An alternate solution would be to improve Icon Composer so it could take icon composition variants for legacy OS versions and the developer (so instead of only "watchOS" and "iOS/macOS" these should be a third "legacy iOS/macOS" option). This could at least enable developers to supply vector and bitmap images that match the legacy icon size/corner rounding. Also there should be a preview option in Icon Composer how the icon would look on older OS versions - the way that Icon Composer now "silently" produces entirely different looking variants for macOS 15 without a developer using Tahoe ever even seeing how it actually looks like is clearly not the right way to go.

I posted this as a new separate question, maybe an Apple engineer will respond: https://developer.apple.com/forums/thread/794485

I posted this as a new separate question, maybe an Apple engineer will respond: https://developer.apple.com/forums/thread/794485