"Google’s data could be skewed. It is entirely possible that users with older devices simply don’t access the Market as often because the apps they want aren’t compatible with older versions of Android."
This may be true but as a developer you're really only interested in your actual, addressable market and that includes only the people who in fact visit the app store.
So while it may be wrong to say that "77% of all Android devices run 2.1 or 2.2" it's true to say that 77% of your market as a developer runs 2.1 or 2.2.
And from a fragmentation point of view, that's what counts.
Maybe from a techinical/code perspective, that's what matters, but from a size-of-the-market perspective, there's a huge piece of key data missing here.
77% of devices accessing the App Market are 2.1 or 2.2. But what percentage of all devices sold are actually 2.1 or 2.2? Depending on that number, the size of the actual reachable market could be much lower than the installed base of all Android devices.
I agree that it's the size of your market that's important. However if a large percentage of Android users can't or don't access the market (because of old software), then your market is not as large as it could be, and that is not ideal.
I know that Android's OS versions are more fragmented, because they're controlled by Google, handset manufacturers AND carriers (in contrast to the iPhone being solely controlled by Apple), but I always thought hardware, not software, fragmentation was the big issue.
There are about 80 different Android smartphones that have been released according to Wikipedia. That is more than what RIM have released in the last 15 years, including their pagers and carrier-specific versions, and a lot more than the 4 iPhones and 5 webOS smartphones.
I can't speak much about consumer-side of things, but as a developer, I can tell you that developing for iOS and webOS is easier and cheaper because there are less devices. I test on every iOS and webOS device, but on less than 10% of the available Android devices, because of the cost caused by so many devices.
In theory this is no big deal.
For most apps the only difference you would take care of is screen resolution and this is handled pretty good by Android.
You would have to check in source code for different capabilities of course (if you can read the location from GPS/Wifi or not, for example). But that's also no big deal.
One thing to worry about though, is that it is possible that different hardware uses different drivers. I've read about one game that did run very poor on a particular Samsung device, because the OpenGL driver had a bug or missing feature.
The framework does a pretty good job for abstracting the different capabilities and supporting different hardware (on a phone). When manufacturers produce buggy hardware drivers, that's where you need to dig deep.
"In theory, there is no difference between theory and practice. In practice, there always is."
I was doing iPhone development back when there was only 2 generations of iPod Touch and 1 generation of iPhone. In theory, they ran the same platform. In practice, there were several subtle differences between the hardware capabilities and resources on each permutation -- and that was assuming you were running the exact same OS version, which, in the wild, is not always true. A game that looked and worked perfectly on say my iPhone would have a weird glitch on a Touch. And so it had to be tested and tweaked to run well on each. Since then, they've added several more hardware generations of Touch and iPhone, and now also the iPad, and now there are more OS versions in the wild too. Yes, thankfully, Apple allows you to build your app so it officially only supports a narrow subset of these platform permutations. But in practice, your clients/employers often want you to support a wider set. Re-enter fragmentation pain. And this is in the iOS ecosystem, which should be less fragmented than Android.
I did write "in theory" more because i've not developed for Android in a long time, and only know from the beginnings of Android that they did a pretty good job in supporting different devices. At that time there only was the HTC Dream and the emulator, so i can't speak of experience with such a big range of Android phones nowadays. I only know that the apps i've written back then should "in theory" also run on the Nexus One without problems.
As you are talking about games, i can imagine that this is much harder on Android as you can't rely on the built-in UI-Framework and have to handle different resolutions yourself.
In practice you do run into cross-device issues, though. For instance, the ConnectBot SSH client has a glitch that makes it impossible to type the pipe character with the custom Sense virtual keyboard on the HTC Incredible. But it works fine on stock Android.
Software is one side of the coin. The other side is hardware and developers are dealing with different screen sizes, different sensors, different keyboards and so on. Compared to Apple's iPhone, you have to spend a lot of time making your app work on every device.
Different sensors do not enter the picture, unless your application uses them all (99% of them don't). Different keyboards do not enter the picture at all. Different screen sizes are handled very neatly since 1.6.
Most applications don't use any sensors at all, yet you have to deal with the situation if you plan to use them. And there is a big difference in designing an application for devices having only a touchscreen keyboard and devices having a physical keyboard.
The sensors situation is the same on all platforms - if you want to use them, you have to handle them. If not, just ignore them. How is that more complicated on Android?
The difference with keyboards - the original point was "all the keyboards" (i.e. HTC IME, Swype, etc), not just hardware vs software. When you prepare your application for software keyboard, whether pan-and-scan or resize, it will just work with hardware keyboard (opposite is slightly more complicated: when you assume only hardware keyboard, then the software keyboard has surprises in layouts for you).
Getting OT: sometimes I wonder, how people could handle PCs 20 years ago. You had CPUs with different speeds (286 to 486), different graphics cards with different resolutions (EGA, VGA, SVGA), operating system that didn't abstract the differences and yet the PC was considered single platform, much more successful than competing unified platforms. There wasn't rampart rationalization against "fragmentation", like today.
What fragmentation? 23% of shoppers can't buy your apps. That's assuming they can access the Market at all, which is not a given on any of the brand new devices that still ship with 1.6.
When I talk to Android users about my preference for building for the iOS store, they chastise me. When I talk to other developers, they're generally in agreeance with me (with some exceptions, namely purely hacker types not looking to make real profit who are more hobby oriented). Unless your revenue model is ad driven or complementary to another product, it is very hard to make a reasonable living on the Android Market. Users looking for an "open" experience are expecting free/cheap apps, and are willing to use less perfect free/cheap apps over your perfected "expensive" one. Fragmentation (which certainly exists, even on the App Store) simply exaggerates this problem.
The situation is getting better with regard to paid apps, 18 new countries got access a month back. Also, Paypal integration is rumoured to be on the way.
And please don't make blanket statements like this unless you have data to back it up:
>Users looking for an "open" experience are expecting free/cheap apps, and are willing to use less perfect free/cheap apps over your perfected "expensive" one
Anybody would rather use a free/cheap app rather than an expensive one. I don't know that FOSS users are any different in this regard.
Edit: Remember Marco Arment's "Two App Stores"? The same is true of Android, and any other market.
Great. Now as a developer who wants to write software for your system, I have some questions. Are you running KDE or Gnome? Are you using apt or rpm? What version of Python are you running? What's your kernel version?
1) Of course the data is skewed! Please don't use a headline only to correctly question its content in the last sentence.
2) Fragmentation hits at two, largely orthogonal levels - there are different versions of the base OS (1.6, 2.1, 2.2) as well as different top-level UIs/distributions (HTC Sense, Samsung stuff, stock Android). The fragmentation problem would persist even if 100% of all accesses came from 2.2 devices. This is equivalent to claiming that Linux is a unified platform because 77% of all google.com visitors use the same kernel.
3) Don't forget the hardware problem. iOS and webOS aren't perfect in that respect, but comparatively harmless.
The hardware-isn't-the-same fragmentation problem still exists in an all 2.2 ecosystem. The is-this-API-call-supported problem does not. Problem 2 is a bigger problem, but solving it does not fix problem 1.
This article doesn't even refute the idea of OS level fragmentation. They arbitrarily bundled two versions. If you look at the original data, the most share held by any single version of Android is 40.8%: <http://developer.android.com/resources/dashboard/platform-ve...; And it's not even the newest version!
The less spin-laden headline would be: "What fragmentation? 36% of devices run Android 2.2."
I hate to say this, but of that 77%, the percent of devices that will probably never get vendor supplied updates from 2.1 and 2.2 to a newer version of android is probably 90%.
It's not in the OEM's interest - they'd rather have you buy a new phone and put more money in their pockets rather than support what's already out there.
Witness the gnashing of teeth every time a new version of Android comes out, and devices X/Y/Z don't get a manufacturer update.
Thankfully there are 3rd parties doing custom ROM's for these, but that's not a solution for the layperson...
The situation has changed in the last year or two. Especially since Sony Ericsson and Dell took such a beating for shipping old OS releases and refusing to offer quick upgrades. The only new devices on 2.1 which I don't know to have a clear upgrade path to 2.2 are the HTC Legend and Wildfire. And an upgrade is rumoured to be in the works for those too. It has become clear to the manufacturers that OS releases are something that matter. I am optimistic about the future of these devices.
The HTC Hero and Samsung Moment (both Sprint) are EOL as of July 2010. No 2.2 or future upgrades for those devices. I expect this to continue with future phones. I've had a Sprint store employee basically tell me that they expect you to get a new phone every two years because things change so rapidly. But I just got my phone in May. So two months later, no new upgrades.
Fragmentation, in this case, is the result of an unmanageable amount of choices. There's a happy medium here, and I don't think the number of different Android handsets is anywhere near it.
It will be interesting to see whether subsequent versions of Android will be able to drive similar adoption rates.
I work, lets say on the handset production side of things, and my impression is that the major driver for Froyo take up from handset vendors was the promise of Flash support.
Gingerbread and/or Honeycomb might offer better support for large screen devices (pads), but apart from slightly less bed Flash video support (via Stagevideo) it's not clear that these releases will have the same pull as Froyo.
On the fragmentation side of things, I find the debate rather strange and strained. Ignoring that the debate is probably between fanboys rather than developers, those developers have some obvious strategies they can take.
They can become or remain Apple specialists and sit in a comfortable, superior but cloistered ecosystem. Alternatively, embrace other platforms in a manner which specifically suits your application, its audience and implementation.
The pros and cons are equally obvious for either strategy. I'd say at least if you choose to stay solely on Apple, I think this will definitely remain a strong platform for the near future. However, there's no point resenting that it is likely that the iOS platform (in the handset space) is unlikely to grow much relative to other platforms. But.. of course it may not matter to you.
Yeah, that fragmentation will definitely be the downfall of Android, just like the multiple Windows versions and thousands of hardware configurations for Windows machines killed the Windows software market. And don't forget websites! Such a shame the web died because web developers had to test against multiple browsers and browser versions.
... In other words, fragmentation is probably the silliest arguments that fanboys can come up with at this point. God forbid developers have to test against multiple configurations like damn near every other software market in existence. There is no free lunch, and added testing time is just the small price you have to pay for a non-walled garden approach.
What about the mention of how long it took for 2.1 and 2.2 to actually roll out, after their official releases? I know in Canada, we were delayed for several months as Rogers and Telus took their sweet time pushing the upgrade from 1.6 to 2.1...
Sure you may say "77% of devices run the latest versions" but you may be in the situation where "0% of the devices in your country run the latest version" because your carrier isn't updating the OS.
The OS version and device format fragmentation is a bit of a red herring. Now admittedly, I've only developed a few simple apps for Android, but the framework really handled all of the differences between screen sizes, etc. for you.
IMHO a bigger handycap for Android is the fragmentation of the end user experience. With iOS, you can by an iPhone, and iPod touch, and an iPad and they'll all have an identical UI. And when you upgrade to the next model of any of the three, you can count on still have a consistent UI and an easy, simple upgrade.
Unfortunately with Android, moving from one Android device to another might involve significant UI changes. Compounding that is that none of the non-phone Android devices currently have access to the Android market, so you don't readily have access to all of your apps across all of your Android devices.
40 comments
[ 2.9 ms ] story [ 105 ms ] thread"Google’s data could be skewed. It is entirely possible that users with older devices simply don’t access the Market as often because the apps they want aren’t compatible with older versions of Android."
This may be true but as a developer you're really only interested in your actual, addressable market and that includes only the people who in fact visit the app store.
So while it may be wrong to say that "77% of all Android devices run 2.1 or 2.2" it's true to say that 77% of your market as a developer runs 2.1 or 2.2.
And from a fragmentation point of view, that's what counts.
77% of devices accessing the App Market are 2.1 or 2.2. But what percentage of all devices sold are actually 2.1 or 2.2? Depending on that number, the size of the actual reachable market could be much lower than the installed base of all Android devices.
There are about 80 different Android smartphones that have been released according to Wikipedia. That is more than what RIM have released in the last 15 years, including their pagers and carrier-specific versions, and a lot more than the 4 iPhones and 5 webOS smartphones.
I can't speak much about consumer-side of things, but as a developer, I can tell you that developing for iOS and webOS is easier and cheaper because there are less devices. I test on every iOS and webOS device, but on less than 10% of the available Android devices, because of the cost caused by so many devices.
One thing to worry about though, is that it is possible that different hardware uses different drivers. I've read about one game that did run very poor on a particular Samsung device, because the OpenGL driver had a bug or missing feature.
The framework does a pretty good job for abstracting the different capabilities and supporting different hardware (on a phone). When manufacturers produce buggy hardware drivers, that's where you need to dig deep.
I'm reminded of that saying:
"In theory, there is no difference between theory and practice. In practice, there always is."
I was doing iPhone development back when there was only 2 generations of iPod Touch and 1 generation of iPhone. In theory, they ran the same platform. In practice, there were several subtle differences between the hardware capabilities and resources on each permutation -- and that was assuming you were running the exact same OS version, which, in the wild, is not always true. A game that looked and worked perfectly on say my iPhone would have a weird glitch on a Touch. And so it had to be tested and tweaked to run well on each. Since then, they've added several more hardware generations of Touch and iPhone, and now also the iPad, and now there are more OS versions in the wild too. Yes, thankfully, Apple allows you to build your app so it officially only supports a narrow subset of these platform permutations. But in practice, your clients/employers often want you to support a wider set. Re-enter fragmentation pain. And this is in the iOS ecosystem, which should be less fragmented than Android.
As you are talking about games, i can imagine that this is much harder on Android as you can't rely on the built-in UI-Framework and have to handle different resolutions yourself.
Alsa support on Samsung devices is also buggy, resulting in problems with various apps, especially sip clients.
Any other questions?
The difference with keyboards - the original point was "all the keyboards" (i.e. HTC IME, Swype, etc), not just hardware vs software. When you prepare your application for software keyboard, whether pan-and-scan or resize, it will just work with hardware keyboard (opposite is slightly more complicated: when you assume only hardware keyboard, then the software keyboard has surprises in layouts for you).
Getting OT: sometimes I wonder, how people could handle PCs 20 years ago. You had CPUs with different speeds (286 to 486), different graphics cards with different resolutions (EGA, VGA, SVGA), operating system that didn't abstract the differences and yet the PC was considered single platform, much more successful than competing unified platforms. There wasn't rampart rationalization against "fragmentation", like today.
We had the turbo button back then. Maybe we need a turbo button on the Android. You could call it the "Anti-Frag" button.
</facetiousness>
They didn't. That's why the Mac was a runaway success and the fragmented PC marketplace floundered.
I think, this is not completely true: http://news.ycombinator.com/item?id=1860578
Different keyboards lead to different users experience with application.
And please don't make blanket statements like this unless you have data to back it up:
>Users looking for an "open" experience are expecting free/cheap apps, and are willing to use less perfect free/cheap apps over your perfected "expensive" one
Anybody would rather use a free/cheap app rather than an expensive one. I don't know that FOSS users are any different in this regard.
Edit: Remember Marco Arment's "Two App Stores"? The same is true of Android, and any other market.
1) Of course the data is skewed! Please don't use a headline only to correctly question its content in the last sentence.
2) Fragmentation hits at two, largely orthogonal levels - there are different versions of the base OS (1.6, 2.1, 2.2) as well as different top-level UIs/distributions (HTC Sense, Samsung stuff, stock Android). The fragmentation problem would persist even if 100% of all accesses came from 2.2 devices. This is equivalent to claiming that Linux is a unified platform because 77% of all google.com visitors use the same kernel.
3) Don't forget the hardware problem. iOS and webOS aren't perfect in that respect, but comparatively harmless.
The less spin-laden headline would be: "What fragmentation? 36% of devices run Android 2.2."
It's not in the OEM's interest - they'd rather have you buy a new phone and put more money in their pockets rather than support what's already out there.
Witness the gnashing of teeth every time a new version of Android comes out, and devices X/Y/Z don't get a manufacturer update.
Thankfully there are 3rd parties doing custom ROM's for these, but that's not a solution for the layperson...
I work, lets say on the handset production side of things, and my impression is that the major driver for Froyo take up from handset vendors was the promise of Flash support.
Gingerbread and/or Honeycomb might offer better support for large screen devices (pads), but apart from slightly less bed Flash video support (via Stagevideo) it's not clear that these releases will have the same pull as Froyo.
On the fragmentation side of things, I find the debate rather strange and strained. Ignoring that the debate is probably between fanboys rather than developers, those developers have some obvious strategies they can take.
They can become or remain Apple specialists and sit in a comfortable, superior but cloistered ecosystem. Alternatively, embrace other platforms in a manner which specifically suits your application, its audience and implementation.
The pros and cons are equally obvious for either strategy. I'd say at least if you choose to stay solely on Apple, I think this will definitely remain a strong platform for the near future. However, there's no point resenting that it is likely that the iOS platform (in the handset space) is unlikely to grow much relative to other platforms. But.. of course it may not matter to you.
... In other words, fragmentation is probably the silliest arguments that fanboys can come up with at this point. God forbid developers have to test against multiple configurations like damn near every other software market in existence. There is no free lunch, and added testing time is just the small price you have to pay for a non-walled garden approach.
Sure you may say "77% of devices run the latest versions" but you may be in the situation where "0% of the devices in your country run the latest version" because your carrier isn't updating the OS.
That's the fragmentation I'm afraid of.
IMHO a bigger handycap for Android is the fragmentation of the end user experience. With iOS, you can by an iPhone, and iPod touch, and an iPad and they'll all have an identical UI. And when you upgrade to the next model of any of the three, you can count on still have a consistent UI and an easy, simple upgrade.
Unfortunately with Android, moving from one Android device to another might involve significant UI changes. Compounding that is that none of the non-phone Android devices currently have access to the Android market, so you don't readily have access to all of your apps across all of your Android devices.