The Rumored iPhone 6 w/ 4.7″ Display and the Case for 1704×960 – Compatible with Present and Future

(WARNING: Far more conjectural and far less educated than Daring Fireball’s post on the subject. Doesn’t cover the rumored 5.5″ iPhone Phablet. And in case you’re new to the blog, I’m just a humble home gamer on the subjects of tech, stocks and Apple, so be advised.)


Quick “background”: The resolution we see vs. the resolution developers see

I’d been thinking about potential resolutions on the iPhone 6 now and then (it’s no big secret that I own an iPhone 5S and will likely upgrade to either an iPhone 6 or its year-after successor), and read John Gruber’s extensive musings on the matter, linked above.

If I read things correctly, one of the major “points” is that as a default, Apple has one iOS framework which, at risk of oversimplifying, lays out a programming matrix of sorts with which developers can design apps (add and place images, buttons, etc.)

In other words, at even higher risk of getting things hilariously wrong, using the 4.0″ inch, 1136×640-pixeled iPhone 5/5S display as an example, the “developer resolution” of an app (independent of font size, anyway) could be said to be, or at least be more like, “568×320”. That’s because the Retina Display has twice the pixels per inch of the 480×320 display that saw duty in the original iPhone, the 3G and the 3GS.

Yes, in the actual developer world, the proper term is “effective resolution”, but I think you’ll understand why I think the term “developer resolution” better communicates the concept to those of us non-developers by the end of this post. For instance, think of the non-Retina 13″ MacBook Pro. It sports a 1280×800 LCD display. The Retina version sports a superior 2560×1600 display, but put side by side in their default display settings, the user-facing difference between the two is that the Retina version is dramatically sharper. Icons and text look the same size because they are, just rendered in a profoundly better manner on the Retina MacBook with its 4x pixel density advantage. So, in the case of the Retina MacBook Pro at default settings, icons and buttons are being rendered at 1280×800 at “2x mode”, because the Retina Display is working with the same 1280×800 matrix, even though the actual image quality result is worlds apart from 1280×800.


Three candidate pixel densities for the non-phablet iPhone 6

Back in May, Mark Gurman from 9to5Mac originally reported that the rumored iPhone 6 with 4.7″ display (which, these days, seems decently likely) could sport a resolution of 1704×960 (roughly 416 ppi) on account of a “3x” Retina scaling mode.

This month, Gurman reported on a (theoretically embargoed?) configuration file within a recent Xcode 6 beta (which given Gurman, I presume has been verified) mentioning a “414×736” resolution. The logical inference? That there may be a display out there, which, in actual pixel terms, has a resolution of 1472×828 (roughly 360 ppi).

Gruber’s guess is that the iPhone 6 with 4.7″ display (which, if for real as seems to be the case, would likely be the volume seller if accompanied by another display size) will sport a “low”, though technically-still-better-than-720p HD, 1334×750 resolution, given the advantages for both Apple and developers in working with the current 326 ppi displays and the undeniable ability to increase the amount of content displayed without making any changes to such things as fonts and icons. Basically, it would be Apple’s second application of the concept behind the iPhone 5’s display.

Obviously if given the choice, I and pretty much everyone else intending to buy an iPhone 6 would prefer the highest-resolution option. Interestingly, both Gruber’s piece and Gurman’s more recent report indirectly provide solid technical reasons why 1704×960 would be a great, sensible choice for Apple and developers as well, even though it’s the harder road to take.


The case for 1704×960: An intriguing combination of “backwards compatibility” and forward-thinking developer sandbox, provided the attendant hardware and software and power consumption challenges can be (have been) overcome

Gruber wasn’t a fan of 1704×960 under “3x” Retina Display scaling for the rumored 4.7″ iPhone 6, because the practical effect is to simply scale up icons and objects about 18% (actually around 17.5% if you want to get all technical). Sharper, bigger, but no gains in the amount of content that be displayed in that scenario, not without additional work.

But what if that was just a transitional approach?

One to relatively quickly adjust an app or even elements of iOS 8 for the 1704×960 display? While the “transitional” approach, by definition, doesn’t check all of the boxes (it’s a big zero in the “more space for content” category), it does “automatically” address two common problems amongst those of us who get older over time 😛 – (1) readability (larger default text/graphics) and (2) ease of navigation (larger default interface elements), all with a 2.25x higher pixel density than the iPhone 5S (which further enhances readability). Hey, it beats pixel-doubling, hands down.

The more forward-thinking developers, as well as Apple, would see a much greater and lasting benefit from “sticking with 2x”, however. It would require considerably more software engineering effort on the part of all involved, but it could also mark a paradigm shift in software design and development. Because “retaining” a 2x, 4-pixel-block development model increases developer resolution from 568×320 to 852×480.

Now it’s very true that this approach is an “imperfect” solution and would require considerable rethinking to optimize. Having the ability to, at least once, cram four pixels into the space of one makes life much easier on developers and software engineers, in that they can focus more on fine details than layout. On the other hand, increasing the “creative canvas” in direct proportion to the increase in pixel density could open up many new layout and design approaches in both iOS 8(+) and optimized apps. Recall, for instance, the original Macintosh with its pixel dimensions of 512×342, then imagine how developers adjusted (I daresay, exulted) as screens with resolutions of 800×600, then 1024×768, arrived on the scene.

