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 problems some iPhone developers are having writing apps for the Apple device, caused by a restrictive NDA that prohibits them from discussing code and therefore collaboratively solving problems, will Android be a more attractive system for developers? Of applications? And if it is, does that mean it’s going to be an iPhone-killer? In a word, no. This is why:

Android is 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. In reality, 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, for one, 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 the available hardware: camera (not present on either iPod), GPS (not present on the iPhone 1 or iPod, although location-aware services are still supported on both via from Wi-Fi 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 vibrate feature being iPhone-only, but this is such a phone-focused component that it hardly 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 allows you to access it as standard, if not, you get access to the built-in Photos app. Either way, you know you’ll be accessing the images in the 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, you could be running on any 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 whether 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? does video? The same goes for GPS. And so what kind of sound capacity is there? The list goes on.

So in the hardware alone, there are thousands of possible combinations, and you will never be able to test them all before releasing 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 “stock” part of the OS, and then Sony will release a phone that doesn’t actually have that part, because they either removed it or replaced it with something they wrote themselves. So your app fails.

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

Unlike the iTunes App Store, which vets all software before it’s released, 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, see that they don’t work, and give up. Chances are they will never discover your artwork among all the junk.

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 its vision, it will 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 knowledge. Android is too techie and it 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 on?

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *