iPhone evolution and how to avoid the Android problem

One of the reasons for the iPhone to be such a well functioning and exceptionally usabale device lies in the fact that, completely in Apple fashion, both hardware and software are made by the same company. This way, the hardware engineers were completely aware of how the software would function, and the software engineers fully knew the ins and outs of the hardware platform, letting both achieve the maximum of what’s possible with the combination. This has worked very well in the past too: just have a look at the Mac to see how a complete package of tightly integrated hardware and software eleminates a lot of problems that occur in the generic PC field, where all software is supposed to work on all possible vendors, types, versions and variants of hardware components in countless possible combinations.

Next to the obvious usability advantages for end users, having a clear combined hardware/software platform is also a very nice thing for developers. Knowing exactly the device that your software will eventually run on gives a developer some of the same benefits: he or she can take maximum advantage of the platform, without taking the risk that something would not work, or work differently, on another type of device. You know the capabilities and limitations of the platform, and you do not have to guess what features might possible be there, or worse: what featurs might be missing and how to deal with such a situation.

Now take a look at the Android platform. Android is a well designed piece of operating software, based on a steady and capable Linux kernel. So far so good. However, contrary to the iPhone, Android is not a combined hardware/software platform. It is a software platform that can be applied on a phone by a handset manufacturer. And contrary to the iPhone, all manufacturers of Android handsets are direct competitors to each other. Which means that, in order to stay competitive, they have to differentiate their products. This will very rapidly lead to different Android models, with or without hardware keyboard, with or without scroll-weels, with or without multi-touch capacitive touchscreens, with different screen sizes and different screen resolutions.

This makes developing for Android far more difficult. After all, you have to take all those different hardware configurations into acount. And quite possibly it means that current software needs to be adapted for future devices. As an example, let’s take a look at the keyboard. The first Android phone, the HTC G1, features a slidable hardware keyboard, and the phone expects it to be there, as it is the only way to enter text in an application. There is no on-screen keyboard. Whenever a future Android phone would exclude such a keyboard, text entry should be done using some sort of on-screen keyboard. However, the current Android apps feature a user interface that was not designed to offer place for one.

Things will become even more difficult when you think of handsets with different screen sizes and pixel counts. Some applications will simply not fit on the screen. And by keeping the pixel resolution and shrinking the screen, active areas for user input would become too small.

I expect Google to offer a solution for this in its development SDK, however no matter what: a developer from then on needs to take all the possible handsets and configurations into account. A simple solution would be to develop for the a common feature set, but this will result in software that it not optimized to take advantage of all the features of the phone. Compare this to the near-universal Java “games” that work on nearly all simple cell phones. It is not a coincidence that the Android SDK is based on Java, alowing easy porting between platforms and not be limited to certain processor architectures and hardware capabilities.

As I explained, none of these issue affect the iPhone (both the original iPhone and the iPhone 3G are identical in terms of hardware/software platform). That is: until now. The question is: what will happen when Apple eventually wants to differentiate its iPhone line of products? Especially if and when Apple wants to introduce smaller screen versions, possibly in a “candy bar” or clam-shell design. This would of course break the current screen size/pixel count ratio, and results in the same user interface issues that I mentioned above.

Some might argue that Apple will never break the current iPhone platform with different form factors, declaring that Apple is not interested in this portion of the market (comparing it to the Mac-market, where Apple has no products in the budget to mid-level price segment), however I think that Apple will follow a different strategy with the iPhone. Noting that the cell phone market is several times bigger than that of the personal computer, and combining this with the fact that it is much easier to introduce a new platform at this time compared to the mature state of the computer market, make me fairly certain that a new iPhone form factor will make perfect sense for them (comparing it, if you will, to the iPod, where Apple has a product at each $50 segment ranging from $50 up to $400).