The beauty of 1704×960 is that it cleanly enables a 2-mode approach, and even a scaling-of-1136×640-apps mode that doesn’t look utterly hideous. “568×320” apps at 3x will look even better than before. “852×480″ apps at 2x will usher in a new level of refinement, along with the ability to leverage the 38% increase in geometric area vs. the current 4” Retina Display. Of course, whether a considerably-higher-resolution screen with a higher-developer-resolution mode will overtax Apple’s historically “lower-than-average-capacity” batteries is an open question.


Why not the lower-resolution choices?

Gruber’s guess of a 1334×750 resolution is “very Apple” in two ways, scoring points in efficiency (same 326 ppi, least impact on consumption) and purpose (by default, enabling the display of more content). However, it’s the least future-proof option, which would look increasingly dated as smartphones in its class and price range increasingly trend towards 1920×1080 displays. The shorter the “half-life” of the display, the sooner another round of developer (and iOS, and end-user) adjustment begins as they move on from “667×375”. It’s also a sub-optimal choice for future pixel density improvements (assuming the same 16:9 aspect ratio), because

  • 3x scaling results in the awkward 2001×1025 resolution (that, in reference to footnote 2 of Gruber’s article, results in two pixel dimensions with odd numbers),
  • and 4x scaling results in the mind-bendingly-dense, resource-destructive, and conceptually-pointless-for-the-screen-size-seeming 2668×1500 resolution at an insane 650+ ppi.

To me, using a 326 ppi panel looks more like amortization than the innovation Apple is capable of, especially when the Android competition can handle sharper panels with good battery life. 1334×750 is also a tremendous waste of the A7+ SoC series’ raw power. The A7 is already capable of driving 2048×1536 displays, and leaving the volume-selling iPhone to a comparatively low resolution makes less and less sense the more that Apple improves A-chip SoC CPU and graphics performance (as I presume they will continue to do for the foreseeable future).

The potential 1472×828 resolution reported by Gurman takes a bigger step towards pixel density and developer resolution than does 1334×750. It also has the bonus of having a less awkward, less imposing “3x” resolution boost option (a razor-sharp, yet somewhat rational and already-possible 2208×1242 539 ppi display). However (Gruber pointed this out), as a “2x” resolution with pixels at around 91% scale (326 ppi divided by about 360), the default state is to render icons and text smaller on a larger display, which “automatically” impairs readability and ease of navigation. Not a win for consumers. And really, “1472×828” isn’t that great of a “marketing resolution” given that every iPhone to date has had a pixel width that’s fairly easy to remember (320, 640). Overall, as with the 1334×750 resolution, it just seems a bit too “incremental”.

1704×960, on the other hand, seems to strike the best balance between today and tomorrow. More than double the pixels. A natural extension of the current 568×320 matrix, which is a plus for Apple, yet “competitive enough” vs. other smartphones’ 1080p displays.¹ A 852×480 developer resolution would encourage Apple and third-party developers to remap, rethink, and redesign on iPhone, somewhat like the new Swift programming language does. Provided power consumption can be optimized, there’s now ample SoC horsepower to operate within an 852×480 points system, since the A7 already handles 1024×768 developer resolution at 2x on iPads. It also leaves two additional pixel density upgrade paths should Apple ever need them in the future – 2272×1280 (568×320 multiplied by 4, or 1136×640 at 2x) and, if absolutely necessary, 2556×1440 (852×480 multiplied by 3, essentially 1440p resolution).


No pain, no gain; “hoping against hope”?

480×320 and then 568×320 have taken iPhone a long way, but maybe now is the time for Apple and developers to take the next step – even a giant leap – forward in pocketable app development. Increasing developer resolution by a factor of 2.25x (whenever they’re ready to take on the challenge) just makes more possible – and backed by Swift, Metal and other software technologies, it’s hard to see why excitement wouldn’t prevail over reluctance.

Developer guidelines would have to change under a 852×480 at 2x system, but “certain immutable truths” aren’t terribly hard to address with more pixels at your disposal. 44×44 point control targets now too small at 416ppi? Well, 56×56 (112×112 pixels) will basically fit the bill. Now, 14/11 scale is awkward, but it’s a change that only needs to be done once, and to the extent Apple or developers use vector graphics, there shouldn’t be anything more than a scaling change applied. It’s also something that would only apply to touch targets vs. content display.

Having two paths to “fully compatible” apps is also classically Apple – see PowerPC optimized and FAT way back when, then Cocoa and Carbon for OS X, then Universal Binaries and Intel-only in the x86 Mac transition. Except this time, a change in mindset plus some healthy competition might really accelerate the development curve. When given the choice between cramming 9 pixels into the space of 4 or working with smaller but 225% more developer pixels, which would the most motivated developer use? Also, it’s not like indie creators of lovingly “low-res” apps would be left in the dust – I can name plenty of notable examples running just fine on 1136×640 today, such as Devil Shard (Game Stew Studios), A Dark Room (Amir Rajan), and some developer that just released some app called Swing Copters.

The only problem? 1334×750 (Gruber’s guess) is compellingly practical. 1472×828 may have already been hinted at in Xcode. 1704×960 is comparatively hard, and presents the biggest hardware/software/power consumption challenge.

My hope – Apple and third-party developers are now up to that challenge.


1 It’s more than just pixel count, anyway, and Apple has always been a solid performer in brightness, contrast, color accuracy, and so on.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s