Apple shifts its icon guidelines

I’ve been reading the Icon Design Guidelines in the OS X Human Interface Guidelines today and noticed that Apple not only added one size of icon that should be created for use on Retina Macs, but they expect you to create the whole icon set twice. And also they’re no longer recommending using the ICNS format.

Table 5-1 of that document tells you to create the following icon sizes, each as a PNG file prefixed with the icon name:

Filename	Size of canvas (in pixels)
icon_512x512@2x	1024×1024
icon_512x512	512×512
icon_256x256@2x	512×512
icon_256x256	256×256
icon_128x128@2x	256×256
icon_128x128	128×128
icon_32x32@2x	64×64
icon_32x32	32×32
icon_16x16@2x	32×32
icon_16x16	16×16

Icon files with the “@2x” part are meant to be shown on a Retina display. Apple expects you to create icons with less details for use on Retina screens instead of just using the standard bigger ones. That means 10 icons instead of 5. Well, probably not: I guess you should only create separate icons when appropriate.

The other change is the disappearance of a mention of the ICNS icon format. Not that this format has stopped to work, but the recommendation now is to use PNG files with the names above instead. I wonder how backward compatible this is.

Documentation on this matter is scarce. This seems like a last minute change. The Icon Design Guidelines seems to mention the naming convention only in relation to the app’s icon, but I have a hard time to believe it can’t be applied to other ones (I would guess the “icon” part of the file names above refers to whatever icon name you specified in your Info.plist, but that isn’t said). Perhaps they gave more details to WWDC attendees.

The funny thing is, if you look at the content of TextEdit in OS X 10.7.4, all the icons are still ICNS icons. But if you open them with Preview, you’ll see the files contains two 32×32 icons, two 256×256 icons, etc. in short each file contains all the 10 representations specified above. And even though the icon file contains duplicated sizes, they haven’t bothered changing the level of detail or anything.

So they did update the ICNS format so it can contain all those fancy “@2x” icons, but they don’t want us to use that for some reason. I’m puzzled.

Update: In the comments Philippe Wittenbergh points out that further down below in the section “Packaging Your Icon Resources” they explain that those PNG icons files should be put in a folder ending with .iconset and run through the iconutil command line tool to create the ICNS file. I guess this is my failure to read through the whole thing. This sentence is interesting: “You must use iconutil, not Icon Composer, to create high-resolution .icns files.” What happened to Icon Composer? This really does feel like a last minute change.

Comments

Philippe

Well, the two 256×256 icons (e.g) have different dpi – 72 and 144, according to Preview. Further down the apple document you linked to, they explain the workflow (under the heading ‘Packaging Your Icon Resources’): create the PNG files, then package them with iconutil.

Thanks for noticing the HIG has been updated (it is very recent) to describe this, and letting us know! I had been looking for that kind of info.

Brian

I think the primary reason for the change was that working with assets embedded in a .icns file is a pain in the butt for graphic designers. Now, they can edit individual png files within a .iconset folder (or export to the folder from a template) without having to worry about cracking open the .icns just to get at a single icon. Xcode takes care of “compiling” the .iconset into a .icns file using the iconutil tool when the app is built, and the resulting .icns is what’s used by the shipping application.

Nicholas Riley

I’d suggest you take a look at the video (or at least the slides) for WWDC 2012 session 213. You may be pleasantly surprised, and I hope the information therein makes it to public docs relatively soon.

Michel Fortin

Thanks Nicholas for the tip. Although unfortunately sessions videos are not available by session number but by title, so one would need to look for the session title related to high resolution on OS X instead. They’re indeed giving the reasoning behind the the .iconset format. I think Brian explains it well. So bye bye Icon Composer, long live ICNS.