Wishful Thinking

I’ve had a couple of rounds of Twitter debates with iOS designers over this 4-inch iPhone rumour, specifically the taller-but-not-wider variant, with me on the pro and them on the con. While I’m not putting my money on a 4-inch screen this year (more on that later), I see a pattern of wishful thinking about it on the “no way Apple will do this” side.

Anatomy of the Con argument

The con argument goes something like this:

@marcedwards: It may happen, but the rumoured taller iPhone sounds like a lot of pain for very little benefit.

@marcedwards: Breaking all apps would be a PR disaster for Apple. Plus they’d have to rework every single aspect of the OS. Doubt it’ll happen.

@mrgan: I reject the idea that “showing more content” is a powerful idea. Again, why not a 15” iPhone then? 3.5 is good.

@marcedwards: Is that how they’d do it, if they had to start from scratch? If the answer is no, it’s the wrong choice.

In other words, they say it won’t happen because (a) it’s a lot of work for developers & designers, and (b) if 4-inches is right now, why hasn’t it always been 4-inches?

Apple’s priorities

A gentle refresher on Apple’s priorities, from highest to lowest:

1. What’s good for Apple.
2. What’s good for Apple’s users (whether or not we know it yet).
3. What’s good for developers.

I see many iOS and Mac developers bemoaning and begrudging Apple for shoveling more shit on them. But every time, they crawl out of the shit and get on with the job. Not because Apple is a cult, but because ultimately it’s good for business.

When the iPad was first announced, there was a huge amount of work to be done to redesign and rebuild apps for the new form factor, screen size, pixel density, and aspect ratio. But everyone clamoured to get their apps onto the iPad because there was money to be made. And it was made. Lots and lots of it.

Similarly, when the iPhone got the first Retina Display in 2010, another huge pile of work landed on the doorstep to produce @2x artwork. And it got done. Same again for the 3rd-gen iPad.

Developers have repeatedly shown Apple, through their actions, that they will quickly rise to the challenge of new screen resolutions. Or, more cynically, Apple has shown that it can coerce developers into doing so. Either way, it gets done.

So, how hard it is for developers does not factor in Apple’s decision here. Rather, decisions are based on the resulting product; and then Apple works on making the transition as smooth as possible within that constraint. “Do I want this to happen?” is a different question to “Will it happen?”

As for why the original iPhone didn’t have a 4-inch 16:9 display in the first place, my guess is that it simply wasn’t possible, technically and/or economically, to build an iPhone any other way in 2007. Maybe 16:9 was Apple’s first choice, and now in 2012, with the technical constraints removed, they can finally implement that choice.

Springs and Struts, and Black and White Bars

Cocoa Touch has some clever screen layout mechanics, inherited from Mac OS X, to place and resize UI elements relative to the edges of the display. This is important for apps that support rotation, since the effective aspect ratio can change underneath you at any time.

In particular, the standard controls that you see on almost every app (tab bars, title bars, etc.) are usually not placed on the screen by the developer at all — it’s all controlled by iOS automagically.

I don’t have numbers on how many apps rely on these layout controls, but I’m sure it’s an overwhelming majority. Even apps that appear to have custom UI controls are mostly just skinning the standard controls to get the look they want.

Because of this, if Apple increased the vertical resolution only, all of those apps would essentially update to the new screen size automatically. No changes required by the developer.

(Pictured: Cities by Bjango)

For other apps, especially games with pixel-for-pixel artwork, automatic layout controls won’t work. But in the transition period, I think it would be absolutely fine to have black padding above and below the screen, effectively displaying the app exactly as it was displayed on iPhone 4/4S.

With Apple’s amazing technique of bonding the display to the front glass, the black bars might just blend with the rest of the phone, enhancing the illusion that the app is running just as it did before. Again, I imagine this would happen automatically, with no effort required on the developer’s part.

As a bonus, the black bars could be white bars on the white iPhone, so that the illusion works there as well!

(Pictured: Kapowie by Bjango)

The Real Con Argument

To me, the far more interesting puzzle is, how would Apple announce this?

Since there would be development and design work to be done, Apple needs to release those SDK updates well ahead of device launch, ideally at WWDC. But that makes the phone 3 months old on launch day. Apple wants to announce, and then sell within 14 days.

But if Apple announces the screen size change within days of putting them into customers’ hands, there would be no time for any developers to test and update their apps before the launch.

Unless! If the Cocoa libraries are really doing their job well, and Apple has already tested and confirmed that 50%+ apps will auto-optimise without changes, then I suppose a launch day announcement could work. Thinking historically again, this is what happened with the iPhone 4; apps that had minimal or no graphical artwork elements were Retina-optimised already, with no update required.

I remain unconvinced in either direction, and now it seems even John Gruber is throwing cold water on his implicit confirmation of the rumour.

So, we’ll see. Maybe it’s wishful thinking on both sides.