Smaller Mac app icons

In an effort to reduce the final app size of iStat Menus, we’ve been investigating ways to slim down our app icon. It’s currently about 1.22MB, which is normal for an app icon, but a decent percentage of our bundle.

As part of the research, I tested which assets are used across the various places icons are shown in macOS. The goal was to identify if we could remove certain icon sizes, or intentionally degrade specific sizes via lossy compression.

To test, I created an app icon that shows a different colour for each asset size, with a white sash added for the non-Retina versions.

Retina display results #

For the dock, the 128pt 2× (256px) asset is always used, no matter how big or small the dock is, and even when magnified. Launchpad uses the 256px 1× non-Retina asset, even on a Retina display. This feels like a bug?

The dock and Finder column view info pane display sizes in pixels are approximates, but should be pretty close to the actual sizes.

Non-retina display results #

The same tests were run on a non-Retina display by Kit Grose (thanks!). Everything matches what you’d expect, and Launchpad uses the correct, non-Retina asset.

All the icon assets are used somewhere, and omitting sizes doesn’t seem wise.

Lossy compression #

The 1024×1024 app icon asset is only used in two places — the Finder when using icon view with a size over 264pt, and in the Finder’s column view info pane. The icon view only shows an unscaled asset with a size of 512pt, and the column info pane’s icon is always scaled down. With that in mind, lossy compressing just the 1024×1024 icon using pngquant seems like an acceptable trade-off in quality. Pngquant converts PNGs to indexed colour images, while maintaining alpha transparency. It’s a lossy technique, but depending on the source image, it can look good and be far smaller. If you’re going to do it, I’d recommend 256 colours, and you may as well use the best quality, because it’s a quick process.

pngquant 256 --speed 1 icon-1024.png

The 1024×1024 app icon asset is almost always shown scaled down, so the quantisation of converting to an indexed PNG is partially undone, because the scaled icon averages out the errors. The comparison below shows the most obvious differences in our icon, zoomed really far in. I think it’d be very difficult to spot the difference in the Finder. For icons that don’t contain gradients, the results will likely be even better.

So far, we’ve opted to not use this technique for iStat Menus, but if you’re looking to shave a little more off your final app size, it’s good.

Asset catalog duplicate files and recompression #

By default, asset catalogs for Mac app icons end up with lots of duplicate files — 32×32, 64×64, 128×128, 256×256, and 512×512 are all included twice, even if the same files are used when importing into Xcode. App thinning likely removes duplicates for App Store apps, but that doesn’t help web downloaded apps. Apple’s version of PNGCrush is also used to recompress images, which typically makes files a lot larger than they need to be. The good news is that indexed PNGs are preserved, so running pngquant does still provide benefits.

We haven’t yet figured out how to stop Xcode from recompressing PNGs as the asset catalog is created. COMPRESS_PNG_FILES=NO and ASSETCATALOG_COMPILER_COMPRESS_PNGS=NO don’t alter the behaviour.

If you know how to stop PNGs from being recompressed, please get in contact.

Potential sizes #

If Mac app icon asset catalogs could just store a single set of the sizes needed, and if the PNGCrush recompression step could be avoided, Mac app icons could take up a lot less space. Here’s the results for our app icon.

Published 12 January 2023.