Separate Icons for macOS Tahoe vs. Earlier
Looks like Tahoe/Xcode beta 5 no longer lets me show my pre-Tahoe app icons in pre-Tahoe OSes. This is a bummer. I filed FB19437407 asking for the ability to do this.
I was also looking into how to do this. I had read that you could just keep your old icon in the .xcassets and use the same name for the new .icon file, and it would all just work: new icon on Tahoe and old icon on older versions of macOS. But I found that the old icon didn’t make it into the built app, and even the generated .icns file for backwards compatibility was low-resolution.
By default, yes,
actoolwill ignore .xcassets compatibility bitmaps that match the name of your app icon, and will instead substitute its own. However, if you use the super duper secret undocumented--enable-icon-stack-fallback-generation=disabledflag, it won’t. See here. This worked as of db4; I really hope they didn’t break it in db5.
This did not work for me with beta 5.
Václav Slavík found that it does work to separate names for the .iconset (for CFBundleIconFile) and .icon (for CFBundleIconName), not putting either in .xcassets, and this seemed to work for me, at least with his test project. But this approach didn’t work for Siracusa.
There’s apparently something special about app icons stored in Assets.car, it’s not just the name, and that’s what is throwing a wrench into things.
Previously:
Update (2025-08-09): John Siracusa:
The approach used in the [new version of the] sample project referenced here did work for me.
It uses a shell script to call actool and PlistBuddy.
1 Comment RSS · Twitter · Mastodon
It broke even for Apple. XC26 betas 2-4 had the original beta icon on macOS < 26. Now with beta 5, it's the disgusting Tahoe icon. Not just for Xcode, but for Simulator, Instruments, etc. Yuck
