6 ms·

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 th

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.

vyshane 12y ago
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.
- moca 12y ago
  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.
  - cmelbye 12y ago
    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.
    - icoder 12y ago
      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.
      - prof_hobart 12y ago
        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.
      - cmelbye 12y ago
        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.
  - vyshane 12y ago
    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.
    - x0054 12y ago
      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.
      - easytiger 12y ago
        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 http://goo.gl/pTwfws
    - cageface 12y ago
      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.
      - 12y ago
moca 12y ago
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.
interpol_p 12y ago
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.
- mirsadm 12y ago
  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.
  - lewispb 12y ago
    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.
    - ardacinar 12y ago
      The alternative talked about here is not having the physical screen resolution of 2208x1242 but rather just rendering at 1080p without scaling down.
  - slyn 12y ago
    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.
cmelbye 12y ago
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.
zaksoup 12y ago
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
vor_ 12y ago
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.
abalone 12y ago
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.
coldtea 12y ago
>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.
- untog 12y ago
  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?

vyshane 12y ago

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.

moca 12y ago
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.
- cmelbye 12y ago
  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.
  - icoder 12y ago
    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.
    - prof_hobart 12y ago
      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.
    - cmelbye 12y ago
      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.
- vyshane 12y ago
  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.
  - x0054 12y ago
    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.
    - easytiger 12y ago
      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 http://goo.gl/pTwfws
  - cageface 12y ago
    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.
    - 12y ago

moca 12y ago

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.

interpol_p 12y ago

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.

mirsadm 12y ago
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.
- lewispb 12y ago
  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.
  - ardacinar 12y ago
    The alternative talked about here is not having the physical screen resolution of 2208x1242 but rather just rendering at 1080p without scaling down.
- slyn 12y ago
  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.

cmelbye 12y ago

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.

zaksoup 12y ago

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

vor_ 12y ago

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.

abalone 12y ago

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.

coldtea 12y ago

>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.

untog 12y ago
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?