Articles in this series:
Android doesn't really compete against the iPhone directly; Android is a flexible platform that can be put to use with a lot of implementation leeway by any company, not a specific product tightly managed by a single company in the way the iPhone is.
However, with the wholesale collapse of nearly every other viable smartphone platform — including the old PalmOS, Linux distros like OpenMoko and GreenPhone, Windows Mobile, and even the leading Symbian — Android has assumed the position as the lead candidate for producing a potential rival to the iPhone, and lots of hardware vendors are hoping to use Android to do just that. New Android phones from HTC, Motorola, and Sony Ericsson are clearly taking aim at the iPhone, each in unique ways.
Comparing specific implementations of Android phones against the iPhone is problematic because Android is only one component of the package. Individual Android-based phones may be exclusively tied to a specific mobile network with different price plans, service coverage, carrier restrictions, or technology limitations that have nothing to do with Android itself. Similarly, different phone manufacturers may have their own design or quality issues, support problems, features or pricing that contribute to or distract from the overall ownership experience but which also don't involve Android itself.
For these reasons, this series will focus exclusively on Android's strengths and weaknesses in comparison to Apple's iPhone as a software platform, rather than being limited to any specific phone model. The issues presented here will broadly apply to all Android phones on the market, as well as those still in production. In addition to the factors presented here, there are lots of issues external to the software platform that users will want to consider when actually choosing a phone.
However, because the core phone platform so deeply impacts usability, expansion options, third party software capacity and feature support, examining the differences will provide a lot of illumination on what kind of experience Android users will have over their phone's lifetime compared to the iPhone. This comparison is analogous to comparing Windows to Mac OS X, rather than the features of a specific Windows PC against a specific Mac model.
Android vs. iPhone: under the surface
The Android or iPhone software platform is more than just a core operating system. And really, the differences in their core operating systems are one of the least important factors to users. Both use a Unix-derived kernel and operating system environment that few users will ever even see. Android phones happen to use a Linux kernel while the iPhone uses the same Mach/BSD Unix kernel as Apple's desktop Macs.
In the big picture, this doesn't really matter much because neither smartphone platform provides any real access to this layer (either to users or developers), and neither phone platform is designed to run desktop software developed for Linux PCs or Macs. Both systems are examples of well regarded technology that is fully capable of supporting the needs of the smartphone environment above the core OS.
The actual platform environment that matters to users on Android and the iPhone exists well above the core operating system kernel. This is where applications run, where security is enforced, and where the business model behind the smartphone impacts what users can and can't do.
Platform environment: Android
Rather than running desktop Linux PC software (which is built using the X11 "X Window System" paired with a window manager like KDE or GNOME) like Nokia's N900 running Maemo Linux, Android supplies a modified Java Virtual Machine similar in many respects to the BlackBerry OS and Symbian phones designed to run Java ME apps. Google has modified Android's Java bytecode interpreter (which it calls Dalvik) to avoid having to pay Sun licensing fees for the official JVM in Android. This enables Google to offer Android for free, and without any interference from Sun. It also effectively makes Android a Java platform, not a Linux platform.
Existing Java ME software is easy to port to Android, which is an advantage both because it makes delivering new third party Android apps easier for developers familiar with mobile Java programming, and because it forces developers to do some minimal porting rather than just make their old Java ME apps available as is. The majority of existing Java ME apps are simple and low quality and can't actually run across the wide range of phones that are supposed to run them. Java ME competes against Adobe's Flash Lite, which is also broadly licensed to phone makers but which, like Java ME, hasn't done much to result in broad availability of quality mobile software.
Sun's mobile Java platform is purported to be a "write once, run everywhere" platform, but in reality it only serves as a lowest common denominator for very minimal functionality. BlackBerry and Symbian users want to obtain software custom designed for their phone OS and model, not a basic generic applet that can potentially run on any phone but which does not take advantage of any special features on any model.
The "run everywhere" premise of Java ME is also complicated by the fact that different phones (even from the same vendor) implement the Java virtual machine differently. This results in user confusion as each app has to be tested and optimized for each new phone model, something that simply hasn't happened. That's why Sun's Java ME platform, despite being touted as "the most ubiquitous application platform for mobile devices across the globe," hasn't resulted in a popular, successful market for smartphone software.
Google has purposely broken compatibility with Java ME to introduce Android's Dalvik alternative as a new development platform that leverages all the developer experience and familiarity of Java, without allowing or intending Android software to run on BlackBerry or Symbian phones. The hope is that Android's single, standardized implementation of Java technology will do what Sun's broadly licensed Java ME failed to do: deliver a viable mobile software market across hardware vendors' offerings.
This all happened before
Android's goal is somewhat similar to the world of desktop computers in the late 70s, where various vendors adopted CP/M as a common way to write software that could work on more than just one computer model. Microsoft introduced its own modified copy of CP/M under the name MS-DOS, partnered with IBM to widely deploy it, and then became very successful in selling a standardized, proprietary version of what had been a loosely open standard (open in the sense of being widely used by multiple companies, not in the sense of open source or an open specification).
When other software vendors began copying MS-DOS, the new market for DOS PCs enabled hardware makers to bundle any DOS with their hardware, and customers could subsequently run any DOS software on their PCs. However, Microsoft subsequently worked to suppress and eventually killed off all MS-DOS software clone competitors with the introduction of Windows 95 in order to maintain monopolized control over the software platform sold on every PC globally.
In contrast, Google says it intends to allow manufacturers to use Android any way they like. Phone makers and even mobile operators can introduce their own modified versions of Android that all use the same Dalvik bytecode interpreter. This will result in the Android software market being much more like DOS PC world of the late 80s than the Windows world of the past fifteen years.
This is an important distinction because Google's Android is being frequently compared to Microsoft Windows by pundits, despite the fact that Google has little in common with Microsoft in terms of how it runs its new platform and how it plans to make money from it.
Platform environment: iPhone
Apple has taken an entirely different approach to delivering its mobile software platform. Rather than building a bytecode interpreter based upon a specific, customized implementation of Java ME, Apple introduced the iPhone running a scaled down version of its desktop Mac OS X Cocoa development environment. This leverages the installed brain trust of the company's Mac developers rather than the installed base of Java ME coders in the existing smartphone market.
It's still possible to port Java code to the iPhone, but it requires more translation work as Apple only supports Objective-C/C as an iPhone development language in its own tools. Rather than allowing iPhone developers to easily port over desktop Mac apps to the iPhone, the great overlap between iPhone and Mac development tools appears to have been more of strategy to draw developer attention to the Mac. Apple already sells about twice as many iPhones as it does Macs, and the iPhone certainly casts a larger mindshare net than the Mac platform does itself.
The differences between developing for Android and for the iPhone are not a clear win for either camp. Both offer somewhat similar tools in terms of capability, with Google's being more familiar to open source or Java developers and Apple's being nearly identical to its desktop Mac platform tools. Apple has a minor lead in having deployed its platform about a year and a half before Android reached the market, and because it has been actively working on its Mac OS X platform for over a decade; Google is new to the platform development business.
However, the team Google acquired to put Android together has been working within the company for about as long as Apple's own efforts on the iPhone; both got started on their current strategies around 2005. Outside of Google, the original Android project dates back to 2003, and was largely built upon on operating system technology that started at Danger in 2000, around the same time as Mac OS X's modern development. So in many respects, Android and iPhone are contemporary platforms, as opposed to Symbian, BlackBerry OS, and Windows Mobile which had their core foundations designed in the mid 90s to serve very different purposes as simple PDA or pager operating systems.
Android vs. iPhone: the business model
In addition to their internal technical differences, Android and the iPhone platform also differ in many other more significant respects that will more directly impact users. It's possible to use inferior technology to create a good product, and to use excellent technology to deliver a terrible product. More than technical specifics, users will be most impacted by platform factors such as:
â¢ User restrictions and/or freedoms accorded by the platform's business model.
â¢ The potential for rapid advancement of new features, increased sophistication and greater performance delivered in software updates.
â¢ The usability of core bundled applications and the availability and affordability of useful and desirable third party software.
Upcoming segments will look at how Android and the iPhone compare in these respects.