How Android developers can avoid the fragmentation blues

If there is one common thread amongst developers of all platforms (mobile and non-mobile) it is that they like to complain. I’m not talking little grumbles that get spoken under their breath but loud, obnoxious, over-the-top rants. This manifests in copious blog posts and conference talks that rail upon OEMs, hardware vendors, software tools and operating systems for “making their lives harder”. The pet peeve for mobile developers has, and always will be, fragmentation in whichever market they are developing in.

Recently, there has been quite a bit of fragmentation news for Android developers. There’s the rumoured possibility that Android OS 5.0 might launch as early as this Fall, which comes at a time when less than 2% of Android smartphones are running Android OS 4.0. Compounding this data is a new model that shows that 2012 will be the year of Gingerbread from an OS penetration standpoint, regardless of what happens with Ice Cream Sandwich or Jelly Bean. With potentially three major OS versions requiring support in one year, how bad is Android fragmentation for developers?

Back in the day

To answer that question, let’s put Android development in context of the history of mobile development. In the “old” days of J2ME/MIDP mobile development, phones were as different as you could imagine, with every combination of features, screen sizes and keyboards known to man. Even the implementations of “standards” varied between manufacturers and devices. Fortunately, phones had such a short lifespan that the manufacturers basically never updated the OS on the devices. The hardware was designed for a specific operating system version and the device was never updated with a new one. The benefits for developers here was that once you got your game or app working on a device, you only had to modify the code for that device if you found a bug in your game/app.

When BlackBerry launched and started the smartphone revolution, this model of building hardware and software in tandom was modified slightly. New BlackBerry OS versions were developed in concert with the launch of new devices, however, frequently the OS was updated to support older devices. This meant that you had devices that could be running different versions of the OS depending on when the BlackBerry was purchased or if the user of the device had upgraded their OS.

This introduced the need for BlackBerry developers to make updates to their software for devices they had already supported. In addition to dealing with multiple types of hardware on the same operating system version, they had to maintain and update the software for older devices as the operating system was upgraded. However, since RIM controlled the hardware and software on BlackBerry, they were able to exert some control upon the process for OS releases and updates. A new device intrinsically had the newest OS on it at launch because the OS was not released until the device was ready. This helped to provide better predicability on the BlackBerry device ecosystem, but there was still a lot of post-release maintenance work for developers to support devices that upgraded their OS.

Apple improved upon the BlackBerry model of controlling the hardware and software and has limited fragmentation by limiting the number of devices they launch to one phone and one tablet per year. They also work hard to make it clear when a new OS is available for older devices and easy for users to upgrade. This makes iOS development easier in both core app development and maintenance when trying to cover the majority of the iOS devices in the marketplace.

Android: the worst of both worlds

Android has absorbed the worst of all of these models:

    * Hardware and software are not controlled by the same company.
    * The OS and the hardware are not developed in concert with each other.
    * Older devices can upgrade to new OSes, but OEMs are not incentivized to encourage this because they don’t make on-going revenue after selling the device (to cover the support costs of providing the OS upgrades).
    * Hardware is not standardized because individual OEMs want to provide unique selling features for their phones.

The result of this model is the perception that Android development is a huge problem because everyone wants to use the latest and greatest features of the device in their products.The reality, however, is that supporting the latest and greatest is not always the best strategy. Think about other industries where the technology evolves quickly but takes time to be adopted by consumers:

    * HDTV: on day one, there was very little HD content available for consumers. Only premium priced content was in HD and it took time for enough HDTVs to be available in the market for content producers to switch to HD as the main production method for their content.
    * 3D TV: how much 3D content do you get on your TV networks? Very little. While the TV manufacturers are pushing it as a selling feature of their products, consumers have not adopted it and demanded the content strongly enough for producers to invest in the content development.
    * 3D Games on Mobile: there have been mobile phones capable of doing 3D for many years but only when the number of 3D-capable phones reached a tipping point of penetration did game developers start producing a lot of 3D games for mobile.

The common thread in all these examples is the need to identify what consumers have, not what the latest and greatest tech is. The announcement of Android 4.0 or 5.0 is basically irrelevant for the short to medium term planning of mobile developers. Mobile applications and games are scheduled in months not years. That means you only need to look about a year out to determine what technology and devices to target.

For Android developers, the most important numbers are that Android 2.2 is 25% of devices in-market and Android 2.3 is 62% of in-market devices. That’s almost 90% of all Android devices. A quick look at the Android phones being shipped in the next 6 months shows that enough of them are still 2.2 or 2.3 that the 90% number isn’t going to drop down to 30% and fragment the market.

The path for Android developers is clear: develop a successful product for the vast majority of Android handsets running 2.2 and 2.3. Once developers have a successful product to leverage, the cost to support additional handsets (maybe the latest and greatest Android phone everyone is buying in droves) will be offset by the revenue generated from those handsets. If it’s not being offset, then STOP: why would you support handsets and OS versions that don’t generate revenue? The goal for any developer is to make money, not get caught up in the ‘latest and greatest’ rat race.

About the author

Jeff Bacon

Jeff Bacon is the Director of Mobile Strategy at bitHeads Inc. He helps companies understand how to best bring their business to mobile and plan execution strategies to maximise the value mobile can bring to any business. You can read more on the bitHeads’ blog: or follow @bitHeads or @TheSuaveHog on Twitter. Check out bitHeads’ mobile portfolio here:

  • Brian Estey

    That’s OS fragmentation but not device fragmentation — there are many different model phones in that 90% you mention with different hardware, from CPU and RAM to GPU and screen-size.

/* ]]> */