iPhone devsugar: Working with tablet resolutions

Rumors are hitting the ground hard and strong about exactly what to expect in the upcoming (yeah, yeah, possibly mythical) Apple tablet device. And the most important of those rumors, the fact most consistently cited, is the introduction of extra pixels. You might roll your eyes and say, "of course a tablet means more pixels," but what exactly does that extra resolution mean to you as a developer? After all, we don't know what the pixel count will be or whether the (possibly mythical) tablet will offer widget-mode applications using the current iPhone resolution size or full-screen options. So let's look at some of the challenges having extra screen space might offer up developers.

For example, the (possibly mythical) tablet might run what essentially amounts to iPhone Rosetta -- little virtual iPhone apps running in their own little simulator windows, 20-pixel-high status bar and all (we aren't sure the tablet will run on ARM or not). And those 20 pixels matter. Many iPhone devs have designed their apps for 320-by-460 or 480-by-300 screen geometries, the geometries that have been native to the iPhone and iPod touch throughout the first three generations of devices. (Strictly speaking, the iPhone is in its 2nd generation with the 3GS and the iPod touch is in its 3rd with the latest model unit.)

Take away the status bar, however, and you're dealing with just the first break in the geometry story. Apple doesn't offer specific UIKit-based calls for querying standard items like 44-pixel navigation bar presentations. When moving between an iPhone and a tablet, that's the kind of information that an application should be able to find out for itself.

With an expected (and currently hypothetical) 960-by-1440 minimum resolution, tablet software doesn't just have to change aspect ratios but also deal with magnification. Art that looks terrific at 320x480 may not look so hot at 960x1440. Although Apple has always encouraged developers to design for resolution independence, the fact remains that most iPhone artists have delivered photoshop-quality art at device-level resolution. In my experience, sadly little development has centered on vector-graphic-based art. Consider the image at the top of this post, showing a screen shot from my App Store Draw application at the original resolution (top-left insert) and zoomed in to 960x1440. Simply scaling up art is not an Apple-worthy option. (Do note, however, that vector art can have anti-aliasing issues of its own.)

Apple's current SDK offers little in the way of resolution control or querying. You can ask a shared UIScreen object to report its dimensions and provide an "application frame" to fit your application into, but little more. The calls just aren't there yet -- although hopefully a 4.0 SDK would provide hooks to allow exactly that.

In response to this kind of uncertainty, iPhone developer (and talented High School student) Jacob Bandes-Storch has been developing the open source ResKit project at github. ResKit offers "a library for testing resolution-independent iPhone OS applications". You can establish it to run with a simulated screen size of 800x600 for example, to see how your application works at that given size. The screen shot to the right shows ResKit in action, displaying its virtual screen.

And while pixels are important, they won't provide the only developer challenge for migrating iPhone OS applications. Because when the touch screen dimensions change, so does the way a user's hand can interact with that screen. A larger screen means more hand lifting and movement. Imagine a standard landscape game running in a standard 480-by-300 window floating in the middle of a 7- or 10-inch tablet.

Now imagine trying to thumb-control any touch-based buttons at the bottom-left and -right of that floating window. Not going to happen, at least with a window in the middle of the screen for normal-sized hands. It's time to start designing for a one-hand-to-hold-and-one-hand-to-manipulate reality. Because any applications that are not full-screen will have to deal with a floating ocean of space when presenting their GUIs.

And even if you scale up, and move your game into a full-screen total resolution mode, consider the simple physical weight of a tablet device. If your users are going to hold it in such a way that their thumbs can manipulate buttons at the bottom of the screen, think about what the simple weight of the device will do to their interactivity. To get a sense of this, pick up any standard DVD movie case. Hold it in landscape position and manipulate it as if you were manipulating a thumb-based tablet game. The tipping backwards you'll experience from just a lightweight plastic case gives only a hint of what a more solid device will do when grasped in a similar fashion.

There's the accelerometer to consider as well. Because accelerometer readings simply may not make sense for any application that is not centered on the screen. Think about it: what does tipping a device to the left mean to an off-centered floating widget application, let alone one that doesn't have the current focus (assuming a multi-application environment as the tablet would likely support).

These are just a few big issues: resolution, geometry, widget-based windows, touch/grasp limitations, device manipulation differences, and physical device limitations Between these, a lot of App Store offerings may need to re-think, re-design, and re-engineer their offerings.

A January SDK refresh would go a long way towards allowing developers a head start for addressing these issues. If Apple follows previous years, however, the SDK launch may lag months behind the product announcement. So developers are warned to really think through each of the issues I've mentioned and start planning now how they can keep their applications current and device-appropriate.

Expect Apple as well to repeat the 3.0 migration experience. Remember how apps were tested for 3.0? I wouldn't be surprised to see "Tested for Tablet" certifications to start appearing in App Store, especially if there is a processor shift away from ARM. Certifying apps would give a better idea to consumers as to which items will run smoothly on their new systems. As, iPhone developer John Fricker points out, " I think we can safely assume that Feb will be known as 'Refactor Hell Month' if the tablet runs iPhone OS."

Thanks Landon Fuller, Scott Lawrence, Avi, John Fricker, tehbaut

(p.s. As a side note, a front-mounted camera might make the cameraViewTransform property of the UIImagePickerController class finally make sense.)