It’s rare for an app to not have a range of image assets.

We use images because they make it easy to portray complex ideas. What may take a word or even a sentence to describe, could be done in the space of an image that’s a mere 20x20 points.

Alas, the unfortunate thing about images, is that they take up a lot more storage space than a sentence or two. So much more in fact, that some apps can grow to be hundreds of megabytes.

Brief history of the humble Asset Catalog

I have worked on apps in the past where effectively all of the content in the app has been delivered through images. Yes, there were reasons. This resulted in our app size being >250MB.

This was after retina iPads (2012) had come to the market and before Image Assets (WWDC 2013) and App Thinning (WWDC 2015) were introduced.

Management of assets had been somewhat clunky back then. Before Xcode 5, everyone essentially had image.jpg and image@2x.jpg littering their Xcode project hierarchies (not to forget the ~iPad versions too). The project I mentioned, had hundreds of these files.

With the introduction of the Asset Catalog things became much easier. No longer were we required to name our images in a specific way. We could even hide them all away into their own special folder Content.xcassets and no longer would our Super Secret.xcodeproj/project.pbxproj be messed with when we added or removed some assets.

Asset Catalog received little improvements over time. Apple added the ability to mark an asset as needing a specific Metal version or be for a particular width / height class, add vector PDFs, even add arbitrary pieces of data.

With App Thinning, we received a great optimisation. The default was that when we shipped an app, a user would download all of the assets — regardless of the device they were using. With App Thinning, if we used Asset Catalogs and correctly marked our assets, the user would only get assets that are relevant for their particular device.

This meant that our customers could save a significant amount of space on their device. They would no longer download @2x iPad images to their iPhone 5s.

That old project I mentioned? With App Thinning, the 1x iPad version became a 53.6MB download, instead of 274MB for the universal version.

New additions to Asset Catalog

WWDC 2018 has revealed some seemingly heretofore undisclosed details, as well as introducing some interesting new features to the Asset Catalog.

Automatic Image Packing

One of the optimisations described, is that Asset Catalog analyses all of the images that are added. It then attempts to group images that share similar traits (e.g. colour spectrum, gamut) and with this collection, it creates a texture atlas.
The logic behind it is that when an app has lots of similar images, especially if they’re already small, the continuous repetition of the metadata consumes the very space it is meant to be saving.
The example used onstage claimed up to 80% saving when Automatic Image Packing took place.

Lossy compression

New feature coming with Xcode 10 is that Asset Catalogs will now use HEIF for the storage of lossy images. As HEIF is meant to have a better compression ratio than JPEG, this should see us shaving some more space off our app bundles.
The presenter did point out that HEIF also supports transparency. As such I would expect PNG images which contain transparency, that are marked as lossy, to be converted to HEIF. But as for default settings for PNG, well that leads us on to…

Lossless compression

Introducing: Apple Deep Pixel Image Compression.

Based on the type of category that your asset can fall into:

1. Icon and simple artwork (i.e. narrow colour spectrum, small amount of distinct colour values)
2. Complex artwork

Asset Catalog will select the optimal compression algorithm to use. With this, Apple is seeing a 15-20% size reduction.
But if that wasn’t enough, with ADPIC, Apple have observed an up to 20% improvement in decode time.

Other than the above, no huge amount of specific detail was really given on this new compression.

OS Variant Thinning

As it currently stands on iOS 11 / Xcode 9, Apple takes a utilitarian approach with App Thinning.
Older iOS versions are not able to utilise new optimisations. So when an app is targeting a range of iOS versions, when App Thinning takes place, it would generate a bundle that can be used across the whole range that you’re targeting.

With this in mind, Apple is introducing OS Variant Thinning. A project that now targets a range of iOS versions, will have its Asset Catalogs compiled into iOS version specific bundles. This means that the older versions of iOS will get their own optimised assets and the newest iOS will benefit from the new optimisations that are added.

Another way to think about it: consider the new lossy compression that Asset Catalog is going to use. HEIF was only just introduced with iOS 11. If your app was targeting iOS 10, when App Thinning took place, the lossy compression it would need to use would be JPEG. This means the new improvements could take a quite some time to propagate.
With OS Variant Thinning, the iOS 12 device would get the lossy assets encoded with HEIF, whilst iOS 11 and older would get theirs with JPEG.

Summary

The use of texture atlases, using HEIF for lossy images, as well as new lossless compression being tailored to the specific image characteristics, make this a great update to Asset Catalogs.

If for some reason you were not using Asset Catalogs yet, you really should start. The benefits that come from simply using Asset Catalogs are way too good to pass up.