The Curious Case of iPhone 6+ 1080p Display | Hacker News Reader

The Curious Case of iPhone 6+ 1080p Display

medium.com

191 pointsjameshuynh127 comments

Just... no. So very no.

Apple cheats because they failed to build a true density independent UI toolkit that actually works. Thus you end up with hacks like this where the UI is in a permanent state of filtered hell because the UI toolkit is just broken.

Android has proved this can work, and work fantastically. The article tries to spin it as being broken somehow, but clearly they never actually worked with Android much because this all works so, so well.

You don't need whole multipliers when you work in DIPs instead of PX.

iOS uses logical points, i.e. a DIP on Android.

As for iOS's @1x vs. @2x images, think of them as your drawable-*dpi resources on Android.

iOS apps use fixed layout, so they can't scale up/down with different display sizes. Since iOS only did double density once so far before iPhone 6 Plus, apps are quite easy to handle it. Android has way more variety, which is a pain for app developers.

This isn't correct. If you've ever resized an application window in OS X, it's likely that you've used autolayout. iOS has the same functionality. In addition to a flexible layout system, iOS has the concept of size classes which determine appropriate content to show based on display size.

But I can imagine that many iOS apps still use 'a fixed layout', as the parent comment stated (or perhaps at max use the old struts and springs mechanism). This may be quite a few and they could all break if Apple had not come up with the 'cheat', as the top comment called it.

I doubt that too many do, or at least many that are actively maintained.

The introduction of the taller iPhone 5 screen, and Apple's subsequent rejection of "letterboxed" apps (ones that don't make any use of the additional screen space) mean that most developers will almost certainly have switched to autolayout.

I still don't understand the "cheat". Any well-designed app that wants to take advantage of larger screen sizes on the new iPhones to display more content will use autolayout and the new size classes (compact and regular). There is no cheating involved.

For transition purposes, apps that haven't been updated yet will simply be scaled up (everything on screen will be slightly bigger). This is similar to when the iPhone 5 introduced a lengthened screen and apps were letterboxed until they submitted an update confirming that they were compatible with the larger screen.

iOS has always been able to do fluid layouts. It was possible with Springs and Struts (though a PITA), and from iOS 6 onwards has Auto Layout, which I personally find better (more declarative) than Android's box model.

I would also like to point out that there is a JailBrake tweak, FullForce, that lets you stretch most iPhone apps to iPad screen. Most iPhone apps can actually stretch and grow, and can actually do so pretty well. And, it worked even before auto layout. Apple, stupidly, did not allow legacy apps to auto stretch on iPhone 5 because (a) they wanted to force developers to update, and (b) they are paranoid about some things not working perfectly. A tweak like full force could have starched 90% of all iPhone 4 apps to iPhone 5 screen, but Apple would not allow it because of the 10% that would not work so well. But the software supports it, and to claim otherwise is silly.

I agree that it isn't as big a deal as some people are making out. But at the end of the day you can't disagree that it was a massive flaw from the beginning of the iPhone (and its days before it let people develop apps for it) driven likely by the megalomaniac supposition that if you build a phone you can't reach all parts with from your thumb: "no one's going to buy that."*

*http://goo.gl/pTwfws

Can't agree with this at all. Auto Layout can do some things that are very hard to do with Android layouts but for the common cases I find Android's layouts vastly more logical and maintainable than the typical Auto Layout mess. There are fewer things I dread more than opening up a complex xib file to dig into a complex Auto Layout scheme. Let the hunt & peck party begin!

I can open up an Android layout file and almost instantly understand how it works and what I have to do to change it.

It might be too late for your project, but I'd highly recommend using Masonry (https://github.com/Masonry/Masonry) for Autolayout. It's a DSL for specifying constraints that is far better than Apple's NSConstraint API and constraint language.

Since discovering it I've fallen in love with Autolayout and its abilities — where I used to dislike it before.

For me, it comes down to the fact that I find Auto Layout more declarative. I'm `saying what I mean` when I apply constraints - that can be done in code too, of course, although Xcode 6 is getting pretty good at surfacing that information. Whereas when I'm dealing with a box model I'm having to play compiler in my head. LinearLayout, RelativeLayout - these are terms that are optimised for the computer to understand. Constraints are the way we humans think about things. "Element A should always be 10 points to the left of Element B".

It's a bit like imperative vs. functional programming. In the former model, I have an idea in my head and I need to nest containers step by step to get to the final form. In the latter I'm simply building up a ruleset.

