Hacker News Reader

Hacker News

Comment by Tepix | Hacker News Reader

Full thread

Tepix

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.

View on HN

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.

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

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

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.

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

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.

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

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

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

'Market Fragmentation' != Device resolutions.

lrn2terms

Reply on news.ycombinator.com