When Kuo's report of the iPhone 6 screen resolution came out, my first thought was that it had to be wrong, because it didn't seem to make sense based on the current theories. 1334x750 (4.7" at 326ppi) wouldn't scale current apps graphics cleanly (via an integer multiple for pixel count) like the retina transition did, nor is it enough of an increase to justify all app developers having to redo their graphics for a completely different resolution.

So far, the prevailing theories are the resolution will be another integer multiple, @3x or @4x graphics, or to use something like 1080p and developers will just have to deal with it. (for the pros and cons of these approaches, see this article on iMore)

Kuo's numbers don't fit either of these, but after thinking about it, I think he's got it right. Here's a few reasons why.

- Apple has been not too subtly pushing developers to use auto-layout when designing their apps. Properly used, auto-layout can adapt an app's layout to various screen dimensions based on rules and priorities set by the developer. By only changing one dimension with the 4" screen, Apple seemed to force a half step on developers to use this system full time.

- Also shown in the 4" screen transition, Apple is fine letter-boxing non-optimized apps so long as they're still functional. It's not a great solution, but it works until the developer can update.

- Even though it's technically a marketing term, Apple has stated their "rules" for what kind of display they consider retina. For the iPhone being held 10-12" away, 300ppi and higher is "retina". Sticking to 326ppi on a bigger display, which would ideally be able to be held even further away, and thus require a lower pixel density, would also then meet the "retina requirements".

So, how Apple gets to 4.7" is simple: add pixels to each side of the display, and keep the pixel density the same. Non-updated apps get letter-boxed on all 4 sides (instead of 2 like the 4" screen), and developers are further pushed to use auto-layout to target all 3 display sizes. One of the big differences here compared to other theories is that, rather than everything just getting bigger, UI elements stay the same size, there's just more room for additional content.

If this all sounds familiar, it should. We've been here before. After all the speculation for the iPhone 5 display, the answer was just to add more pixels to the top and bottom. Wash, rinse, repeat on all four sides.

I also made a couple mockups to describe how the settings and maps apps would work both unoptimized and optimized, just for a visual reference.

via i.imgur.com

The biggest reason I can see against this theory is that Apple would look bad releasing a 326ppi screen in a world where their competitors have screens in the 400+ppi range. However, the Moto X, who's screen is 4.7" at 312ppi, has been well reviewed, and most reviews say the lower resolution isn't really noticeable without a 1080p screen right next to it. Plus, Apple can poke fun at their competitors, saying they're wasting battery life trying to power screens with pixels people can't see anyway. (You can certainly argue against that claim, but I can definitely see them saying that)

This seems like the easiest path forward for Apple. The burden on developers is minor (and is similar to the 4" transition), no apps are at risk of being broken (just slightly annoying to use, thus incentivizing devs to update), and screen costs and complexities can remain low so that either new technologies can be fielded at lower risk (thinner panels, new screen tech, etc.) or just to keep margins high. Plus, devs are further pushed to use auto-layout, giving Apple further flexibility in the future. (Perhaps for that 5.5" iPhablet...) Finally, additional power consumption is kept to a minimum since there's only marginally more pixels to push and light up, so the presumably bigger battery can give a sizable boost to battery life.

I know as a tech nerd part of me would be let down with such a "low" density screen, but as both an electrical engineer and a developer, this seems like a good solution that works without compromising real world use of the device. What are your thoughts, or is there something big I've missed?