actool Strips Larger Icon Sizes
Max Seelemann’s App Store upload failed because the high-resolution versions of the icon were missing:
It turns out, the icons actually were not there… but obviously we had them in the source asset catalog. We didn’t change the asset catalog or how icons are created in months.
[…]
It started dawning on me… if we didn’t notice others might not have as well? A quick check in the app folder… yep, other recently updated apps like @pixelmator, @vectornator, or @dayoneapp show the same problem. It even affects Apple’s own apps like KEYNOTE!
[…]
1) iconutil requires images in an “iconset” to be named like “icon_16x16.png” etc. – actool seems to be more flexible (but strips the larger sizes)
[…]
2) Seems that Finder no longer takes the app’s icon from the icns file. Instead, it reads the embedded asset catalog (if there is any).
So you can’t just add an .icns file and use it – if you have an asset catalog, the icon must be compiled in.
3) You cannot compile an app icon in an asset catalog without actool also writing the icns file. Whatever you do … you need to replace that icns file in later build phase.
I haven’t been using asset catalogs because, last I checked, they don’t work with frameworks. There’s no public API to look up an image in a given asset catalog; it only checks the one at the top level.
See also:
Update (2020-04-29): I don’t know how I missed this, but the Bundle.image(forResource:) API seems to work for looking up images in a framework.
Update (2020-05-19): Max Seelemann:
Btw my understanding by now is that either all app&document icons must be .icns or all inside asset catalogs. You cannot mix the two. So if I had removed all file icons from the asset catalog, Finder would have fallen back to using the ICNS file.
1 Comment RSS · Twitter
Your link for "don't work with frameworks" actually seems to include a way to make the work with frameworks.
One of those things where someone has to tell you because hey what d'you expect, documentation?
