In a previous post I argued that it was Palm’s WebOS that had emerged as a legitimate threat to Apple’s iPhone; Google’s Android platform is left in third place to compete with the Blackberry OS, Windows Mobile, and Symbian—all of which now look very much like previous-generation technology. I also said this about Android:
Frankly, I’m not sold on the business sense of this project: Android’s architecture doesn’t seem nearly web-centric enough to be of direct benefit to Google.
In the past week, Google released the Native Development Kit for Android, which allows Android development in C and C++. I’m a big fan of C++, but this just seems to be another giant step the wrong way along the programming-language timeline.
I’ve always thought that the main difference between Android and the iPhone is that Android is meant to run on lots of different kinds of hardware: some with physical keyboards, some without; some with GPS, some without; etc. This is an advantage in that it allows manufacturers to create Android phones for market segments that the iPhone isn’t addressing; Android could thus build up a huge user base. The size of the user base then makes the Android platform compelling for developers, who create and sell applications for all those phones.
This disadvantage to such heterogeneous hardware is the difficulty in creating applications which work well in all situations. An interface designed for a physical keyboard is nearly unusable on a device with only a touchscreen, and an interface designed only for a touchscreen is wasteful and inefficient on a device with a keyboard. What’s more, applications then need to be separated into categories for the classes of devices they run on: some apps may only work if GPS is available, for example. The prospect of a single unified app store (and thus a single market larger than the iPhone market) is remote.
A native development kit further undermines the advantages and enhances the disadvantages of different hardware configurations. Native apps actually need to be recompiled for every different type of processor (and possibly each different memory architecture) used in devices. Worse, in the cases where native development is needed to accomplish things that the Java SDK cannot, the app might need to be completely reimplemented for each different device.
I understand the desire for a native SDK: native apps can be much faster and more efficient (in terms of both power and memory) than Java apps. But that’s a backwards-looking philosophy. A non-native app which runs too slowly on today’s phone will run perfectly fine on tomorrow’s. A native app will run fine on today’s phone but won’t run at all on tomorrow’s. Apps like that won’t encourage a customer to buy a new Android phone to replace their old one, and this “just make it work today; we’ll worry about tomorrow when it comes” approach seems much more appropriate for a company in desperate need of immediate success (e.g. Palm) than one with the cash to gain ground slowly over time (e.g. Google).