[huhtenberg]

Can't you do some sort of custom image compression? Bundle app with the highest resolution images, then scale them down, arithmetically subtract from the respective image and pack and ship the difference. Just gzip or paq it, and see what the savings are like. If it works (and my gut feeling is that it would), then reconstruct lo-res images on the fly when they are needed.

[ajslater]

Automatic scaling doesn't work very well. You can find numerous design blogs showing you in great detail why it looks slightly shoddy if you scale from 512x512 down to 128x128 or 64x64, and how below 64x64 you just get into illegibility. For your app to look great you need hand tweaked assets for most resolutions. http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes http://bjango.com/articles/designingforretina2/

[huhtenberg]

No, you don't understand. Of course, automatic scaling doesn't work.

Prepare two images - 512x512 and 32x32. Scale first one down to 32x32, subtract it from the second one and this will yield a arithmetic, per-pixel difference. Compress it. Now store 512x512 image and the compressed diff with an app. With these two, you will then be able to recreate original 32x32 (by scaling down 512x512 and applying the diff). And I am making an (educated) guess here that the compressed diff will take less space than the actual 32x32 image.

[pornel]

iOS already supports PNG8+a, which is much smaller than regular PNGs and a"CgBi" PNG variant that Xcode uses.

[huhtenberg]

PNG8 is 256 colors, that's pretty limiting in very many cases. CgBI - I just looked it up - appears to be a speed optimization rather than a space one.

[ricardobeat]

At least in web apps, a good part (I'd say 60-80%) of image assets can be converted almost lossly to 8-bits, including gradients/shadows (you can have alpha transparency).