Why Android Won’t Kill the iPhone

Since Google has recently unveiled the first Android device, there has been a lot of press attention to the open source operating system. Given the problems that some iPhone developers are having writing applications for the Apple device, caused by a restrictive NDA that prohibits them from discussing code and therefore collaboratively solving problems, is Androind going to be a more attractive system? for application developers? And if it is, does that mean it will be an iPhone killer? In a word, no. This is why:

Android is already too late, Google was wrong to keep developers waiting. They did something to try to repair that, but it was already done a lot of damage. 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 will be the phones. Actually, everything is a problem. Android is open source, which means that anyone can use it and anyone (including phone manufacturers) can make their own changes.

So on the one hand, you have the iPhone, with Mac OSX (well, iPhone OS which is essentially the same). Every copy of iPhone OS is pretty much the same (at least if you consider version 2 to be iPhone OS and version 1 at a discount, which now runs only on a minority of devices).

Currently, iPhone OS only runs on four hardware devices, iPhone 1st generation, iPhone 2nd generation (3G), iPod Touch 1st generation, and iPod Touch 2nd generation. Among them, there are only four differences in the available hardware: camera (not present on iPod), GPS (not present on iPhone 1 and iPod, although location detection services are still supported on both through interrogation wifi or triangulation of mobile phone towers). ), access to the phone / cell network (iPhone only) and 3G data (only present on iPhone 3g). You could also argue in favor of the vibrate feature, which is iPhone-only, but this is such a phone-centric component that it hardly deserves a mention.

So if you want to write an iPhone OS application, it is relatively easy because you know exactly what you are 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 so, it lets you access it in a standard way, if not, you get access to the built-in Photos app. Either way, you know that you will have access to the images as standard.

If you want location-based services, you will have access to all hardware. If you are running an iPhone 3G, the operating system will provide GPS data to make your location more accurate, but it will continue to work on the other hardware.

Everything else is the same on all devices: same screen size, resolution, languages, keyboards, accelerometers, audio capabilities, 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 screen size it is: it could be big like the iPhone, it could be small like a Nokia folding phone. So how can 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 it can support, or if the device has a keyboard or not. It may or may not have a touch screen. It may have a joystick or directional pad, or it may not. So how do you allow users to interact with your app if they don’t know all of the above?

To continue … the device may 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 so what kind of sound capacity is there? The list goes on.

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

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

Assuming you somehow manage to write an application that can accommodate every possible hardware configuration, and take into account the fact that you are running on an operating system that could be the same as the one you developed it for, or that it might not be, then it should. distribute it on the google app store.

Unlike the iTunes App Store, which examines all software before putting it on sale, guaranteeing a minimum level of quality, in the Google store, anything goes. Which means that you will be inundated with useless applications (many of which will not work for the reasons discussed above). Users will download an app or two, see that they don’t work, and give up. Most likely, your artwork will never be discovered among all the garbage.

Other than that, Android is a good idea. And the mobile market needs it, because Nokia bought Symbian and it will probably kill it, and Windows Mobile is just awful. 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 to write applications and distribute them, iPhone OS is light years away. He also has Apple’s knowledge of consumer marketing. Android is too technological and will take much longer to catch up with the general public. After all, aside from iPhone users, who buys a phone based on the operating system it runs?