+Phil Nickinson gives the best rebuttal yet of the ridiculous Android fragmentation… 7


+Phil Nickinson gives the best rebuttal yet of the ridiculous Android fragmentation chart published by +Michael DeGusta the other day.

As flawed the chart is, even Phil missed one of the most egregious errors of the chart is the indication that all generations of the iPhone have been updated to the current software which is absolutely untrue. In fact the first gen iPhone was cut off from updates when iOS 4 was released 16 months ago. The iOS 5 compatibility chart on the Apple website http://www.apple.com/ios/features.html shows that the 3G and the first two generations of the iPod Touch are no longer capable of running iOS5 and as Phil accurately points out, the 3GS and 4 are incapable of running several iOS5 features such as Siri.

Embedded Link

Editorial: Fun with ‘fragmentation’ charts (or, why you shouldn’t be distracted by shiny objects) | Android Central
This is not a good chart Let’s not mince words here: This “Android and iPhone Update History” chart is not a good chart. Oh, it’s a pretty chart, to be sure artfully illustrated and researched.

Google+: View post on Google+

Post imported by Google+Blog. Created By Daniel Treadwell.


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

7 thoughts on “+Phil Nickinson gives the best rebuttal yet of the ridiculous Android fragmentation…

  • Michael Leahy

    I'm a fully committed Android dev that has worked with Android intimately since v1.0 and orphaning is a major problem for devs who wish to create performance oriented apps & games that reach as many devices as possible. Besides payment for exclusives by Sony / Nvidia there is a reason most decent new games focus on the latest SoCs / OS releases. A fair amount of them could have wider releases. That is mainly because "real fragmentation" is the snowball of bugs, defects, and regressions in the SDK (software development kit) itself that are introduced and then sometimes subsequently fixed at each OS / API level. When there is such a large spread of orphaned devices each running a different OS version a multitude of workarounds are necessary to overcome the SDK deficiencies.

    The chart doesn't imply that the original iPhone is going to get iOS 4 or 5. It states that the iPhone got OS updates for 3 years ('07 to '10). It doesn't say it runs well or has all the features of the latest OS / bundled apps. Thos claims were never made. The iPhone 4 to 4S and Siri aspect is nonsense as that is not fragmentation. The same thing occurs / occurred with Android. What this chart shows is OS differentiation. There is no real problem with OS differentiation per se as it can be sanely dealt with except for the Android teams poor quality at times releases (tell me an OS version and I'll likely be able to list a debilitating bug for real time apps / game dev for that particular version!) which tragically spread out across the entire ecosystem. OS differentiation isn't the problem, but unfortunately "real fragmentation" is never discussed; certainly not by bloggers and tech pundits who don't understand things so deeply.

    Like I said though I'm a die hard Android dev and focus on it exclusively and have worked with every OS release. Device orphaning is a problem when combined with low quality control from the Android team as bugs and regressions remain dispersed across the larger ecosystem. I'm afraid that the chart presented is not inaccurate nor did the author make claims that are inaccurate. The chest puffing from the majority of Android pundits has been funny to watch. Yes Android is different and isn't controlled in a fully intregrated way, but there is nothing inaccurate about device orphaning causing problems at least for devs. If the speculation is correct and LG orphans their flagship G2X on Gingerbread (for US) and it doesn't get ICS that is a clear example of this silliness. That isn't a commodity phone. These devices are not feature phones. They are powerful handheld computers and that they are being neglected by manufacturers and carriers is potentially lame for most users who can't root or install custom ROMS, etc.

  • Dennis D. McDonald

    +Michael Leahy I think the phenomena you describe are inevitable given the decentralized nature of the communities responsible for Android development and the variations in hardware platforms introduced competitively by so many users. Such decentralization gives rise to many opportunities for innovation but also creates challenges for commercialization. Apple's more centralized (dictatorial?) approach may reduce opportunities for innovation but also guarantees a more stable platform for developers.

    It will be interesting to see how Siri develops and is integrated into different apps on the iOS platform. If I wanted to proliferate the adoption of a potentially game-changing approach to interactivity such as Siri offers and I wanted developers to adopt and experiment as much as possible, I would definitely prefer the more controlled environment that Apple provides.

    I am reminded of the days when software developers had to write hardware drivers for various printers, network adapters, and display devices. Microsoft finally got this under control for the most part by promoting windows interface standards. Will Google have to do the same given the proliferation of Android platforms?

  • Frann Leach

    It's not possible for software to be completely downwards compatible if the hardware is updated to the extent possible. You can make software that is downwards compatible if you never update the current hardware beyond a certain point – but who would buy it then?

  • Michael Leahy

    +Dennis D. McDonald Indeed.. I wouldn't trade the decentralization aspects of Android for a dictatorial as you say walled garden any day. Certain design decisions and lack of full quality testing / vetting of various Android releases is annoying. Unless you were there and worked with a given OS version as a dev likely you will not have time to find these problems and thus are forced to focus only on new devices or whenever the dev picked up their first one. I mention on device testing necessary for OpenGL ES / low level stuff as the emulator doesn't cut it.

    Dennis:
    >Such decentralization gives rise to many opportunities for innovation but also creates challenges for commercialization.

    I did leave out my "bias" point. What I've been working on for the past 3 years over all OS releases is a middleware platform called TyphonRT that I started porting over from J2SE / desktop when the G1 hit my hands that rolls in all of the fixes required to release performance oriented apps / games across the entire ecosystem / all OSes 1.5+. At the same time apps run on the desktop and Android from one codebase. It's kind of been a little hellish really on the Android front because of device orphaning, but it's caused me to take my software architecture skills up another level and innovate on directions I thought neat before Android, but now there is a real reason to go where I headed; I now have a real problem to solve for that technical itch. I am aiming to get my efforts out soon and it has been a journey thus far and is time consuming. I do hope ICS is a pure / good release with high quality.

    +Frann Leach I disagree though at least for real time app / game dev. Sure one has to make some decisions on low level support such as OpenGL ES 2.x usage as that will get rid of some of the early 1st gen devices (Hero / G1), but the original Droid supports it and most devices forward. I'm still effectively working with OS 1.5 / API level 3 as the base for my middleware and it runs on every device (or should I don't own 200+ after all!) There are software architecture techniques that I'm exploring / implementing that makes it possible to provide device or OS specific workarounds seamlessly while providing a consistent API / middleware layer that just works as opposed to the minefield devs face coding directly to the Android SDK if they wish to release a performance bound app across the ecosystem on the latest devices and reaching deep into the long tail.

  • Michael Leahy

    +Frann Leach ahh.. No, but I see a bit more where you are coming from though in your previous comment. I have nothing to do with the OS releases and yes there may be some issues with ICS running on Milestone though I understand that given a little effort you can install Gingerbread on it yourself. There is a whole category of Android enthusiasts, devs, and hackers who work full time on porting various newer OS versions to old and new devices alike. It'll be interesting to see what devices get ICS through the 3rd party scene.

    http://www.xda-developers.com/android/motorola-milestone-joins-the-gingerbread-gang/

    My efforts are specifically targeted at app level developers and not the OS itself. What I'm working on is called middleware. Essentially it's a layer of software that sits in between the OS and apps that run on top of the middleware. It's a category of tool / software for app devs to use to be able to write to a consistent and less buggy layer of software than the raw OS / Android SDK which varies greatly in quality and API features over the larger ecosystem. You can kind of picture it as if in the graph above if you overlaid a transparent layer / filled in box and it happened to be able to turn most of those devices to "green"; in as much as my efforts make it possible to create highly portable performance based apps.

    My main point is that OS differentiation only becomes a real problem when combined with serious bugs / defects that are introduced with each OS and a given device is orphaned. It would be interesting to see a graph with the OS differentiation with an overlay of serious dev issues and believe me it would get a lot more red than it is presently. With the large amount of different devices out there there are many orphaned on each OS level / release. Unfortunately the Android team hasn't had the best track record in catching serious bugs before they ship; I honestly hope they improve and take more time. Android is not a web app and despite the amount of smart folks working on Android it's being developed in a shooting from the hip engineering style more appropriate for web apps (Google's forte) than OSes. I'm not doubting the complexity of the task per se, but a lot of serious defects made it out to the wild that could have been caught with moderate testing. It's obvious which OS is the front runner now, so focusing on quality over shipping quickly is a better management strategy at this point; Honeycomb was a disaster! When devices are orphaned they remain active with these bugs / defects thus making it harder for devs to create apps that work well across the larger ecosystem.