The other day I talked about the retina display bloat and using vectors to vastly decrease the distribution size of your iOS apps. The drawback however was that it only work for image that can be vectorized. So what about the rest of your images like photos or the default screens?
Well, it turns out that the built-in Xcode PNG compression tool kinda lacks in the compression department. There’s a great case study about the Tweetbot app over on the ImageOptimum site:
Disabling Xcode conversion and simply using ImageOptim instead was enough to reduce the application size by almost 30% (33.4MB down to 23.8MB) and halve initial display time.
Manually optimizing images with ImageAlpha reduced entire application size by more than a half (33.4MB down to 16.3MB). Images alone were 65% smaller and were displayed 2.5 times quicker than Xcode-optimized ones.
Now that’s awesome. If a few clicks can save you megabytes why not?
It turns out that Xcode creates a CgBI PNG varient optimized for loading speed using 32-bit BGRA. Jeff LaMarche has a great technical explanation of what’s going on, explaining that Xcode basically optimizes for loading speed by swapping bytes in the image and “corrupting” the PNG format.
During the build, Xcode basically screws up your PNG image, turning it into something that’s technically no longer a PNG image. Xcode doesn’t change your original file, but when it copies it to the Resources folder of your application bundle, what it does is it byte-swaps the red and blue octets and also “premultiplies the alpha” … The PNG specification does not support either of these changes
The other downside is that sometimes this manipulation results in a larger file size than you would have with a normally optimized PNG.
To disable Xcode’s built in image compression, go to your target’s build settings, filter for “Compress PNG Files” and select NO.
However, be cautious if you choose to disable Xcode’s built-in PNG optimization and do the optimization yourself with a tool like ImageOptimum. Disabling Xcode’s optimization will mean your iDevice will do the equivalent optimization on-the-fly at run-time, adding additional processing and memory overhead. You should to take this into consideration and optimize your code to share and reuse image resources where possible.