Retina display Macs, iPads, and HiDPI: Doing the Math

The landscape is getting a little messy for app developers. Not saying this is bad. It's just a fact.

Today you have to deliver .png, @2X.png and *~ipad.png image sets with your app. And, there is no off-the-shelf way to reuse @2X images with the iPad when in most cases they'll work just fine. You can, but it requires creative coding.

Still, this results in app packages that are bloated with image assets in triplicate and now soon to add a fourth version.

If you build a universal app it seems that even someone downloading your app onto an iPod Touch is going to end-up with @2X, ~ipad and ~ipad2X (or whatever) images that the app will never use.

Maybe this is the beginning of the end of the universal app?

Not exactly. This theoretically only pertains to bitmap UI elements (mostly icons). Sadly bitmaps are everywhere, notably because they're so cheap to create and render compared to vector, and more computation implies more energy. I suppose one could generate a cache of rasterized vector UI elements to cut on subsequent rendering.

Apple tried to bring resolution independence to Mac OS X since quite some time, and in all honesty it worked well... for vector stuff. It broke in varying ways across iterations of it every time there was a bitmap involved, in which case they were at best either blurry or unscaled. There's no miracle, unless you generate bitmaps for numerous multiple sizes (like in icns files, where they range from 16x16 to 512x512, downsampled if scaling is needed, like on the Dock), initially small bitmaps will just look bad unless you use a 2x factor, in which case you will at best have no improvement (but no loss either) over a non 2x screen, or you have an uncanny effect when a 'fat pixel' bitmap stands near a 'thin pixel' vector curve. Anyway as noted by robomartin, things are sufficiently bloated already not to include full-scale 16->512 bitmaps.

What's more 2x is computationally way simpler and much less costly for everyone. The only non-hackish, seriously viable alternative is to go all the way vectorized. A typical case of 'less is more'/'worse is better' if you ask me.

[0] http://news.ycombinator.com/item?id=3658369

I was under the impression that not specifying a device modifier would allow the image to be used on both devices. From Apple's documentation:

Applications running in iOS 4 should now include two separate files for each image resource. One file provides a standard-resolution version of a given image, and the second provides a high-resolution version of the same image. The naming conventions for each pair of image files is as follows:

Standard: . High resolution: @2x. The and portions of each name specify the usual name and extension for the file. The portion is optional and contains either the string ~ipad or ~iphone. You include one of these modifiers when you want to specify different versions of an image for iPad and iPhone. The inclusion of the @2x modifier for the high-resolution image is new and lets the system know that the image is the high-resolution variant of the standard image.

That said, it would be cool if Apple produced four different variants of an app and would send you the proper one depending on the device you download it on. When downloading with iTunes, your machine would download and store all four versions.

Fortunately, i'd be willing to bet you could use some kind of Occlusion culling to compress that stream quite a bit.

Hi ebbv, I'm the author of the post.

I've had a quite a bit of feedback that I've moved the viewing distances too far out. I measured from my own experiences, but I guess I must be atypical. It might be because I use dual monitors on the desktop (I have a 27" and a 26", so I sit back to reduce head turning) and slump when I have a laptop in my lap.

Anyway, I've expanded the spreadsheet that goes with the post to include some extra settings for closer distances and for your specific distances and devices.

Hope this helps!

Here's the spreadsheet: https://docs.google.com/spreadsheet/pub?key=0Aq8W2-V7OXqfdGV...