I've found that the much more annoying and difficult to deal with fragmentation bugs are carrier specific. You will find things like Samsung has changed how you launch the default browser from your app or HTC doesn't follow the spec for getting an image from the camera. These are the kind of bugs that drive me crazy.
My current project runs a test suite (as well as some light adhoc testing) on 6-7 devices (across screen densities and carriers) and that seems to catch most of the issues without spending $20k on a device lab. (We use the excellent Spoon library by Square: http://square.github.io/spoon/)
Screen sizes are not an issue for anyone that's shipped a non-toy app. API levels are not so bad - though you will find yourself using the Support Libraries even in cases when they shouldn't be needed.
BTW: Android provides a weekly report of OS/screen sizes etc that access the Play Store: http://developer.android.com/about/dashboards/index.html Use this (not a random blog post) to make informed decisions for your clients on your minSdkVersion.
Now if you want to talk about a real headache for Android developers, let's talk about Fragments - not fragmentation :)
Many comments here can be summed to “I am frustrated because Android is fragmented and I may not be able to target all one+ billion android devices if I code for a week”.
No problem here though, if you think 1+ billion users don't deserve a few dev hours, you may as well code for another platform. Same goes if you think targeting anything less that 1+ billion users is problematic.
As far as OS version fragmentation, iOS 6 and Android 2.x are both running on approximately 20% of their respective ecosystems. But for some reason iOS developers are more ruthless in cutting off older devices. I recently convinced a very insistent company to drop Android 2.x support after I pointed out that they had already dropped iOS 6 support without giving it a second thought.
iOS 6 was released fall 2012, the last release of Android 2.x was in 2011. A better comparison would be Android 4.1 Jelly Bean to iOS 6 - that's 35% of the android base on ancient versions (pre 4.1, relative to iOS's 4%)
I still maintain that fragmentation is less of an issue than is commonly believed...I think the biggest problem is that unless your app is relatively new, you probably have to continue supporting Android 2.3. Making sure your app works on that ugly, buggy OS is a massive pain.
I gripe about having to support an OS that Apple shipped in Q3 2012. Semi-mandatory Android 2.3 support is a fragmentation problem, especially when you mix in all the crazy shit some handset makers and carriers have done to 'improve' Android.
>Semi-mandatory Android 2.3 support is a fragmentation problem
Only for spoiled iOS developers.
I used to develop for Windows, starting in pre-1995. Want to talk about fragmentation? With dozens of video cards, each with their own custom APIs for doing anything that standard VGA couldn't handle, dozens of sound cards with varying levels of support for the de facto standard(s), memory configurations from 128k through multiple megabytes, BIOS variations, and even CPU bugs in AMD or other non-Intel chips...and then tons of software that might be running on top of your app (drivers and such)? THAT was fragmentation.
Windows 95 and later (specifically after DirectX was introduced) reduced THOSE problems significantly, but new ones surfaced, anti-virus and firewall packages being the worst, though some video cards still have bugs that break things randomly.
You think having to support 2.3 qualifies as a problem? JUST having to support 2.3 is a dream compared to what we used to have to deal with. The compatibility libraries -- especially the latest versions -- do a great job of making apps work everywhere. And if you're using OpenGL, you have even fewer compatibility issues to worry about.
From my point of view its management handling thats my issue. When I say week to update iOS, 3 days on the html version, 3 weeks for android, I get a massive push back... "android in one week".. "OK an extra few days for testing, but we need these out now"
Then I start to get really annoyed at the level of shit of I have to support for Android and the backwards and forwards on testing and just seriously wish the company didn't support it all.
Actually TBH, I only took up looking after the mobile suite as a learning thing. And what I learnt is I'd rather be doing other forms of software (almost exclusively due to time pressures and android). The experience has been less rewarding that other forms of development I've done.
I'd never work on Android products again without a proper team (project manager, QA etc...) so someone else could fight the battle of more development time every iteration instead of me.
With a TAM measuring in the hundreds of millions of devices for each platform, I'd much rather work with the one that requires less self-flagellation. But, to each their own :)
The people who point out "90% of Apple iPhone users are on the latest OS version! Android sucks because not everyone is on the latest OS!" don't realize (or care) that Apple just bundles up a bunch of userland components and calls it an OS update. Nearly everything but the kernel is auto-updated to the latest version on all Android devices, even if they're several OS versions behind.
The discussion should be around "What is it that people without the latest hardware / OS version can't do?" not "What number does your phone say under OS version?"
If almost everything is auto-updated, why do developers need to test against old API levels? Wouldn't the frameworks be updated as well? Or are the frameworks covered by the "nearly" qualifier?
Wait some bugs are security issues and cant be patched unless a full upgrade is performed so no the discussion is how do we keep people protected when they cannot upgrade the phone. I apologize if I am missing something but it my understanding Android relies on the carriers to push the updates, correct?
Around our shop (we have several PhoneGap projects) we frequently refer to Android browser as the IE of mobile. (and we're referring to IE6-8). Its crazy how many really key parts of HTML & CSS don't work on various versions of Android browser that are still very much alive and well, including some that worked on 2.3 and stopped working on 4.0 or 4.1. We basically have to turn our apps into static pages for anything < Android 4.2.
I think a subtle problem with the android fragmentation is that it is not going to get any better. As time goes on there will be more devices running more android versions.
While Google's cheap handset initiative embodied in Nexus 5 will ameliorate problem a bit by giving people incentive to upgrade, it is not nearly enough. I would like to see Google do more to address growing complexity of fragmentation.
I do not dispute that. I agree that it is a manageable situation. What I was pointing out is sheer scale of it. Given enough effort it is certainly possible to make any app to work on all android platforms. However, there are millions of apps in the play store and it is not possible to make them all to work on every device. I just think Google should be actively working to make that task easier on developers. For example getting cloud emulators or even physical devices available to developers for testing their apps against with automated framework.
I agree that in general situations are quite similar, however there are few differences:
1. PC never had a singular point of access to nearly all available applications. Play store makes it easy to download/install or distribute a new application making it instantly available to large amount of people.
2. It is fairly easy following a tutorial to create a new mobile app. This combined with 1 makes it easy even for relatively inexperienced people to make apps that reach wide audience.
3. Rigidity of mobile environment. On PC if something goes wrong you have a chance to figure it out and correct a problem. This is much harder on mobile, often times only thing you could do is complain to the developer.
4. No POSIX. On PC if you need an app to work across a wide array of software and hardware configurations POSIX got your back. Granted, this is a weaker point because it would work only on a limited set of operating systems that are POSIX compatible.
5. You can install almost any app from play store on nearly any android device. You can't install mac os app on windows.
It's not. Except Windows has 95% of the market and the Mac had 5% of the market. So even though it's easier and cheaper to support a Mac app, the market is so much smaller it's still not really worth it.
Compare to mobile where iOS market place was leading, it didn't make a lot of sense to spend more effort on the smaller market.
Now the Android market is about equal, you are still spending more effort to make the same money.
The problem is the hardware AND software targets for mobile devices is still growing and evolving rapidly.
Rapid, very different hardware variants- Screen size, cpu power, GPU power, storage mechanisms. Software: 3d Apis, third party Apis, if you want to take advantage of a new framework you may not be able to because of people either unwilling to, or not able to upgrade.
I think the main issue with fragmentation is dealing with 2.3 (as the article mentions). Now that that's going away it's getting much better very soon so I can't agree that "it is not going to get any better". The latest Android project I'm working on will only work for ICS and newer and I've had very few cross-platform issues (two minor issues that I can think of).
If you have used Android's Camera APIs, you would know how bad the fragmentation is. Had to fix various framerate/preview size issues on many Samsung S3/S2 variants because Samsung have their own private camera parameters when you don't use the default MediaRecorder and just try to process the frames yourself. (I work on recording for Vine)
I still haven't popped my mobile development cherry because of how fragmented the development experience is on a few levels. One, the pain of having to develop twice for iOS and Android and Blackberry (if someone requests it). Two, the pain that comes with fragmentation in each specific platform with Android being the worst.
Because the app store is a race to the bottom, I don't want to create an Android app that works well only on the latest devices and have someone else copy it and make it available for all other platforms. This fear is enough to keep me from executing any ideas on the mobile platform.
I still focus on web applications and HTML5 because eventually everyone will be on a phone powerful enough to use it.
I have been looking at Intel XDK, I think it hits my pain points.
PhoneGap I'm not so sure about because people seem to be walking away from it and writing native applications instead because they were frustrated by performance. Now, I'm sure there's success story.
My current project runs a test suite (as well as some light adhoc testing) on 6-7 devices (across screen densities and carriers) and that seems to catch most of the issues without spending $20k on a device lab. (We use the excellent Spoon library by Square: http://square.github.io/spoon/)
Screen sizes are not an issue for anyone that's shipped a non-toy app. API levels are not so bad - though you will find yourself using the Support Libraries even in cases when they shouldn't be needed.
BTW: Android provides a weekly report of OS/screen sizes etc that access the Play Store: http://developer.android.com/about/dashboards/index.html Use this (not a random blog post) to make informed decisions for your clients on your minSdkVersion.
Now if you want to talk about a real headache for Android developers, let's talk about Fragments - not fragmentation :)