The march of technological progress can only be described as relentless, yet the road to bringing new technology to market often takes far longer than it should. IE6 may be a quintessential example, but this is a story that continues to be retold.
Internet Explorer 6 was released in late August of 2001. Originally developed for and shipped with Windows XP, IE6 was ultimately made available across a wide swath of Microsoft’s operating systems, from Windows NT 4.0 and Windows 98 through Windows 2000. Its successor, IE7, was released just over five years later in October of 2006, but it was not until 2011 that most web developers began feeling truly comfortable dropping IE6 support. Even today, well over a decade after its initial release, Microsoft continues to support IE6 on PCs running Windows XP Service Pack 3. That OS — and IE6 with it — will not enter “end of life” until 2014. Developers have spent countless man-hours supporting this antiquated piece of software, which has managed to maintain non-trivial market share even a decade after its release.
While many consumers are aware that newer versions of the software they use are available, there is a critical lack of information about how the process works and what benefits exist for the user. Today’s best example of this is Android.
How Android is Released
Despite being an open source project, Google’s Android operating system is developed in secret. Usually working in partnership with a hardware manufacturer, Google develops a release of Android specifically for the flagship device said manufacturer will put on the market. The source code is usually released alongside or shortly after the flagship’s entry to the market, although this is not a certainty. For example, Google opted to withhold the source code for Android 3.0 “Honeycomb”, claiming it was not ready:
“To make our schedule to ship the tablet, we made some design tradeoffs,” says Andy Rubin, vice-president for engineering at Google and head of its Android group. “We didn’t want to think about what it would take for the same software to run on phones. It would have required a lot of additional resources and extended our schedule beyond what we thought was reasonable. So we took a shortcut.”
It is only when the source code is made available that other manufacturers are able to start the process of retrofitting it to work on previously released and upcoming devices. This process can be very costly for manufacturers, with many opting only to upgrade specific older devices. In general, there is little economic incentive for manufacturers to upgrade old hardware, as doing so only extends its usable life, which in turn disincentivizes consumers from purchasing something new. The end result is that it can take months for Android users to see upgrades, if they see them at all.
Consistent and timely updates offer many benefits for consumers. Many of the updates that go into an operating system are bug and security fixes that directly impact user experience and safety. Others add new functionality or improve what was originally provided. Manufacturers who choose to skip these updates will often find that consumers go elsewhere when their contracts are up. There is no better proof of this than Apple’s line of iOS devices, where a user may choose to hold onto an aging device rather than upgrade. Ensuring that user’s satisfaction all but guarantees that her next device will carry an Apple logo.
The Problem of Choice
Today, developing for Android can be a daunting task, as software engineers attempt to build apps that can work in a variety of different environments. Here are just a few of the things an Android developer must consider:
- What is the physical size of the screen and what is its resolution? (The Motorola Xoom tablet has a 10.1” display at a screen resolution of 1280x800. The Samsung Galaxy Nexus smartphone has a 4.65” display with a resolution of 1280x720.)
- Is the screen a touch screen? (Android was not originally developed to be a touch-centric OS.)
- Does the device have a physical keyboard? (Some devices have built-in keyboards, which mandate the support for horizontal orientations in apps. In contrast, many iPhone apps only work in portrait mode, as developers can assume there is no physical keyboard.)
- What are the performance metrics of the device? (How fast is the CPU? How many “cores” does it have? How much RAM does it have? How powerful are its graphics capabilities?)
- Does it support location services? (Does it use a real GPS chip, or is it assisted? The quality of the sensor and its integration can vary.)
- What sensors does it have? (While Android includes support for a wide array of sensors like accelerometer, gyroscope, and more, the Android specification does not mandate any minimums for the hardware.)
Aside from the specifics of the hardware, the primary consideration is what version of the OS is being used. According to Google, more than 60% of Android users are running some version of Android 2.3 Gingerbread released in late 2010. Another 20% are using the previous version (2.2 Froyo) released earlier that year. Just eight percent of Android users are on a version newer than Gingerbread. In practice, this means that developers must “target” older versions of Android to ensure their apps can run on the widest assortment of devices. While Android has matured into an impressive operating system with many advanced capabilities other mobile operating systems have yet to match, developers often must forego using the latest tools because older devices don’t support them.
The net effect is that Android usage appears to follow the two-year contract cycle dictated by mobile carriers. Android 4.0 Ice Cream Sandwich (ICS) was released late in 2011, but it has taken the first half of 2012 for device manufacturers to ready devices running the new OS. By the end of the year most or all new Android smartphones will be running ICS, just in time for those customers who signed contracts in 2010 to upgrade. I expect we will see another two-year period during which ICS becomes the dominant version of Android, and those releases that follow it will garner relatively little adoption until 2014, when contracts again expire. This cycle started with the release of the T-Mobile G1, the first Android phone, in 2008. The stickiness of particular versions of Android seems to shift every couple years to whichever version of Android was released the year prior. While consumers are swimming in options when choosing an Android device, manufacturers have limited their ability to acquire the latest and greatest software. Apple avoids this issue by developing both hardware and software in parallel, essentially under the same roof.
Mitigating the Problem
Google has done an admirable job of assisting app developers working with Android. The Android Compatibility Support Package adds some features from newer releases of Android that developers can add to projects targeting older devices, enabling the use of some newer functionality as well as some facilities not provided at all. Unfortunately, the package isn’t an exact fit, and subtle differences exist between what is offered in the package and what is available in the “stock” platform.
At the Google IO conference in 2010, Google announced the Android Update Initiative, with manufacturers committing to “timely” operating system updates for at least 18 months following the release of a new device. At the time relatively few details were made available, and unfortunately now — two years later — it appears that the initiative has not had as much of an impact as was hoped. We hold out hope that the initiative will gain traction, but this remains to be seen. Google could begin placing more stringent controls around the process, but would risk alienating its hardware partners in the process. Of course, with Google’s recently approved acquisition of Motorola Mobility, we may see Google leading the charge to bring the best Android devices directly to market under its own brand.
Compared to iOS
iOS suffers from some of the fragmentation issues that currently plague Android, but the number of concerns are reduced and their severity is greatly diminished. iOS app developers have only four screen resolutions of concern (480x320 and 960x640 for iPhone and iPod touch, 1024x768 and 2048x1536 for iPad) across two screen sizes: 3.5” and 9.7” diagonal. Apple has made software upgradeability a cornerstone of the iOS platform, and the three year old iPhone 3GS from 2009 can run iOS 5.1 — the latest version of iOS currently available. While there are differences in the underlying hardware and some features are not available across all devices, developers are generally in a much better position to support the latest and greatest features. iOS 5 adoption has been stellar, and this looks to continue with the addition of over-the-air (OTA) updates of the OS itself.
Full Steam Ahead
While Android presents its own set of challenges for software developers, the reality is that even 2010’s Gingerbread is a powerful operating system that has kept many millions of users happy worldwide. While Android’s open source nature brings with it certain drawbacks, the fact it is open source has allowed it to become so widespread. There was clearly a market opportunity for such an operating system, and without it we would likely be living with a mobile device market not unlike the MP3 player market of the first decade of the 21st century: dominated by one company with a small assortment of products. While Apple’s products are rightfully regarded as some of the best available, the truth is the market needs competition to thrive. No single device or even series of devices can truly fit all needs.
Building apps for Android can be a rewarding experience for developer and client alike, and building for both iOS and Android is essential to reaching the greatest number of post-PC consumers. More important than any version of an operating system or particular piece of hardware is a firm understanding of the strengths of the platform, why people choose it, and what can be accomplished with the tools at hand.