Originally Published on the Igneous Quill Xanga blog.
Mike Elgan thinks Android could fail. I'm afraid he might be right.
When the iPhone first went on sale back in 2007 it made an enormous impact on the smartphone market. Really, it took "smartphones" mainstream. Up until it came out, what we now call smartphones were devices primarily for business people and geeks. Rank-and-file mobile subscribers were content to talk and text with dinky flip-phones like the Motorola RAZR. My, how times have changed. Actually, a year ago I actually predicted that smartphones would be the future for most folks, and so far I think I'm being proven correct. On the train to work and in the streets I'm seeing more and more of these devices in people's hands. I believe this process of moving to smartphones was inevitable, but greatly accelerated by the iPhone.
The iPhone's a great device. It has a strong brand, an overflowing app store and hardware that was good to begin and has only improved. It may not be to everyone's taste (call me old-fashioned, but I really like my Blackberry), but it's clearly a powerful and fun device to use. The only real drawback I can see to it is the unevenly built-out mobile network it has to depend on in the United States.
What about Android? Well, it's a mobile operating system, not a device. Many different smartphones are being made to run with Android. So the brand is split up in a way, between the mobile OS and whatever hardware and carrier it is on. The iPhone doesn't have this problem. It's the iPhone on AT&T, and that's it.
Problems are arising precisely because there are many different hardware types running Android. Android app developers are struggling to make their apps compatible with the myriad different smartphones running Android, and no guarantees can be made as to functionality, except regarding specific devices. For iPhone app developers this really isn't an issue, given that the hardware is consistent. The iPhone OS is only intended for the iPhone device. No strange hardware configurations to be concerned about.
To mix things up even further, there isn't even a single Android OS in circulation. There are three versions of the OS in active circulation (Android 1.5, 1.6 and 2.0) and manufacturers and carriers often install their own custom firmware. For app developers this can be a major headache, and end-users are none-too-pleased when the app they download for Android doesn't work properly.
Having said all that, I'm sure there's a way forward. Android is a Linux-based, open source mobile OS. Any problem can be solved with enough eyes looking at it. Carriers could begin developing their app stores to differentiate better between different Android versions and mobile hardware, allowing downloads of only what is truly compatible with a particular device. Branding should be done from the device side, emphasizing the phone's brand rather than the OS on board.
Some matters need to be resolved to make Android a success, perhaps including the absense of the name "Android" from marketing. Could Android "fail"? Yes, it could, in a manner similar to the failure of Windows Mobile. The strength and weakness of Android is its open-source model. Proprietary has worked well for Apple and has been employed poorly by Microsoft in the mobile market, but only time will tell how well open source mobile development will do.
See Also:
Why Android Could Fail (Datamation.com)
Android's rapid growth has some developers worried (Wired.com via CNN Tech)
1 comments:
It sounds to me like no one has defined the appropriate API's to properly abstract the hardware from applications -- or else no one is paying attention to them.
To be frank, that's the point of an operating system. An operating system is supposed to handle the particulars of hardware and provide a standardized interface to the software applications. It's how both Windows and Linux are able to run on a plethora of disparate hardware platforms in the non-embedded world. (It's also why my application doesn't need to know whether I'm running on 10Mbit wired ethernet, a WiFi network, or a WiMax network. I simply need to open a TCP/IP socket and the operating system's underlying drivers handle the lower networking layers for me.)
The differing screen sizes is a bit more challenging, but that's only because those of us who write software on embedded systems like to hard code everything for our device's display. But it doesn't have to be that way. Yes, it will cost a bit in terms of execution speed. But unless they're trying to do something graphically intensive (as opposed to trying to display text and images), that should be fairly negligible.
Post a Comment