Tuesday, November 17, 2009

Is Android a "Tower of Babel" OS?

That's the question I'm thinking about after reading an in-depth and excellent 3 part series of articles titled Inside Google's Android and Apple's iPhone OS. 

The series analyzes the Android OS and how it compares to and contrasts with Apple's iPhone OS in three main areas. The first article is a comparison of the OS's as core platforms. The second article compares the business models Google and Apple are implementing for their mobile OS platforms. The final article looks at how each platform manages software updates and delivers platform advancement in the form of new operating system features and bundled apps. If you want a deep analysis of both platforms in these areas and have some time to dig in, the author 'Prince McLean' does an excellent job of covering a lot of ground. 
  
The biggest takeaway from the series for me was the many ways each Android handset maker is going to be able to make custom modifications and changes to Android. Each vendor is naturally going to try and make the end user experience the most attractive it can. This means user experience from one Android device to the next could be VERY different. Now on the surface that sounds great! More choice for consumer's is always a great thing, right? On the surface that IS true.  

But there is a devil in the details underneath the variability of the flying windows on your Android handset. That devil is the difficulty this creates for SW application developers to develop Android apps that run across many devices on all the different variations of Android deployed on all the various devices from competing vendors. The testing permutations will boggle the mind of even the best mobile app development company. Developers have been promised "write once, run anywhere" many times in the past and every time it's ended in a mess. No matter what Google promises I'm pretty certain the Android model will not achieve, "Write once, run anywhere."  

Imagine trying to manage your 4 or 14 mobile apps you've written for mobile phones when there are 20, or 50, different Android handsets from a dozen different handset vendors and you have to test and certify that app to run on all 50 devices? Then imagine having to retest on every device every time an OS update gets pushed from Google. Then you have to retest and certify AGAIN every time the handset vendor issues it's layer of changes on top of the latest Google Android release.

Now compare this to the effort for the iPhone App developer of retesting and re-certifying each time Apple issues an iPhone OS update. Then take into account the likelihood that Apple is going to move away from it's ATT exclusive and sell through other US vendors and all the major global vendors. As an App Developer, whether you love Apple or hate them, you'll have to think hard about how you spread your limited SW development resources between iPhone and Android.  In the long run is it sustainable from a business perspective for the mobile app developer to take on the headaches building and scaling the Android "Tower"?


This devil has the potential to make the Android community suffer the same fate the builders of the Tower of Babel suffered in trying to build a tower that reached the heavens. There may be just too many Android "languages/dialects" to effectively sustain a combined effort to disrupt and compete with Apple's "iPhone Hegemony".

I'm a big believer in the benefits of competition for consumers and for the businesses who are competing. So I hope Android is a success. That success, if it happens, will certainly drive innovation forward and improve the health of the industry as a whole.

But to do that Google and it's vendor partners must do something to make sure App Development for Android is not going to be a mess? If they don't, SW Developers are going to feel like they are SW developer versions of Bill Murray in "GroundHog Day"; redoing the same SW tests over and over and over and never getting it right? Am I missing something here? I'm curious to hear what people think.
blog comments powered by Disqus
There was an error in this gadget