Xcode - PDF Vector x PNG

I think you are missing one important piece of information. In current Xcode versions (8 and 9, I think, probably not 7), you have the option when adding PDF-format images to an asset catalog of retain the vector structure, and letting it be rendered at run time into the correct resolution for the context. The blog you linked to didn't know that (or was written for an earlier version of Xcode).

Here's the rule I suggest you follow:

— If you know in advance the point size of the image you will display (e.g. a button or toolbar icon), then put it in the asset catalog as 2x and 3x PNG images (and 1x if you need).

— If you know the image will be displayed at sizes that are calculated at run time, put the image in the asset catalog as a PDF.

— If you know in advance the image will be display in one of a fixed set of sizes, it's pretty much a wash which of the two ways you do it. PNG is probably smaller, but you'll need to supply one set for each size.

Note that you can alternatively store the PDF files as resouces (not in an asset catalog) in your bundle, and render them using the built-in PDF APIs. This can be convenient when you have lots of related images, because it's often a convenient workflow to put one image per PDF page. You would then render each page "manually" to the desired size.

But using PDFs in asset catalogs should be well supported now, and there's no reason AFAIK to avoid them.

Thank you very much for your reply.

My question is more related to a preferred way of one versus another when using small assets such as small images and toolbar icons.

Is there any reason I should use PNG (1x, 2x, 3x) instead of a one single PDF vector that could handle all those sizes? You mentioned PNG are smaller, would there be the advantage of using PNG vs PDF or that would be merely a matter of preference?

>My question is more related to a preferred way of one versus another when using small assets such as small images and toolbar icons.

In that example, I'd audit your workflow for each, being sure to adopt batching, WOUA, etc. where applicable, then decide which is your friend simply in terms of time, effort, data warehousing, etc., so yes, matter of preference.

If the question, however, is how one vs. the other may affect app behavior post-distribution, I don't think there is any impact either way when the asset is small icon, toolbar image, etc.

My preference has always been pngs, BTW, for no other reason than habit from a workflow I've come to trust over the years. And I know asset catalogs have been around a while now, but I still avoid them unless necessary 😉 - been bit too many times in the past.

PDF is possibly more forward looking. If there's ever an enhancement that affects resolution, a PDF will give better results. (Imagine a 4x image resolution being introduced — though we have no reason to believe this is going to happen.)

The advantage of PNG is that you get to hand-tune the images at the pixel level, which can be helpful especially when the image is small. OTOH, if you simply generate these small images from vector artwork without pixel tweaking, then it doesn't matter much.

There might also be something to think about in terms of the new HEIF format, but I don't yet know how that would fit into the workflow.

If you don't check "Preserve Vector Data" in the assets catalog, XCode will generate 3 PNG files from the PNG. So, not much difference in terms of build size.

I would prefer PNG, because, otherwise, creation of PNGs will take time on the designer's side. Automatic job is cheaper then human job.

Also, it's easier to track changes in vector. It could even be staged by Git. Easier to maintain, when it comes to updating images.

*3 PNG files from the PDF
*I would prefer PDF, gosh!