So, eventually Apple will face the problem as well: current software will not work (well) on new form factor hardware designs. Assuming that this new, smaller, iPhone still offers a way for users to install third party software, Apple should provide the necessary tools in the SDK to do so. However, Apple has a big advantage over other “open” platforms like Android: It can minimize the number of possible platform configurations.

And I think they can do so in a clever way. Assuming that the succeedor of the current iPod nano will also be based on OS X (as the iPhone and iPod touch are today), why not combine the platforms of both it, and the new small form factor iPhone into one? Let’s face it: The small screen on an iPod nano is about what you would expect on a candy bar phone. Just as the iPod touch greatly expanded the reach for developers of iPhone applications, the same could happen with a single platform for the iPod nano and the small iPhone.

Of course, Apple should figure out whether such a small-screen device should be operated using a touch screen, or whether the device should retain its landmark click wheel. And whether this click will would then be incorporated into the small iPhone. But keeping the main aspects, like screen size, pixel count, input operations and hardware platform the same, Apple would greatly extend the reach of this new sub-iPhone platform.

I think two configurations are still managable for software developers, especially if Apple keeps much of its hardware and software underpinnings the same as in the current iPhone. What’s more: both the large iPhone and the small iPhone will probably target different audiences with different application requirements. This is something radically different than looking forward to possibly dozens of hardware configurations with different input options, resolutions and sizes that Android is currently facing.

Oh, and to be clear: I don’t expect a small form factor iPhone, nor an OS X based iPod, anytime soon. But don’t be surprised to see next year’s iPod event in september 2009 to have Apple introduce us to their second combined mobile platform.

UPDATE 10/22:
In its Q4 conference call, Steve Jobs made a reference to the difficulty of developing for Android, compared to the single-model iPhone. According to Jobs“As software becomes the differentiating technology of this product category, people find that a hundred [hardware] variations presented to software developers is not very enticing, and most companies in this phone business do not have much experience in a software platform business. So we’re extremely comfortable with our product strategy going forward, and we approach it as a software platform company, which is pretty different than most of our competition.” I guess we’ll see.

Advertisements

2 thoughts on “iPhone evolution and how to avoid the Android problem

  1. I have to agree on your observation, when we’re concerned with the UI part of Android and iPhone’s OS X. However, the UI (really!) is only a small part of the stack. It’s the final step in which Apple has got the critical advantage of being closed. However, let us not forget that more than 75% (if it isn’t more) of Mac OS X’s codebase is taken from open projects, which weren’t designed with Mac OS X in mind. Mach for one wasn’t. Not even originally for the same hardware.

    The key difference is that you have a lot more room when you are writing an interface for a programmer. There are so many different ways of doing things amidst the libraries used, but they all share proper design, programmaticly. Diversity for the UI, the top of the stack, might work adversely: it’s no problem for the rest.

    I wouldn’t be suprised if Apple makes the iPhone Android compatible, except for the UI. Similarly, any program I write on Linux will work with little effort on Mac OS X, as long as I don’t do UI.

  2. Bas, some interesting points. It’s true that the UI is only part of the complete OS stack, but I also think it’s an understatement to think that Mac OS X is 75% kernel and related stuff, which I presume you are refering to by saying that 75% originated from open projects.

    I think the key differentiators for Mac OS X compared to other Unixes are the APIs (Cocoa and Carbon) and the Media facilities (Core technologies, after which this blog was named), which allow developers to create programs that really take advantage of the OS and which will not run on other systems.

    Have a look at http://developer.apple.com/macosx/architecture/index.html to see an overview of the OS architecture, or to http://developer.apple.com/referencelibrary/index.html for an extensive description of the componentens and a clarification between open and proprietary components

    I think an iPhone or Mac OS X app is not that easy to port to other systems due to the usage of these APIs, and that it involves more than rewriting the UI.

    To make myself clear regarding this article: Of course the iPhone and my imaginary “small iPhone” share these OS underpinnings, and hence they *can* benefit from easily porting a program from one to the other.

    But I am not a programmer, so please clarify if I dont get this right.

Comments are closed.