Mark Lowenstein has a good write up of where Android is falling a bit short, and makes the case that Google should work with operators to provide distinct Android experiences for all devices across each operator, rather than the current OEM free-for-all.
My perspective is a little different. The 100 variations thing didn’t really work for UNIX vs. Windows 20 years ago, and it could be a big problem for Android vs. iPhone (or even BlackBerry) in the future. Microsoft had a similar problem with phone hardware inconsistencies resulting in quite a few dogs running Windows Mobile. The inconsistencies turned off consumers, and consumers tended to associate any bad experiences with the platform rather than a particular phone model. Google’s now at risk of having a multiple of the Microsoft Windows Mobile problem as both hardware and the software experience are modified by OEMs and/or operators.
While Google does provide financial incentives to operators that use the core Android experience, it hasn’t been enough to contain the proliferation of variants. The problem is that the OEMs are working so hard to differentiate their devices, that they can’t pass up the custom UI experience play. To date, operators have been pretty darn happy about mandatory data plans on very capable and inexpensive Android phones.
If Google were to alter it’s strategy to work with each operator on a distinct variant of Android and have the operators each force the OEMs to synch with their own model – it still wouldn’t help app developers or consumers at scale. Is the innovation advantage in having each operator go in a slightly different advantage worth the consistency loss? My take is that in this case, the answer is no.
In the long run, Apple devices are going to continue to be the easiest to develop on and the most attractive to the majority of consumers as long as they have a big consistency advantage. That’s a positive cycle that will be hard to match.
What does the current state of Android proliferation mean to companies building mobile apps? It means that a fraction of the problems of J2ME and BREW are still alive and well on Android: namely that all complexity and custom-work that goes into an Android app is more expensive than it would be on a platform like iPhone, since it must be is multiplied across device resolutions, UI models, and keyboard configurations and tested in these different situations. This means that a least-common-denominator approach is the right way to go for anything that’s not considered a key component of the unique user value or a major differentiator in the app experience, and the vast majority of the hard engineering and product work should be put into those few valuable features that will make or break the product experience.
