Why Android won’t kill the iPhone

With Google recently showing off the first Android device, there has been a lot of press attention on the open source operating system. Given the trouble some iPhone developers are having writing apps for the Apple device, caused by a restrictive NDA that prohibits them from discussing code and thus collaboratively solving problems, will Android be a more attractive system for them? app developers? And if it is, does that mean it’s going to be an iPhone-killer? In a word, no. This is why:

Android is already too late, Google was wrong to keep developers waiting. Somehow they tried to repair that, but a lot of damage had already been done. The iPhone platform has been around for a year and the official SDK for several months, giving it a head start.

But the real problem is going to be the phones. Actually, everything is a problem. Android is open source, which means anyone can use it and anyone (including phone manufacturers) can make their own changes.

So, on the one hand, you have the iPhone, which runs Mac OSX (well, iPhone OS, which is essentially the same thing). Every copy of iPhone OS is more or less the same (at least if you consider version 2 to be iPhone OS and rule out version 1, which now only runs on a minority of devices).

iPhone OS currently runs on only four hardware devices, iPhone 1st generation, iPhone 2nd generation (3G), iPod Touch 1st generation, and iPod Touch 2nd generation. Between them, there are only four differences in available hardware: camera (not present on either iPod), GPS (not present on iPhone 1 or iPod, although location-aware services are still supported on both via wifi interrogation or cell tower triangulation) ), phone/cellular network access (iPhone only), and 3G data (only present on iPhone 3g). You could also make a case for the iPhone-only vibration feature, but this is such a phone-centric component that it barely deserves a mention.

So if you want to write an app for iPhone OS, it’s relatively easy because you know exactly what you’re dealing with. For example, if you need to access an image, the operating system does all the heavy lifting for you: it gives you an easy way to check if you have a camera available. If you have it, it lets you access it out of the box, if not, you get access to the built-in Photos app. Either way, you know you’ll get access to images in a standard way.

If you want location-based services, you’ll get access to all the hardware. If you’re using an iPhone 3G, the operating system will provide GPS data to make your location more accurate, but it will still work on the other hardware.

Everything else is the same on all devices: same screen size, resolution, languages, keyboards, accelerometers, audio capabilities, etc, etc.

Compare that to an Android device. On the hardware side alone, it could be running on any one of hundreds of different devices. You don’t know what size screen you have: it could be big like the iPhone, it could be small like a Nokia flip phone. So how do you start designing a user interface when you don’t know how much space you have to do it?

So you don’t know how many colors you can support, or if the device has a keyboard or not. It may have a touch screen, or it may not. It may have a joystick or d-pad, or it may not. So how do you let users interact with your app if you don’t know all of the above?

To continue… the device can be working in English, French or 100 different languages. You don’t know if there is a camera or not, and if there is, what kind of camera? What resolution? Do you make video? The same goes for GPS. And then what kind of sound capacity is there? The list goes on.

So, on hardware alone, there are thousands of possible combinations, and you will never be able to test them all before launching your app, unless you buy every Android device that will be released in the future.

But it gets worse, because remember that the phone manufacturer can also change Android itself! So you can write code that uses some “standard” part of the OS, and then Sony will release a phone that doesn’t actually have that part, because they removed it or replaced it with something they wrote themselves. Then your application crashes.

Assuming you somehow manage to write an application that can adapt to all possible hardware configurations, and take into account the fact that it runs on an operating system that might or might not be the same one you developed it for, then you have to distribute it on google app store.

Unlike the iTunes App Store, which reviews all software before putting it up for sale, ensuring a minimum level of quality, anything goes in the Google store. Which means you’ll be inundated with useless apps (many of which won’t work for the reasons discussed above). Users will download one or two apps, find that they don’t work, and give up. Chances are, your artwork will never be discovered among all the trash.

Other than that, Android is a good idea. And the mobile market needs it, because Nokia bought Symbian and will probably kill it, and Windows Mobile is just horrible. So Android will stimulate some competition. And if Google sees your vision, you’ll end up running DVD players, washing machines, and who knows what else. So it’s a useful project.

But for writing apps and distributing them, iPhone OS is light years ahead. He also has Apple’s consumer marketing insights. Android is too tech-savvy and will take much longer to reach the general public. After all, besides iPhone users, who buys a phone based on the operating system it runs?