Slashdot Mirror
Android Fragmentation Isn't Hurting Its Adoption
Nerval's Lobster writes "Apple's developer Website offers a new, handy graph of iOS fragmentation — which, of course, highlights that the mobile operating system isn't fragmented much at all. A full 93 percent of iOS users are on iOS 6, the latest version; another 6 percent rely on iOS 5; and a mere 1 percent use an earlier iOS. Compare that to Google Android, which really is fragmented: some 33 percent of Android devices run some variant (either 4.1.x or 4.2.x) of the 'Jelly Bean' build, while 36.5 percent run a version of 'Gingerbread,' which was first released in December 2010 — ancient history, in mobile-software terms. (Other versions take up varying slices of the Android pie.) For years, Google's rivals have used the 'Android is fragmented' argument to hype their own platforms. But is Android's fragmentation really hurting the platform? Not as far as global shipments are concerned. According to recent data from research firm IDC, Android's market-share stood at 75 percent in the first quarter of 2013 — up from 59.1 percent in the same quarter a year ago. Meanwhile, iOS owned 17.3 percent of the market — compared to 23.1 percent in the year-ago quarter. Whatever the drawbacks of fragmentation (and people can name quite a few), it's clear that it's not really hurting Android device shipments or adoption."
The argument presented doesn't seem to actually grasp the point of the comparisons. On one hand you may be interested in market share. But when Apple presents the issue at WWDC they're not talking about market share. They are talking about what the actual platforms in use are and which ones are going to present the best area for developers to target. Three different versions of android are going to present three different APIs that app developers are going to have to deal with. On the iOS side you can target iOS 6 and know that you're be hitting almost the entire market segment.
But that wasn't the point of the graphic. The graphic was created by Apple to tell developers that they should target the newest version of iOS exclusively, if possible.
Now imagine making that argument on Android. Anyone suggesting that an Android developer should seriously target 4.2 exclusively would be laughed out of the room.
This article is missing the point. It was a dig at Android for hurting developers, not necessarily users.
...who's going to buy your app?
If you've got to target 6 or so major differences in versions—not to mention the differences in hardware—to reach the same percentage of Android users as you could reach in iOS users by targeting only iOS 6, that's got to say something about the ROI you can expect.
And that's not even taking into account the many datapoints showing that Android users buy something like half, or less, the amount of apps per device that iOS users do. (I don't have the numbers in front of me right now, but my memory suggests it was considerably less—like, closer to 10% than 50%.)
The reason Android's adoption is high is pretty damn obvious to anyone who's actually paying attention: the phones occupying the space in carrier lineups that, seven years ago, would have been held by dumbphones are now cheap Android phones. People buy Android not because they're choosing it, but because that's what happens to come on their phone...which they use almost exclusively to talk and text. (And maybe check Twitter and Facebook.)
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
It has everything to do with being able to develop for phones. The article misses the point entirely.
As someone who develops for both, testing in Android *is* a pain in the ass. Developing in it is a breeze. The minor issues you run into on varying handsets is just a nightmare to deal with. The small variances because manufactures can't develop to API specifications correctly.
I question anyone who says it isn't an issue. Either you aren't doing development or you haven't built something complex enough to see the various issues.
If you're coding for the iPhone, you deal with iPhone 5 screen resolution and iPhone 4/4S. That's 2 screen resolutions.
Try coding for Android, while having fun doing it ;)
I actually have a feeling the screen resolution thing isn't going to hold. Apple is going to go with multiple screens eventually.
I program part time for Android, and the screen resolution thing isn't actually what bothers me on Android. A lot of other things do bother me and make iOS still my favorite platform. But both platforms have very effective tools for dealing with screen size differences (Android more in practice, and iOS more in theory at this point.)
Apple's point is that their installed base (no matter what size or market share it is) has very little fragmentation allowing those who develop for the platform to target only the newest iOS. For developers this is a big deal.
Getting market share because you re selling junk like this the Samsung Pocket that still comes with Android 2.3 is not helping out anybody. The security implications of running this older OS is also an issue.
I am not advocating one side or the other. I am saying the OP countered the point Apple were making with a somewhat irrelevant argument.
Most of it's that the "fragmentation" in Android really isn't visible at the developer level. Sure you've got a lot of versions. But in general the API changes between versions don't break backwards compatibility: if you wrote code for API level 8 (Android 2.2), it's almost certainly going to run just fine on a device running API level 17 (Android 4.2.2). It mostly comes down to picking the minimum API level that supports all the features you need and writing to that. There's only a relatively few places where you need to explicitly handle differences, eg. coding for "If the device supports NFC then hook up the handlers for it, otherwise don't bother.". Most of those are just like that, simple feature tests: does this device have GPS, does it have a camera, and so on. Only a small minority are truly complicated to handle and need special coding based on the Android version.
It's a lot like cars. There's how many car manufacturers, and how many hundred different models? Yet when you sit down in one you don't worry about that huge degree of fragmentation. The controls will mostly be where they ought to be and the ones that aren't aren't safety-critical and aren't that hard to figure out, and while the shape of the fenders and design of the taillights may change the looks dramatically that doesn't really impact your ability to drive it.
Android has 75% of the device shipments, but Apple has 74% of app revenue. Fragmentation may not affect device shipments, but it certainly seems to be affecting other things.
Look at it another way. Android has 75% device shipment marketshare. Apple has 18%. This means Google ships 4.17x as many devices. But (not knowing the Android app store marketshare), Apple has a minimum of 2.85x the overall app store revenue.
This means that Apple devices, on average, produce roughly 12x the app revenue. Is this because of platform fragmentation? Is this because of Apple's demograhics? I don't know, but dismissing fragmentation based purely on device shipment market share is shortsighted.
Apple still has feature fragmentation. Airdrop is going to be Iphone 5 or above only. I find it hard to believe an iphone 4 cant exchange files in the field.
Good-bye
And this is somehow different from the PC market?
I can't recall the last time I heard anybody complaining about the PC market being fragmented. It's standard for Apple to use fragmentation as an argument against their opposition, because they want to make all the decisions for the end users. It's easy to eliminate fragmentation when you limit the option to things that you've chosen.
There are two axis for fragmentation.
The graph is showing the one that doesn't matter, since you can always target a subset of the APi which is supported by all the versions of the OS; that's the same for both iOS and Android, and it's just common sense code portability. The first product I worked on out of college was TERM software for a small company called Century Software in Salt Lake City, Utah, At one point, we had greater market penetration for async communications software on UNIX systems than UUCP, and UNIX systems came with UUCP for free. We also ran on VMS, BTOS, CP/M, MP/M, Mac OS, and half a dozen other non-UNIX platforms, as well as the 140+ UNIX platforms we ran on.
The secret to this success was to have as small a porting surface as possible, and that's eminently possible with both iOS and Android, although that type of design and coding tends to not be taught in colleges and universities these days, it's still eminently possible. It's just a matter of API contracts.
The other axis is hardware differences, and you can't ignore those for either iOS or Android. Those are the ones you can't get around with API contracts, because they touch on different device capabilities - the most important of which is screen aspect ratio, and that's the very thing that iPhone 5 broke, and it's the very thing the original iPad broke. Sure, there are other important parts to this; there the "I" in "I/O" as well, in particular, of all the sensors, there's keyboard inputs, but for the most part, that has fallen out to touch interfaces, which pretty much everyone other than Blackberry has agreed upon, and GPS. All the other sensors are much less useful to most apps.
If you talk to a Rovio engineer (and I have) on this issue, they effectively target a dozen iOS hardware platforms: to get the best user experience, and to get where they are today, with "Angry Birds" being the top selling mobile game of all time, they've had to adjust to aspect ration, resolution, and OS version. Being a game has meant having a much larger porting surface, in terms of OS interaction. And yeah, this means several dozen Android platforms, as well as their other platforms, but the difference between a dozen and several dozen isn't as large as the difference between 1 and a dozen.
Rather than pointing to Apple infographics, you'd be much better off pointing at the biggest success story in the industry, and doing as they do, rather than doing as Apple would have you do, since it's more important to be a top seller than it is to be portable, if the end goal is popularity with users and income.
Let's see. With Apple, you can target 100% of 17% = 17% of phone buyers, whereas with Android you can target 75% of 75% = 56% of phone buyers.
For applications, it never wasn't much of a problem.
However for games, the biggest problems I faced were the different configurations of the CPU (some included NEON and some didn't, which improves performance enormously), and the GPU ( OpenGL ES implementations were buggy depending on drivers, different texture compression schemes, etc).
Nowadays, everything is coming out with NEON and future phones are starting to support OpenGL ES 3.0, which is much more standarized (that will take some years to settle though). However, it's mainly supporting the 4 main architectures properly by checking the extensions: Tegra, Adreno, Mali and PowerVR. There are more (like the Rockchip ones, but those usually come with crappy hardware), but supporting those means that your app or game will run pretty much anywhere.
The challenge is probably dealing with different screen resolutions and aspect ratios, which wasn't a problem on iOS until recently (iPhone 5).
If you're coding for the iPhone, you deal with iPhone 5 screen resolution and iPhone 4/4S. That's 2 screen resolutions. Try coding for Android, while having fun doing it ;)
To an iOS developer who hard-codes screen resolutions and aspect ratios like a Guttenberg-press typesetter would at the end of the 15th century, dealing with screens of different resolutions, different aspect ratios, and different sizes like Android does would seem like an insurmountable task to him/her, but that's one of the easiest problems to deal with once you start understanding the Android fundamentals and once you start writing your application the Android way (although, some veteran iPhone developers don't even try to do that when developing for Android, so they end up writing an android application like they would have an iPhone application).
If you're going to complain about the Android fragmentation, then complain about bluetooth compatibility between all the different Android devices. That is a pain, a real pain (assuming your client insists on compatibility between all Android phones/tablets, and not just the bluetooth compatibility of certain models with the same chips -- the latter of which is easy enough to do).
>> You must be somewhat mathematically challenged, because even if you and Apple are right, targeting a subset of 75% of the market is still better than targeting nearly all of 17% of the market.
And yet, 75% of app revenue is from iOS. So as a developer the 75% marketshare means nothing if those people aren't buying apps.
Even so, this represents an edge case, and not the majority of app development by far. Most apps don't do anything special with phone features.
Look at it like this... if you compare IOS 6 to Android 4.x, you get:
IOS: you get 90% of 25% of the market on a single relesae.
Android: you get 75% of 75% of the market.
You end up with more than twice the target audience with Android 56.25% vs 22.5%. Now, IOS people tend to buy more apps because IOS users are "premium" users and many Android devices are "freebie" phones that come with a cell plan. But even so, those numbers should be scaring the piss out of Apple.
I have no problem with your religion until you decide it's reason to deprive others of the truth.