Considering the iPad mini as a developer

Considering the iPad mini as a developer:
I give up. An "iPad mini" seems to be a good possibility despite my protestations. Many Apple watchers expect to see a small iPad being announced sometime Fall-ish. Although I'm somewhat convinced that I've wandered into a figment of John Martellaro's imagination, it's worth thinking through the possibilities.

Resolution and Aspect

When considering the possibility of a longer, thinner iPhone 5 (the "new" iPhone) and an iPad mini, a developer's mind wanders towards resolution and aspect issues.
Between iPhones and iPads and Retina displays, I'm regularly creating multiple megabytes of basic art in order to serve all possible platforms. Isn't it time for Apple to start re-imagining art support so we can slim down some of these bundles?
Enumerating each device and Retina support gets old. I currently create four icons (iPhone, iPhone Retina, iPad, iPad Retina) and 6 launch screens for my apps as iPads use separate portrait and landscape launch art, all customizable through Xcode.
Like many others, I gave the Eagle-Giraffe hack a try -- it lets you adjust the simulator's resolution to arbitrary values -- and immediately started wondering what kind of new iOS artwork I'd have to supply.
If the two new devices launch as anticipated, that's at least two new launch screen resolutions to take into account: Default~Phone5@2x (if the aspect ratio is to be respected, with a Retina display) and Default ~iPadMini (possibly with Retina, adding an @2x to the name, and possibly requiring orientation-specific art) or whatever. Trying to guess the new names, etc, isn't always obvious.
Then there's the issue with application layout. I feel fairly confident that developers, who have been through this once before at the iPad launch, can adapt their apps to new aspect ratios, but there's a big cost of human labor and QA to doing so. Interfaces that live naturally in a 4:6 (640 by 960, or 320 by 480) aspect screen might struggle in a 9:16 without some major re-thinking, or at least some careful work in Interface Builder (The iPad uses a 4:3 aspect).

Basic Design Challenges

There's also basic design challenges. Designing for tablets is not, as we have long since discovered, the same as designing for mobile phones. iOS uses different paradigms for presenting information. Tablets need fewer space-folding tools like navigation controllers and tab bars than their smaller brothers. Their extra pixels offers greater nuance for creating view paradigms, and the overall interaction space welcomes multiple hands -- including from more than one user at a time.
Moving from the current iPad to a smaller version means these accommodations might need re-addressing. Will a smaller tablet belong more naturally to the iPhone family or to the proper iPad family? How much space does it take to support popovers (not much -- I'd love to see them properly on the iPhone) or split view controllers (perhaps more than 7 inches might offer)?
I've tried imagining where UIKit might need to go for a "between sizes" device, and how the Human Interface Guidelines might need to adapt. Having spent time in the Android 7" world (I have a Kindle Fire -- great device for when I need to keep my iPad safe), I've worked with the form factor as a user, although not as a developer.
Many apps make the transition well -- especially those that already thrive on smaller devices. Halfbrick's Fruit Ninja games are far more fun to use on 7" than on a standard iPhone. Reading, typing, and surfing are also improved. These are hardly surprising -- a bigger screen better matches their requirements.
The drawbacks come in more expansive apps that push back the other direction. Apps that try to introduce multiple interaction zones (the "tablet" experience) don't seem to have enough room on a 7" screen. Vendors like Dropbox seem to have realized this and styled their Android apps more on the iPhone experience than the superior iPad experience.

Expectations and Best Guesses

For all these reasons, I'm tending to think of the iPad mini as requiring an enhanced iPhone app design paradigm than a degraded tablet one -- and, yeah, I know that's basically heresy. I believe that iPad-specific development (like split view controllers and popovers) will be supported but that most developers will use these to enhance more-iPhone-like development.
In other words, I'm not expecting all too many two-user-hand games specific to the platform the way the iPad currently supports that modality. At the same time I can see developers taking a breather and growing their existing iPhone screens with all their navigation controllers, table views, and so forth, to the new larger screen.
I'm not sure an iPad mini would need a separate full-screen and part-screen modal presentation, to give an example of an iPad-specific adaptation, but it would be a weaker platform without popovers.
In the end, I guess I'm saying that the in-between-device would hybridize both development approaches, even if I see it skewing towards the smaller family.

Considering the iPad mini as a developer originally appeared on TUAW - The Unofficial Apple Weblog on Fri, 17 Aug 2012 16:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

DIGITAL JUICE