How Google can checkmate iPhoneMarch 1st, 2010 by Jeremy Chone
When looking at the future of the mobile market, we can clearly see two big contenders, Apple and Google. While Apple has a definite head start, Google mobile’s strategy and execution has been impressive. In the last couple of years, Google has managed to create an open platform, engage with a wide variety of device manufacturer partners, and promote its own branded device. Although iPhone fans might disagree, it is fair to say that, with the latest Android 2.x generation of devices (i.e., NexusOne), there are fewer and fewer hardware and software differentiators between the two solutions.
The dilemma: iPhone is still the big gorilla
However, despite Google’s successes with Android, iPhone is still the big gorilla, and it is too early to predict whether Android will ever take the lead.
Looking at the three aspects (i.e., product, distribution channel, and ecosystem) of each business, we can easily see that Apple is still the clear leader in the market it created: the application ecosystem. In this category, iPhone beats Androids on all counts (i.e., users, applications, and revenue)
In the real world, this means that if you intend to build a mobile application, you will probably do it first for iPhone and then for Android with the leftover. Ironically, Google is in the same position that Apple is in the PC market vis-a-vis Microsoft.
So the billion dollars (or downloads) question, is how can Google turn the tables?
The solution: Embrace and extend
The short answer is, Google should embrace and extend the iPhone [ecosystem] by creating an Android.iPhone SDK.
Google should enable its Java/Eclipse mobile development environment to support iPhone. This would allow developers to use a single mobile development environment to target different devices. This move would hit Apple at the source of its core differentiator, the developers.
The trick of such execution is to strike the right balance between the write once, run anywhere model and to use the best aspects of each device. In fact, from my experience, the best way to tackle this problem is to offer both models and let developers and time decide which one deserves a greater investment.
For example, Google should offer the following options:
- A way to “cross-compile” an Android application for the iPhone. This would have the advantage of the write once, run anywhere model, but would inherit its disadvantage as well (i.e., the lowest common denominator).
- A specific Android.iPhone SDK that would extend the Android SDK where necessary to fully utilize the iPhone specificities.
The good news for Google is that this path, of third-party iPhone development tools, has already been paved by numerous small companies, as well as by Adobe with the upcoming Adobe CS5. Consequently, it will be difficult for Apple to single out Google even if this move could be more disruptive to the iPhone business than Google Voice application (which has been notoriously rejected by Apple for competitiveness reasons).
If Google were to offer this solution, it would have a big impact on how developers approach mobile development. It would eventually position the Android SDK (and Android.iPhone SDK) as the de facto standard environment in which to develop native mobile applications and make Android an easy and cost-effective device to target.
Additionally, this strategy has the unique advantage of bringing Apple into the foreign territory of openness and inclusion. Apple is very comfortable in competing and innovating in closed markets (i.e., music and mobile), but tends to be a little defenseless in open ones.
The catch: Cost
The only catch of this strategy for Google would be the cost. Doing this the cheap way would backfire, and doing it well would not be easy. However, this embrace-and-extend strategy could be the next single most effective step that Google takes in the mobile space.
If you liked this article, retweet, rebuzz, or +1 on HN appreciated