Improving asset catalogs

Conceptually, I like asset catalogs. It makes sense to group images and metadata together, with a visual way to edit it all in Xcode.

However, in practice asset catalogs have made common tasks slower and more difficult, reduced our ability to automate design integration, and increased the chance of errors. This is largely due to the format used for asset catalogs and Xcode’s behaviour.

Adding and replacing images #

Images can be batch added to an asset catalog by dragging them into Xcode. That’s perfectly reasonable in some scenarios, but it does require one drag per asset catalog. For app icons, each size needs to be dragged in one by one.

That’s 19 separate actions to drag in the 14 different iOS app icon sizes (if you’re careful with file names and select all the pixel densities at once, you can reduce this a bit). In cases where icon sizes are the same and an identical image is likely being used (iPhone home @2x and iPhone spotlight @3x are both 120px), dragging the same image twice into the asset catalog results in duplicate files. There’s 42 different image sizes required for watchOS Complications. I really think asset catalogs should be smarter and provide easier ways to batch add files. Xcode knows the image dimensions required, and it knows the image dimensions of the files I’m dragging in. Use them.

Dragging in a file called icon-120.png into an app icon asset catalog twice duplicates the file, with the handy filename of icon-121.png.

We automate our asset exporting as much as possible, and image files are treated as ephemeral — our build process for images typically rebuilds the entire set. That means it’s common for us to have 100s or 1000s of images to update.

There’s no easy way to replace images in an asset catalog while maintaining slicing, tiling and other metadata. The best workflow we have is to remove all images and re-add them, then manually set the metadata again, or handle all slicing and tiling in code, negating the benefit of using an asset catalog.

Format #

The image maintenance issues noted above wouldn’t be a problem if asset catalogs were easy to work with in the Finder, but they’re not. Asset catalogs include a folder for each asset, with the respective images and a JSON file inside (the JSON contains the metadata). If you’re trying to replace 100 assets, that‘s 100 error-prone drag or copy and paste actions in the Finder.

A few small changes to the way asset catalogs are stored in Xcode projects would allow easier batch image replacement, resolving the issues with Xcode’s behaviour. Removing all the folders and using the asset name for the JSON would do it. If you’re looking at generating or editing asset catalogs, Apple does provide good specs on the asset catalog format (thanks to Kit Grose for the link).

The compiled format requires a tool to inspect asset catalogs. Why? Images are already compressed and JSON files are small. It feels like needless obfuscation.

Scope #

You can provide namespaces for assets, but by default everything has global scope. Enabling provides namespace will let you control asset scope via the group name, but I feel like there are lots of oportunities to improve how this works. Design scope is almost as important as code scope, especially on big projects.

Vector assets #

I have no desire to be polite about it any more — PDF is a garbage format for interface assets, and it should not be used by anyone. If you’re using PDFs, your project is being harmed. Apple should not promote PDF usage, and PDF support as an asset format should be deprecated immediately.

I would like to see a new vector asset format created that addresses the specific needs of user interface elements. A compact, human editable format with ways to integrate dynamic colours and animation. It could even be based on SVG path commands, to make the format easier to author. I really hope we see some improvements on this front at WWDC 2019.

These issues are all fixable, but it would require Apple to have a deep understanding of what’s wrong with the current format, and the desire to correct it.

Published 1 May 2019.