What to do with all those extra pixels?

Custom vs standard

For developers only using Apple’s user interface elements, most of the work has been done for you. For those with highly custom, image-based interfaces (like all of our apps), a fair amount of work will be required scaling up elements to take full advantage of the iPhone 4’s Retina display.

Scaling user interfaces for higher detail displays—or increasing size on the same display—isn’t a new problem. Interfaces that can scale are often called resolution independent. In a recent article, Neven Mrgan described resolution independence:

“RI [resolution independence] is really a goal, not a technique. It means having resources which will look great at different sizes.”

If it’s a goal, not a specific technique, then what techniques exist? How have Apple solved the problem in iOS?

Fluid layouts

While not strictly a resolution independent technique, using a fluid layout can help an app grow to take advantage of a larger window or screen by adding padding or changing the layout dynamically. A lot of Mac and Windows apps use this method.

This is partially how Apple handled the difference in resolution from iPhone to iPad—a lot of UI elements are the same pixel size, but padded to make use of the extra screen real estate. The status bar is a good example of this. It works because the iPhone 3GS and iPad’s pixel densities are similar (163ppi vs 132ppi).

Fluid layouts work when the change in density is minor, but aren’t any help with iOS’s non-Retina to Retina display transition, from 163ppi to 326ppi. The image below demonstrates what would happen if the Phone app was simply padded to cater for the iPhone 4’s higher resolution display. Buttons and tap areas would be the same size in pixels, but half the physical size due to the higher pixel density, making things hard to read and hard to tap.

Just-in-time resolution independence

Another approach to handling wildly different resolutions and different pixel densities is to draw everything using code or vector-based images (like PDFs) at runtime. Without trying to stereotype anyone, it’s usually the approach engineering-types like. It’s clean, simple and elegant. It lets you design or code once, and display at any resolution, even fractional scales.

Unfortunately, using vector-based images tends to be more resource hungry and lacks pixel level control. The increase in resources may not be an issue for a desktop OS, but it is a considerable problem for a mobile OS. The lack of pixel level control is a very real problem for smaller elements. Change an icon's size by one pixel you can lose all clarity.

“It’s simply not possible to create excellent, detailed icons which can be arbitrarily scaled to very small dimensions while preserving clarity. Small icons are caricatures: they exaggerate some features, drop others, and align shapes to a sharp grid. Even if all icons could be executed as vectors, the largest size would never scale down well.”

Although Neven’s talking exclusively about icons, his description is apt for most UI elements. The decisions involved in scaling are creative, not mechanical. That’s why vector-based elements aren’t suitable for all resolutions, if you value quality.

Ahead-of-time resolution independence

The best quality results—and the method Apple chose for the iPhone 3GS to iPhone 4 transition—comes from prerendered images, built for specific devices at specific resolutions. Bespoke designs for each required size, if you will. It’s more work, but ensures everything always looks as good as possible.

Apple chose to double the iPhone’s resolution exactly, making scaling even easier (quite different to Google and Microsoft’s messy approaches, proving yet again that controlling the entire stack has huge advantages).

There’s only three iOS current resolutions that need to be catered for:

• 320 × 480 (iPhone/iPod touch)
• 640 × 960 (iPhone 4 with Retina display)
• 768 × 1024 / 1024 × 768 (iPad)

It seems highly likely that in a few years the line-up will be:

• 640 × 960 (iPhone/iPod touch with Retina display)
• 1536 × 2048 / 2048 × 1536 (iPad with Retina display)
• Some kind of iOS desktop iMac-sized device with a Retina display

There’s significant differences between designing iPhone and iPad apps, so completely reworking app layouts seems necessary anyway—you can’t just scale up or pad your iPhone app and expect it to work well or look good on an iPad.

With such a limited range of models, it’s easy to build bespoke user interfaces for each resolution. Yet another reason why iPhone and iOS trump the alternatives?