+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

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

It would be great to have a simple way to enforce alternate icons for older macOS versions in XCode while using the Icon Composer generated ones for Tahoe. Prior to Xcode 26 beta 4, one could add an App Icon set to Assets for legacy macOS versions and use the an Icon Composer variant in the project root for Tahoe. Enabling "Include all app icon assets" under target settings also helped according to some. This option is now gone, Beta 4 insists on populating the Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. The App Icon variant in Assets makes its way to a .incs file in the app bundle's Contents/Resources folder, but that is not used by macOS anymore and is there for some compatibility purposes. The Assets.car file (which matters) only contains the png variants generated by Icon Composer. Several app developers (especially with icon designs that try to follow the curvature of the standard icon size) are struggling with this issue.

This no longer seems to work with Xcode 26 beta 4, at least for macOS. Beta 4 insists on populating the Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. :( The App Icon variant in Assets makes its way to a .incs file in the app bundle's Contents/Resources folder, but that is not used by macOS anymore and is there for some compatibility purposes. The Assets.car file (which matters) only contains the png variants generated by Icon Composer. Since the default icon rounding radius is different, I can't use the Icon Composer generated icon for older macOS versions (the icon design needs to follow the curvature of the icon background) as that would look super-ugly. Icon Composer has no option to add variants for older macOS versions, so I need to use custom icons. Xcode 26 beta1-beta3 at least gave the option to do so with this workaround.

Yeah, this does not seem to work even with Xcode 26 beta2.

Of course, thank you! FB17797423 I also added some more details and info about how to reproduce the issue quickly with the app BetterDisplay which contains the feature of both creating virtual screens and showing their content in Picture in Picture windows. One can consult this GitHub issue/discussion about reproducing the problem quickly (and get a bit more info): https://github.com/waydabber/BetterDisplay/issues/4405 Quick steps to reproduce the issue with BetterDisplay installed: Steps to reproduce: (0. Enable Screen Recording permissions for the app.) Set up two virtual screens (app Settings - gear icon - > Displays > Overview > Create New Virtual Screen), name them ("Virtual 1" and "Virtual 2"). In the app menu, connect the created virtual screens (toggle in the header), and then launch a Picture in Picture window (this uses SCStream) for both screens (see the Picture in Picture menu item in the app menu for the virtual screens). Show some content on the virtual screens or use "Identify Visually" (quick way: OPTION + Click on the header in the virtual screen’s header in the menu block) to confirm that all is well at this point. Disconnect "Virtual 1" (using the toggle in the menu header) Reconnect "Virtual 1" (using the toggle in the menu header) Reopen the PIP window for "Virtual 1" Confirm that the PIP window "Virtual 1" shows the content of "Virtual 2" I am happy to provide more info and share the relevant code or the app is using to reproduce the issue in XCode (but regarding SCStream, everything is done according to the book, so there is not much to share). I think the root cause is that whatever SCStream (and previously CGDisplayStream) relies upon ends up working with the wrong framebuffer (?) in certain cases when virtual screens are involved (note: interestingly, if confused virtual screens have different dimensions/resolutions, the streamed content is clipped, so the dimensions reported by SCContentFilter is properly taken into account - the native macOS Screen Sharing menubar extra item also shows the wrong, clipped content - to me this shows that the ScreenCaptureKit API at some higher lever tries to do the right thing).

Hi there, thanks again for fully fixing the hang/slowdown issue in the latest versions of XCode 16. :) The SourceEditorDataSource.contentRangeForLineRange(_:) + 244 issue/crash when trying to commit a localization change still persists. I am sure there is an offending character somewhere in the project's Localizable.xcstrings, but since this is now such a monolithic file with all languages combined, it is simply not possible to pinpoint where the issue is + the issue would just reintroduce itself as translators submit new translations. Would it be possible to somehow escalate and fix this issue as well? I am sure others encounter similar issues. I posted a new thread about it so the issue is not conflated with the hang issue which is now fully fixed: https://developer.apple.com/forums/thread/767230?page=1#811224022 Thank you!