The main attraction of the iPad game that I made for Kai last month are the wonderful high-quality animal photos from the Wikimedia Commons. This is the kind of content that justifies a "retina" display. But the high resolution comes at a price: big files.

While my self-imposed restrictions that I only want "featured" pictures (later relaxed to "quality pictures", later even relaxed to "anything goes" if I really need an animal for that letter) hosted on Wikimedia with a resolution of at least 1536x2048 (later relaxed where necessary) with both landscape and portrait pictures available for a given animal (later relaxed to me cropping the original where necessary and possible), distributed (and that is the hardest hurdle) under a license that does not require share-alike, are the real reason that the initial version contains forty-five animals, and not more, the sheer size of the image files has also become a concern.

For the forty-five animal I have two photos each, in three different resolutions (fullscreen JPEG 1536x2048, square thumbnail PNG 144x144, square thumbnail retina PNG 288x288). That resulted in 98 MB of image files (out of a total 114MB download size for the app). "Disk" space on tablets is limited, so this is not good. I started investigating ways to reduce that. There is a nice open-source tool called ImageOptim that tries a number of ways to shrink image files without losing a single pixel. With that, my animal assets folder lost a good 10%, but the progressive JPEG encoding introduced a noticeable delay when the iPad displayed some of the photos. Without the progressive JPEG option, ImageOptim produced a 94MB output. There is a commercial tool called JPEGmini that claims "patent-pending technology" to figure out exactly how much lossy compression can be applied without the reduction in quality being detectable to the human eye. I certainly cannot tell the difference, neither in how the picture looks, nor how fast it loads on the device, and the JPEGmini-fied files are only 49 MB. Earmarked another 20 USD from my so-far elusive App Store earnings for this.

Another area of discomfort is that you have to download the big retina files even when your device does not have a retina screen. So you end up with a package that is three times the size it would be if the next-generation iPad (that you do not have) did not exist, and all the extra data is there only to support features you cannot access. This effect is even more pronounced with universal apps that you install on an iPhone (which does not need any of the large-screen graphics). It would be nice if there was a way to deploy a stripped-down version of an application with only the assets that the target device actually needs.

Having to waste storage capacity on resources your device does not need goes the other way around, too, by the way: The way retina support is implemented is by having every image twice, once in normal, once in double resolution, so that on the "new" iPad you also have files you don't need (but at least they are much smaller than the ones you do need). One would think that you could get away with having just the high-res images and downsampling them on-the-fly for display, but this is apparently a bit tough for the first-generation iPad, whose hardware can just barely keep up with driving the screen as it is. In the case of "A wie Affe", I did prepare all of the thumbnails and icons in both resolutions, but the fullscreen pictures are all 1536x2048 only. This is not completely wasted on non-retina displays, though, as the extra detail makes for more powerful pinch-to-zoom.