But like I said, that was my personal preference. I guess we'll have to differ on opinions ;)

Android UI system still uses pixel in many places, such as MotionEvent.getX(). It should just use DIPs everywhere, which would significantly cut coding complexity.

As the sibling comment states, iOS has used logical points from the very first retina device. And even before then it has never used integers for its UI toolkit coordinate system — there was always the support for fractional coordinates.

The point of the article is that the iPhone 6+ renders to a larger offscreen buffer and then downscales to a 1080p panel. This is the same as the higher resolution modes on Retina Macbook Pros.

I haven't developed on iOS in a while so I'm not sure what the state of layouts is at the moment. Why would they render to a higher resolution than scale down if the UI can work with the new native resolution? It doesn't make sense because the output will be worse and a hit to the battery life.

Actually no. The more pixels the screen has the more energy it requires to drive those pixels and so worse battery life. So by having a lower resolution screen and scaling down to fit that screen battery life is improved.

The alternative talked about here is not having the physical screen resolution of 2208x1242 but rather just rendering at 1080p without scaling down.

Displaying in the native resolution would lead to an even curiouser case where the iPhone 6's 4.7" screen displays more content than the iPhone 6+'s 5.5" screen (assuming integer scaling factors of 2x for the 6 and 3x for the 6+).

I do hope that there is some sort of programmable setting or API for enabling native resolution output so that games built with this option are rendering at 1080p and displaying at 1080p, or 1080p movies aren't needlessly being stretched and then downsampled. For legacy apps and not graphically intensive stuff it mostly makes sense to just display at 3x and scale down for simplicities sake, but if the option isn't otherwise there that seems pretty silly.

By rendering to a larger buffer they can ensure that any raster assets may use an integer scale factor between devices. If they rendered to the panel's native resolution (1080p) they'd probably have to use a 2.5x scale factor, which is not desirable.

The output will be slightly worse, but at 400 PPI you probably won't be able to tell without a magnifying glass. The current Retina MBPs do this in their higher res modes and it's pretty hard to notice.

On battery life: perhaps the tradeoff of using a 1080 panel outweighs the scaling.

Also it leaves the door open to switch to a full resolution native panel in an iPhone 7+ with no hit to existing apps or developers.

