Png's in iOS - png's in bundle vs downloaded - png8 vs png24

Question

I'm writing an iOS application and have some questions about using png's and performance which I couldn't find any answers for.

My app uses pngs from 2 sources, some are in the app bundle, and others are downloaded from the internet and stored locally. The ones in the app bundle I have my head around, I know xCode optimizes them for iOS when the app is compiled (Byte Swapping and Premultiplied Alpha). I have the following questions about png's downloaded from the internet.

1) Do you still get the performance benefits from using pngs in iOS if the images are downloaded vs in the bundle. Can the xCode optimizations be applied to downloaded images somehow?

2) Are there any advantages (or disadvantages) to using png8 vs png24, aside from file size? Do they take less memory when expanded from a local file? Does it take less effort to expand them? Is there any performance gain on animations? Or is the only gain from the smaller file size and better download time?

Thanks in advance for any answers.

Paul

Answer 1

1. The PNG optimization is done by Apple's own version of pngcrush (even though its author states

   [...] 2. Altered versions must be plainly marked as such and must not be misrepresented as being the original binary or source. (http://optimate.dl.sourceforge.net/project/pmt/pngcrush/1.7.70/pngcrush-1.7.70-HELP.txt)

   -- but Apple does not care about such details). pngcrush is called upon by XCode when compiling your source. After compilation, XCode has nothing to do anymore with later downloaded images. However, you can apply Apple's pngcrush to "optimize" the new images before uploading them. In my regard it's questionable whether or not this is worth the effort.

2. It depends, four times in a row. (If I'm counting correctly.) An 8-bit PNG is 3 times smaller than a 24-bit PNG. Working with single bytes instead of 3 or 4 (RGB, RGBA) should be faster; and naturally it uses less memory. It mainly (or possibly, only) depends on the content of your images. A photographic image compresses badly with PNG's algorithms and would suffer from color quantization when saved in 8-bit color indexed mode. A typical "computer" image -- say, a snapshot of a text editor -- with large areas in the same color may decompress very fast.

If you are going to use 8-bit PNGs, the "optimizations" that Apple's modified version applies are not used. Its main modification is to re-arrange RGB(A), presumably to align to the display of an iPhone/iPad. (Its secondary purpose seems to be to invalidate the image as a valid PNG.)

Answer 2

When you put them in the bundle, and turn on the "compress png" option in Xcode, Xcode reformats the pngs to make them faster to load (but usually larger than original, lots of thread on this behavior on SO!).

If you are really curious, look at the build folder for an app, and examine the modified pngs. The options you will see are the current optimal ones for iOS. In fact, I vaguely recall a thread on SO discussing what options you need to provide to some image conversion program (like ImageMagik) to mimic what iOS is doing (but I cannot find it right now).

EDIT: as Jongware (other answer) suggests, it would appear that Xcode is using a modified version of pngcrush. A link to someone evaluating these image options.