Why I don't use PDFs for iOS assets

I understand the attraction. Generating fewer assets and automatic support for present and future display densities seems appealing and convenient.

Under the hood, Xcode turns PDFs into PNGs for the relevant sizes at build time, so the shipping binary is very similar to an app created using PNGs. There may be minor differences in file sizes, because the PNGs were created by Xcode, but ultimately they’re very similar (using ImageOptim or choosing PNG8 for certain assets may give a non-PDF app the edge).

The running app is almost identical, file and performance-wise. This is unlike the web, where using SVG can yield many benefits. It’s also unlike Android’s Vector Drawables, which are drawn at runtime, like web SVGs.

The only benefit in using PDFs for iOS app assets is for convenience, which would be ok, if the PDF file format wasn’t terrible for many kinds of interface assets.

The Portable Document Format (PDF) is great for its intended use — as a document format for content generated in print design tools, for screen and printed output. Its origins in PostScript are very apparent, in terms of features. And, it’s no surprise Apple have great PDF support in macOS, given Display PostScript’s use on NeXT.

1× bitmaps #

Many features in your design tool of choice will be saved as a 1× bitmaps — blurred shapes, some masking, layer styles, shadows and other effects are typically stored in PDFs as a bitmap image, and a 1× bitmap image at that.

When the PDF is scaled by Xcode, your 2× and 3× assets will be created from a 1× bitmap for those portions of the asset, because that’s all the PDF contains. The results are really poor.

The left example above shows a PNG created from blurred shape. A PNG asset created by Xcode from a PDF of the same artwork is shown on the right. Note the bitmap scaling artefacts.

Masking #

Masking is also an issue. The example above shows a red circle with an inner glow effect. There are red pixels showing through the antialiasing on the right, PDF version. In PDFs, inner effects are separate elements. There is no ability to clip an object to another, while maintaining correct antialiasing. (I’m aware the inner effect examples above don’t match perfectly.)

I suspect many types of gradients would also be rendered poorly as PDFs, but I didn’t do any testing to confirm.

Bitmap scaling of effects and poor masking support are the strongest arguments against using PDFs for iOS interface assets.

Rendered by Quartz #

macOS’s 2D rendering engine, Quartz, is great. But, if you’re using a design tool that doesn’t draw using Core Graphics, there’s a good chance what you’re seeing when designing will look different to the output generated by Xcode’s PDF rendering. Photoshop’s antialiasing and gradient rendering is fairly different to Quartz’s.

Your design tool may or may not be giving you an accurate representation of the final app. That’s a significant issue if you care about the quality of your work.

In contrast, using PNG assets means everything matches bit for bit — an image diff of the running app vs the mockup shows the results are identical.

Assets can’t be used elsewhere #

PDFs can’t be used for web or Android assets. Mac apps can use PDF assets, and they’re rendered at runtime, giving many benefits over iOS’ implementation.

No support for spot colors #

macOS’s PDF rendering doesn’t support print spot colors. This shouldn’t be an issue at all for interface design. I’m mentioning it here only for completeness (although it can cause problems in rare cases).

Xcode 9 and preserving vector data #

Xcode 9’s changes to asset catalogs, and support for also including PDFs in app bundles doesn’t change the advice above. Even with an iOS 11 deployment target, Xcode still generates PNGs from your PDFs. Here’s the asset catalog of a small test app I created. It contains one PDF.

But, when the app is built, the asset catalog now contains 3 PNGs. Those PNGs aren’t the same as PNGs you’d create yourself, either. Xcode’s PNGs were 20837 bytes total, exporting them from Sketch resulted in 17324 bytes, and running the Sketch PNGs through ImageOptim with lossless compression reduced them further, to 4115 bytes. Using a PDF vs using PNGs in this instance made the assets take up 5× the disk space.

PDF assets can be useful #

If you’re aware of their limitations and selectively use PDFs, they can be great for things like single color glyphs. It’s also possible to use a combination of PDFs and PNGs in the same project, so you can limit use to the places it makes sense.

For me, saving a PDF is more work than saving PNGs for 1×, 2× and 3×. There is no benefit at all, only potential rendering and quality issues, as well as larger files. I wouldn’t be willing to make those trade-offs, even if using PDFs was more convenient.

That’s why I don’t use PDFs for iOS assets.

Published 30 March 2015.