Huh, I don't know that much about GPU's, but surely they can render fractional pixels directly without downscaling shenanigans. Which actually means that GPU will convert full pixel values to fractional before rendering. Rendering to a larger buffer and then downscaling is actually a form of antialiasing, albeit an inefficient one (if I'm not wrong). Also, rendering without antialias would result in rounded full pixel values. Obviously, bitmaps will be downscaled on the GPU using whatever filters are set for them (just like before, if bitmap is larger than the target size).

It's not so much about the GPU rendering fractional pixels, it's that it makes it much trickier to create neat assets that work at non-integer scale factors. Generally you want to ensure your raster assets have details that lie on integer boundaries at all scale factors, throwing in a non-integer scale factor as a target makes it more difficult to do that.

I don't think you really understand how iOS works. iOS uses points as its units, not pixels. One point on a retina display is two physical pixels. One point on a non-retina display is one physical pixel. To create a one pixel thick line on a retina display, it must be half a point thick.

I fail to see how not having a working scalable UI framework has anything to do with this.

Furthermore, have you used auto layout in Xcode 6? Not sure what about it doesn't work. I've got an app in review right now that's ready to support iPhone 6 and 6+ without any extra work because of Autolayout. I'm not saying it's perfect, but I'm just not sure how you can claim that it plain doesn't work. Also not sure why that has anything to do with why they're scaling @3x down to 1080p

CoreGraphics uses points, not pixels. Experienced Cocoa developers know to make sure their drawing is done on pixel boundaries to avoid blurry edges, and there are APIs to help with this.

iOS does work in DIPs (it calls them points) not pixels.

And it does have a density independent UI toolkit. It just only had 2 densities until now, whole multiples of one another. Which made it a lot easier for developers to update a million apps in short order.

Now there's one more. But the "cheat" here of keeping it to a whole multiple from the dev perspective is undoubtably an intentional choice to keep it easy for developers to adopt it. Which is smart when your platform has a lot of apps and you want them all to work perfectly on all devices.

Compare that to six dpi levels for Android. It can theoretically accommodate a greater diversity of devices but developer support for them is scattershot.

>Android has proved this can work, and work fantastically.

I've used a couple of Android devices, with latest-ish OS versions and "Fantastically" is not a word I'd use in relation to their "density independent" operation, and GUIs in general.

>You don't need whole multipliers when you work in DIPs instead of PX.

You don't work in PX in iOS either. There have been logical units enforced from even before Android had a hi-DPI device available...

This is more about image (bitmap) assets apps have to use, and how they best adapt.

I've used a couple of Android devices, with latest-ish OS versions and "Fantastically" is not a word I'd use in relation to their "density independent" operation

Care to state why?

As an ios dev, i know autolayout exists and lets you somehow manage the different resolutions if you manage to change your set of mind ( no more .frame = or .center= to change the location of a view dynamically but update constraints instead), and get away with the ugliest thing in the ios api that are constraint string expressions ( which almost made me throw up the first time i saw them).

But let's face it, that's one less thing we can mock Android devs about. Pixel perfect Wysiwyg ui building in interface builder has one foot in the grave.

It's not just a matter of layout, it's also a matter of making sure that UI elements are not too small and not too large.

That seems like the only thing that they managed to keep - the assured physical dimensions of UI elements. The 44 point as a minimum guideline for tappable button size is valid for all resolutions (4:3 1x, 4:3 2x, 16:9 2x, 16:9 3x).

P.S. At least on the iPhone. The iPad mini (sporting the same resolution as the physically bigger brothers) will produce smaller UI elements.

FWIW, there are frameworks out there to make writing NSLayoutConstraints much more sensible. For example [1]

[1] https://github.com/Masonry/Masonry

Hopefully apple has updated the storyboard tools to do all of the layout constraints. I remember back in xcode5, there were some constraints that were only possible via code :(

It's really time to dump those code views son. Interface Builder gives you all the tools you need to do it and works reliable, gives a LOT of feedback on your constraints when you build them.

You should learn auto layouts using Interface Builders, otherwise it's a nightmare because you're not getting the feedback you need to learn it right in the first place.

You need to start using priorities right, specially when you are doing >=, <= constraints you also need to add a low prio == constraint. It's not that hard, but you will be really frustrated if you keep clinging on to your coded views.

Try to chop up your Storyboards if you work in teams. They shouldn't be so big that you have trouble following the flow on one monitor.

You can't code review storyboards.

Less code is a good thing! I hope you fire up Xcode to see with your own eyes if the code-only view looks okay as well?

Also it's much more documenting to they guy that's going to maintain your screens later on.

Why not? You can simply open a storyboard and review it, no?

That requires downloading, checking it out (at the exclusion of your other branches), reviewing it, figuring out how to make comments on it even though there's no review interface for storyboards, rinse repeat. Code review in objective-c is commenting on code in github while code compiles and evaluating screenshots of the current state. If apple came out with a way to review storyboards on something as convenient of github, I might consider it.

i did, son. but now tell me how you do complex animations on subviews in an autolayout view without adding constraint by code.

I have no idea what complex would be in your case but adding game-like animations to a view with auto layouts would probably not be a good idea.

But the whole point is that auto layouts from IB can be controlled from code as well so you don't have to write the code for the auto layouts completely in code. Writing auto layouts in code is laborious and it's easier to make mistakes.

So if you "park" a low priority constraint for the end point or even the points in between you can let them take over by changing priorities only. Also you can animate most other properties as well if you need it.

If your getting edge cases, why don't you just write your own layoutSubviews method and avoid using constraints except for very basic things? It's relatively simple stuff to write, and is more performant than autolayout, since layoutSubviews is O(1)-ish while autolayout looks like it's O(n^2).

If you don't believe me, look at this blog article that measures it: http://floriankugler.com/blog/2013/4/21/auto-layout-performa...

He glosses over the 6's resolution of 750x1334 vs the 5's 640x1136. Will 2x image assets be slightly blown up for the bigger screen? And what about the very slightly thinner aspect ratio?

As for "downsampling" of new 3x assets, the main image processing artifact to look out for is moire which happens to images with small repeated details. There are techniques to mitigate these artifacts but it will have to be a very smart algorithm to avoid artifacts in all cases.

OTOH, Android seems to have no problem handling small resizings of images within their size buckets system.

The iPhone 6 remains at 2X, just with more virtual pixels to work with.

My grock of the article is that there will be artifacts, its just that they are difficult to notice at that pixel density.

Wouldn't the apps simply have the 1x, 2x, and 3x bundled in. This means the size of apps is going to grow, yet again. Yey...... As for iPhone 5 vs 6. I think legacy apps, games mostly, would be blown up. Anything that uses standard UI widgets would be starched to fill the screen. So in a list view you see more lines, in a text box more characters, etc. I hope that's the solution, at least.

This write-up (also on the front page currently) is a lot simpler and focuses more on the actual dimensions, instead of frankly half-baked marketing analysis. http://www.paintcodeapp.com/news/iphone-6-screens-demystifie...

Thank you. I was so confused about where the number 1242 came from. The number 414 isn't in the entire article.

That's because the author made a calculation mistake. He wrote "412" instead of "414".

Even so the base number doesn't show up until most of the way through the lengthy article, with no explanation. Even after reading all those words I didn't understand the critical fact that there was a base size in dots that was different for each model. Everything before was 320 or a multiple.

As an end user, I'm a fan of Apple's 'scaled resolution' solution. My Apple notebook renders the screen in memory at 3840 x 2160 and then scales that to fit the 2880 x 1800 physical display. The benefit of this approach is that you can smoothly scale the UI to suit your age/eyesight.

When working, I keep mine set to smallest/most-information setting available by default (dubbed "Looks like 1920x1200"), but when relaxing I often give my tired 40-year-old eyes a break by bumping it down to "Looks like 1680 x 1050" and making everything uniformly bigger and easier to read.

When you look closely, of course it doesn't look as good as an exact match to the display native resolution does, but it looks pretty great. I think it will look even better on the 401ppi iPhone 6+ display, and the increasingly high-res screens of the future.

Tying logical display resolution to actual physical pixel resolution is pretty 💡🙉 at this point.

> As an end user, I'm a fan of Apple's 'scaled resolution' solution. My Apple notebook renders the screen in memory at 3840 x 2160 and then scales that to fit the 2880 x 1800 physical display. The benefit of this approach is that you can smoothly scale the UI to suit your age/eyesight.

That's what Windows 8.1 does when you have two screens with very different DPI (physical). When I connect my Yoga Pro 2 (with "retina"-like resolution) to my external 23" screen, it renders most applications at the high resolution, and then downscales them so they have the same size on both displays. The biggest problem with this approach is that crisp fonts on windows rely heavily on rgb sub-pixel-rendering. If your application doesn't directly paint to individual pixels, it can't control the subpixels, and can only do greyscale antialiasing, which looks very blurred (especially next to my Yoga Pro, where text looks like printed).

You can tell windows "I know what I'm doing, give me the raw pixels", but that comes with a whole lot of other problems, and I've never seen a single app get that right.

(What I'd really like as a developer would be to develop in (real) cm, inches, and em. Have them exactly match the physical sizes, for mobile and desktop screens (projectors would pretend to be a desktop). Have an option to "snap" lines to physical pixels. And on non-hidpi screens, render everything with subpixel-awareness, which triples your horizontal resolution.)

Reasonable UI systems and not-overdesigned programs respect your UI font size setting and scale the rest accordingly, while equal resolutions allow hinting to do its job and produce a sharp output in an intelligent way. The brute-force approach of densifying monitors is a dirty hack and luckily doesn't scale at all.

I understand your position, but I don't agree with it at all.

"Reasonable" and "not-overdesigned" are rarely concerns that last into the future. And I don't think they even hold up given today's (high-end) technology.

Why on earth would font size be the arbiter of anything other than font size? Some programs don't even display text.

Logically, it makes a lot more sense to scale the entire display (or, sure, subsets of it). That's still technically challenging for some of today's systems, but not all of them. And it will be a vanishingly small number of them as we move into the future.

Apple is losing its advantage over Android regarding market fragmentation.

An iOS developer has to support eight different screens these days to cover all devices that will run iOS8:

* iPad 2

* iPad mini (the last non retina devices, same resolution, different DPI)

* iPhone 4S

* iPhone 5/5C/5S/iPod Touch 5th gen

* iPhone 6

* iPhone 6 Plus

* iPad 3/4/Air

* iPad Mini Retina (again, same resolution, different DPI)

Many devs will ignore the DPI differences between the iPad and the iPad mini, but that isn't ideal. I think the iPhone 6 Plus should have had a 1600x900 display to keep the DPI in line with the previous phones, however Apple was probably afraid to be compared unfavorably to the Android phones that have 1080p panels.

From my understanding, they did kept the DPI in line. A 44 point button will have the same physical size in all iPhones, including 6+. It will, however, require three graphical assets (if you intend to support non-retina).

However, as you point out, this is not true for the iPad.

Eh, that's not exactly how it works. You're confusing physical device resolution/size with the logical resolution that developers have to deal with. From a development perspective, with the exception that you have to make 1x, 2x, and (now) 3x bitmaps:

* iPad 2 = iPad Mini = iPad 3 = iPad 4 = iPad Air = iPad Mini Retina

* iPhone 5 = iPhone 5C = iPhone 5S = iPod Touch 5th gen

* iPhone 4S is a "sort of" outlier. If you're using the auto-layout stuff that's available it "just works" on a 5* phone. The exception is apps that aren't widget-based, like games.

* iPhone 6 and 6+ seem to have different logical resolutions, so there's that. But again, auto-layout helps here.

The "different DPI" thing is irrelevant. Get the UI elements to have the same size proportionally and you're set.

Which is not much different than Android, despite all the sensationalism about having to support "18,000 different devices".

You have to support only 6 pretty much, which comes quite close to how many you have to support on iOS right now (you mentioned 5):

ldpi (low) ~120dpi

mdpi (medium) ~160dpi

hdpi (high) ~240dpi

xhdpi (extra-high) ~320dpi

xxhdpi (extra-extra-high) ~480dpi

xxxhdpi (extra-extra-extra-high) ~640dpi

https://developer.android.com/guide/practices/screens_suppor...

This is only true with regards to screen resolutions. From my experience, there are more issues caused by different hardware (making camera work with all devices require a lot of testing), and custom keyboards also cause problems. (Custom keyboards will affect iOS 8 as well, but we will see if it will cause problems. This depends a lot on API design.)

That's actually primarily for phones. For tablets you're supposed to use sw<x>dp. So, add sw600dp and sw720dp to your list. Now we're talking about 8 logical resolutions to support. And the bigger issue, as another person pointed out, is the fact that a _lot_ of the new APIs aren't backported. So you end up having to target the lowest common denominator API version, which is almost certainly two years old.

Contrast that with iOS. The latest version adoption rates are something absurd like 90% within the first month. You can actually take advantage of those spiffy new APIs without having to worry about limiting your audience. The limited set of resolutions is icing on the cake... far less to worry about.

as a note, xxxhdpi is only used for launcher icons (on the nexus 5 and possibly others). 640dpi screens seems like it would only be plausible for VR headsets maybe.

When it comes to Android fragmentation, at least personally, I believe it has more to do with hardware specs than screen resolution.

I remember at my old job, we had an issue with a game being shipped because a handful of phones wouldn't be able to get past the first screen after hitting play. IIRC the issue was around the processor (or something hardware related) not having the ability to render certain things from Unity. It affected about 5 phones, but the published deemed it big enough to not be shippable.

>Apple is losing its advantage over Android regarding market fragmentation.

Android has 5000 devices, differing OS versions (half of the devices out there use a 2 to 3 year old OS), and differing hardware capabilities (including different qualities in stuff like sensors, some of them even being nearly useless).

And Apple is losing to that because it has "8 different" screens?

For one, you can support most of them (all iPads for example) with the exact same code plus 2 sets of bitmap assets: normal and 2x.

As for the iPhones, they transitioned without a hitch to 5 taller display, and the same will happen to 6/6+.

Testing for 5000 devices isn't much different from testing for 8 devices. At some point you stop writing and testing for every configuration separately, and start grouping them, pretty much as you describe with one code and 3-5 sets of assets (counting both bitmaps and layouts).

differing OS versions (half of the devices out there use a 2 to 3 year old OS)

That stat is pretty out of date by now. Android <= 2 now only accounts for 12% of devices, and most app devs aren't targeting it any more.

And Android might have 5000 devices, but it doesn't have 5000 screen sizes. Still more than Apple has, but hardly 4992 more.

http://www.androidheadlines.com/2014/09/androids-kitkat-clos...

Half of all devices use API16 or older (4.1) [0], which is now two years old, so your parent post was still accurate.

Of course, operating system fragmentation has become less of an issue generally since ICS/JB became dominant.

[0] https://developer.android.com/about/dashboards/index.html?ut...

Indeed. For the modern Android dev, there aren't that many aspect ratios that you really need to support.

Most modern phones are 16:9 (720, 960, 1080). There are still a few stragglers (Motorola in particular), but they're becoming a thing of the past.

You basically have three aspect ratios to worry about right now: 16:9, 5:3, and Motorola's 427:240.

With iOS, you have 3:2, 4:3, 71:40 (iPhone 5), and now these new iPhone 6 internal aspect ratios that get hardware resampled.

Actually 71/40 and "these new iPhone 6 internal aspect ratios" are just the same thing.

So, it all boils down to: 4:3 (all iPads) and 1.177 (5, 5S, 5C, 6, 6+).

3:2 is just a legacy ratio that will go away going forward as the 4S gets older. It's not a ratio they have produced iPhones with for several years now.

Also, Android's layout system is light years ahead of iOS's AutoLayout and Size Classes.

Not to mention Bluetooth support: 4.0 wasn't officially supported until Android 4.4 (IIRC), and you had to rely on OEM-specific libraries for Bluetooth beforehand.

In terms of layout there only 5 resolutions (ignoring DPIs): https://rythie.com/ios-sizes/ and then assets in @x2 @x3 versions

In theory. In practice, you could get away with supporting just iPhone and iPad layouts, or one or the other if not going Universal. (And Autolayout helps you move forward when you're ready pretty easily.) Also, you don't have to worry about things like graphics hardware differences, poorly-implemented APIs, and OS versions nearly as much.

Is it even possible to tell the difference between the iPad and iPad Mini in software? When it first came out, it wasn't, on purpose.

> Many devs will ignore the DPI differences between the iPad and the iPad mini, but that isn't ideal.

Most developers do ignore this, and Apple encourages ignoring it. Incidentally, this is why tap target sizes (button sizes and such) are a bit bigger on a full-sized iPad than on an iPhone; to allow for the scale-down.

I'm sorry you're wrong, different screen-sizes (and resolutions) are NOT market fragmentation. It's not hard to handle them and we've been writing phone and tablet apps for years now, so that's a solved problem.

API/Platform fragmentation is the big problem. Supporting multiple APIs and gracefully degrading to older versions is much harder than being able to scale your UI. Apple has been pretty good with keeping customers devices as current as possible. Android, not so much.

>Many devs will ignore the DPI differences between the iPad and the iPad mini

That's because iOS-only developers were spoiled and got lazy. If your app breaks because now it has to work with a slightly different aspect ratio, or doesn't take advantage of a higer DPI screen, that's your failing.

> I'm sorry you're wrong, different screen-sizes (and resolutions) are NOT market fragmentation. It's not hard to handle them and we've been writing phone and tablet apps for years now, so that's a solved problem.

Yes it is fragmentation. Just because it is "solved", doesn't mean it doesn't create extra work, extra bugs, and from a test matrix perspective, more compromises.

Yes, it would be much better if everyone used one aspect ratio, one dpi, one device - but this is something you just deal with, if you're building a native app, not complain about it, or even expect that screen-sizes will forever be constant (which is what the OP suggested). It's like if web developers complained that their job is more difficult because they have to support users resizing their browser window. Strictly true, but insane.

Again, iOS developers got spoiled by not having to deal with this stuff for the last few years so maybe it seems like it's a big deal. The reality is, once you stop expecting a specific screen properties, it really isn't that big of a deal. It's just reality.

And no, it's not fragmentation. There is absolutely no reason to freeze out certain users because of their screen-size, or not provide certain features.

Calm down silly-generalization-man. This my surprise you but "iOS developers" aren't a monolith, aren't spoiled, and most have developed for other environments as well. There are more sizes to develop and test for. What was one is now more than one. Fragmentation.

> API/Platform fragmentation is the big problem. Supporting multiple APIs and gracefully degrading to older versions is much harder than being able to scale your UI. Apple has been pretty good with keeping customers devices as current as possible. Android, not so much.

This is highly dependent on which kind of APIs you are interacting with. Most API families are part of Google Play Services now which means they are generally available back to 2.3. Framework API differences between platforms are generally small and haven't been much trouble to work with, although some types of hardware interaction changed significantly between some platform levels (e.g. audio).

'Market Fragmentation' != Device resolutions.

lrn2terms

As an iPhone app developer, I agree with your first sentence, but the resolutions are actually the smallest issue. In addition to what has been said in the sibling replies,

* Designing for iPhone 4/4S and 5/5c/5s is almost the same, at least in portrait orientation. Most layouts are a little flexible vertically - and they have to be, because users might be in a call, or have the personal hotspot active, in which case the OS reserves some space for an additional status bar. Apps have to be flexible vertically, period. * It is much harder to support all the larger text sizes that are available in iOS 7. Much of the iOS UI is built on UITableViews, and these "tables" are terrible when it comes to line breaks. I have increased the text size and many apps can't handle it, including some of Apple's own. * If you are extra masochistic, enable "Button Shapes" and "Reduce White Point" in the Accessibility options in a custom-styled iOS 7 app. For example, this will darken tint colours, which can make buttons harder to read if they are placed over an image (which the OS will not darken).

To be honest, dealing with status bar height changes are far more annoying in iOS than having to support a few different resolution sizes.

Another possibility for the lower res is perf. I think it's quite possible the 6+ will have the worst per pixel perf of any modern iOS device. In the conference they, I believe, bragged ~38% more pixels on the 6 and 170% more in the 6+. But the GPU is only 50% faster!

The iPhone 4 and ipad3 both suffered seriously by having 4x the pixels as their predecessor but only 2x the GPU. Mostly games suffered but it's still an issue elsewhere with fancy animations, transparency, etc.

But this is all speculatory theorycrafting at this point

The performance should be comparable to the iPad. They share the same SOC.

...no? 6 and 6+ are both A8. 5s, Ipad air and mini retina are a7. I believe air is clocked slightly higher tha 5s, 1.3ghz vs 1.2.

I think without question the 6+ will have worse per pixel perf than the 6. It would be even more worse if the screen were even more higher res.

That's not enough to make or break anything. But it's got to be another consideration.

iPad Airs don't have any problems using a 2048x1536 resolution with the A7. I guess it can be safely said that iPhone 6s won't have problems with their resolution on an A8.

Yes they do share the exact same SOC on the current iPhone/iPad (as mentioned below). They will almost certainly share the same SOC with the new iPad. So yes whilst the iPhone 6 will have better performance than the 6+, it won't matter because the 6+ will be comparable to the iPad.

Happy?

That makes no sense to me. If that were the issue, they wouldn't use the larger frame buffer internally, which (AFAIK) is what dictates graphics performance insofar as it depends on display resolution.

So it's essentially the same thing as the "Scaled" display modes of the Retina MacBook Pro. An interesting approach.

A simpler way to explain this is that for the iPhone 6, it really is a slightly larger iPhone 5 screen, like if you were moving from an 11" MacBook Air to a 13" one. But for the iPhone 6+, it's like moving from that 13" one to a 15" Retina MBP. And as we all know, the Retina Macbooks render at a higher internal resolution and then scale it down to the native one.

I do appreciate the technical explanation, but as Apple has done this before, for a quick explanation it's sufficient to point to the rMBP precedent.

> And as we all know, the Retina Macbooks render at a higher internal resolution and then scale it down to the native one.

I don't know that. Unless you're talking about scaled modes, which do resampling, the retina models render at the native resolution. They will scale apps by 2x that are not capable of rendering at the native resolution (not many).

What would happen if you tried to draw a fullscreen 1:1 pixel tiled checkerboard pattern?

Well if it's using 3x scaling, then writing one pixel will write a 3x3 block on a 1242x2208 buffer that gets downscaled to 1080x1920 yielding a result like this https://imgur.com/ZsJKxzV

Hmm, what if the checkerboard pattern is at 1:1 (1x1 blocks)?

Depends on which downscaling algorithm(s) they use

Moiré patterns probably.

This really needs a TLDR.

There is one.

... at the bottom.

I believe that's the most common location. It takes one keypress or mouse action to get there.

Retina displays have 2 physical pixels per logical pixel. The 6+ has 3x. However, the screen resolution isn't quite high enough for that so there is hardware downsampling. The author thinks that it'll look ok though.

God bless you

Am I the only one that noticed the iPhone on the left is actually a 5s and not a 6?

Very interesting approach. Like others said, the best way to describe is like using the higher resolution (scaled) mode on a Retina MBP.

I wanted to share pxcalc [1] for anyone doing DPI/PPI calculations, please be aware it exists (and it's awesome).

[1] http://pxcalc.com/

Quote: "Calculating diagonal pixel is easy, following this formula: SquareRoot(w x w + h x h)."

Gee -- what's wrong with y = √(w² + h²)? It's much easier to interpret.

maybe because you can't easily type that into a calculator like the one in Spotlight or google.com?

Fair enough, in that case:

y = sqrt(w^2 + h^2)

It not that they had a bright moment when going for a normal (power of two) resolution, its just that they have not done so up until now. And nobody except Apple used those technically suboptimal resolutions in mobile phones, with good reason..

Anybody know what window.devicePixelRatio will report on the 6+?

Raster-based pixel manipulation applications suck in this brave new hidpi world!

In article he mentioned 1242px by 2208px with 462ppi as 3x of 163ppi (original iPhone). Shouldn't it be 489ppi ?

Really confusing.

Yep, another error. He also wrote 412px instead of 414px in some other location.

Not quite an error (the calculation is correct). It just don't make sense for me why Apple come up with this magic 462ppi instead of 489ppi.

Is DPI really a term in the iOS community? I thought DPI was a holdover from the print-era, and the politically-correct term was PPI (pixels-per-inch - not "physical" pixels per inch).

I've heard 1x pixels called "device-independent pixels", "CSS pixels", and "points"; but I've never seriously heard the term "device-pixels-per-inch" until this article.

I really don't think it matters if you call them "dots per inch" or "pixels per inch".

Everyone uses the term DPI for displays even if the correct term is PPI. It's not worth fighting about...

I don't mind people using the term DPI. The part that confused me is that the OP is drawing a distinction between them.

In my mind DPI == "dots per inch", PPI == "pixels per inch", and they measure the same thing (although some people frown upon using DPI in a digital context). The author redefines them to mean "device pixels per inch" and "physical pixels per inch", where PPI / devicePixelRatio == DPI. I wasn't sure if that's an OP-thing or an iOS thing.

I haven't had the time to look at the docs but shall I start shipping art assets as foo@3x.png ?

Yep. Xcode has also added 3x slots to xcassets files.

I don't understand how such high PPI really matter at all. I mean it increases battery usage, it costs more, and all you get is smoother text and smoother pictures on a less than 5 inch screen.

> all you get is smoother text and smoother pictures on a less than 5 inch screen.

I don't think smoother text (and pictures) is anything to be trivialized. I mean it actually looks much much nicer and (imho) comforting - I experience joy anytime I look at anything that's above the 100 or so ppi of average 1080p monitors.

People spend huge swaths of money on the looks of things that they'll hardly ever be looking at. Considering this, spending the money on a screen (i.e. something they'll litteraly be staring at for large periods of time) is actually a borderline-rational choice in comparision..

> I experience joy anytime I look at anything that's above the 100 or so ppi of average 1080p monitors.

I experience joy when I can go online and check my emails when I'm in the bus or outside.

And our village idiot experiences joy whenever he is given a lolipop.

What I'm getting at is, priorities may vary. You might care for portability of checking emails outside, I'd rather have crispy text because I'm working with all day inside.

> I don't understand how such high PPI really matter at all.

If there's more resolution than the display (or the observer's eye) can support, the extra resolution can be used to make diagonal lines look better (as one example), through a sophisticated drawing method that eliminates jaggies. I'm not saying this is always true, but it's on the list of options to exploit the extra resolution.

> I mean it increases battery usage, it costs more, and all you get is smoother text and smoother pictures on a less than 5 inch screen.

That's pretty much it. But consider that people who buy Apple phones know they're not buying the least expensive, most cost-effective devices, so maybe they expect to get something not present in the bargain phones, like resolution that no one can possibly notice. Sort of like having a refrigerator whose light stays on when the door is closed.

For one, at 800dpi or so aliasing problems go away. With that kind of density, I presume, race for density will be done.

I had always heard it's in the 300 range. Phil Plait did an analysis back in the day using "display held one foot away" as the metric and determined that "average eyesight" could resolve 286 PPI. "Perfect eyesight" would bump it to 477 PPI.

http://blogs.discovermagazine.com/badastronomy/2010/06/10/re...

I remember that 800 number from one of the books about graphics and rendering. Forgot which one, probably Glassner's. So it might be more of a theoretical/ultimate threshold than anything. Also, it's not about resolving individual pixels but removing aliasing effects due to signal /picture density.

that's an expensive way to solve a cheap problem, which has already been solved.

And with all this added screen real estate, you're still limited to 4 apps/row. Absurd.

Oh god not another "Apple made the iPhone 3.5" which is the perfect size" type of post.

There's no brilliant magic golden ratio formula behind Apple choosing 1080p. They simply wanted to choose a "regular" resolution for once, while still being bigger than 326 PPI.

If 720p would've been more than 326 PPI for the 4.7" one, they would've chosen that, too. The reason they didn't is because 720p is less than 326 PPI, and they didn't want to have 1,000 headlines out there say how "iPhone 6 has less pixel density than previous iPhones".

In my opinion they should've done that anyway, and end it with the stupid resolutions that Apple keeps using just because they didn't have the foresight to add resolution scaling early on to iOS, because they never imaged they could be building any other mobile device that isn't 3.5" in size. They messed up the "perfect scaling" for developers with 1080p on the Plus anyway. They could've done it on the smaller one, too. It's silly that they didn't do it.

Did you even read the article?

Reply on news.ycombinator.com