No less than 1,000 new APIs were introduced to programmers, letting them do even more advanced stuff with the iPhone and iPod touch then before. Think of using the dock-connector or bluetooth to communicate to dedicated accessories, or the direct iPhone-to-iPhone networking connectivity over Bluetooth that doesn’t need pairing or joining of a wireless network, or the widely disussed push notification services letting applications notify users even when the actual program is closed, or the voice-over-IP functionality that can easily be implemented in a game or app without much efforts, or the in-app purchasing features opening up the way for many new types of applications.

Surely, consumers will be spoiled, if not overwhelmed, with the flood of new applications (or renewed applications) in the second half of this year, pushing iPhone as a platform even further away of the curve.

In this article, I will briefly share with you some thoughts I have on some of the new features offered by the iPhone 3.0 software and the new SDK.

iPhone-enabled USB-sticks and USB-adapters

When I heard that developers will now have full access to the dock connector to connect an unlimited array of hardware accessories, I started thinking about using the iPhone as a companion for USB storage devices. Think of an adaptor with an iPhone-connector at one side, and a USB-port on the other, which enables you to plug a USB-stick into the iPhone. Next to some obvious statistical data such as the stick’s free space, such an app could then also show a listing of the files that are on it. From here, you could do whatever you want with the files, such as opening (or even editing) documents, e-mailing them to others, or perform file management tasks like deleting, renaming or putting files in (password protected) ZIP-archives. The iPhone would be a perfect companion to a data storage device!

As USB-sticks use a standard protocol to present themselves to a host know as “Mass Storage Device”, a single piece of software should work with virtually all kinds of storage devices, including external harddrives. This might even result in a thriving new market for apps.

Of course, nothing would prevent hardware manufacturers from introducing USB-sticks with a USB-connector at one side to allow connection to a computer, and an iPhone connector at the other side to let the users do all the things described above.

iPhone-enabled photo cameras and card readers

Of course it’s easy to extend the ideas above to other specific pieces of storage devices, such as digital cameras. Imagine being able to connect your camera to the iPhone using a USB-cable, which would then show you all the pictures that are on the device. Apart from the general file management tasks that I desribed in the previous paragraph, the iPhone would be an excellent preview-device for pictures, with its large display, and the ability to zoom in and pan around pictures. And of course, these pictures could be transfered to the iPhone’s internal photo library, so that they can be used by blogging applications, your Twitter client, etc.

As most digital photo cameras also mount as a generic Mass Storage Device, so compatibility across apps and various makes and models of cameras should not be a big problem. And for those who think that connecting the camera using a cable is too cumbersome, you could of course imagine an SD- or CompactFlash card reader that can be directly connected to the iPhone’s dock connector. (That is, untill the first camera with built-in Bluetooth is available, of course.)

Push notification services

Yes, we get it Apple. Push notifications trough a dedicated Apple server are the best alternative to actually running apps in the background, as this drains the battery and slows down performance of the phone. I actually do believe that this is not entirely marketing speak, but very common sense from the guys in Cupertino. But yes, we know that we have to fight a minor PR battle with Android and Pre users that will show us their background-performing, multitasking applications (when connected to an AC-adapter, of course).

As I said, apart from the occasional application that I can think of that would really require background applications (such as a GPS tracker that still allows me to use the other parts of the phone), I am generally very pleased with the push notifications solution from Apple. It will surely enhance the usage of the phone and a lot of applications.

However, I think the fact that a lot of applications will add push notifications to their feature list, will also quickly become the weak spot of Apple’s solution. As of now, a push message is a simple blue-colored pop-up window (the same one that we know from the SMS app) with a line of text and a button to dismiss or open the respective application. There can only be one message on screen at a time, you have to dismiss it or open the app, in any case you have to perform an action in order to receive the next message awaiting in the notification que. And what will happen when you receive SMS messages, have IM-buddies contact you, set your traffic app to notify you of delayed trains or jams, receive notifications of @you-messages on Twitter and what more. There is no unified listing of messages (as there seems to be on the Palm Pre), just constantly popping up blue boxes. Worse, the boxes all look the same, as in the current beta-version they do not for example include the home-screen icon of the app (which would not solve the entire problem, but would at least give a very clear visual clue of the kind of message). Much to my surprise, Apple did say that notifications can issue a specific sound. But why limit this identification of the app to a purely auditive thing, and not add a visual part?

It might be that Apple just wants to put the underlying frameworks in place for now, so that developers can begin adding the services to their applications. It is very thinkable that Apple will add a nicer, clearer and more user friendly presentation layer on top of this framework when the final version of 3.0 will be released (we all know that competitors also watch the QuickTime streams on the Apple website after a keynote event is finished). After all, we still have quite some months to go.

In-app Purchases

A lot can be said about in-app purchases that become a possibility for developers in the next software release. My initial thoughts were those of a typical customer: “So now I do not know upfront how much this app/game is gonna cost me, whereas before the app costst would never increase after I bought it”. True, the new system will make things much less transparent for end users, especially for the type of applications that ususally did not require additional payments in the past.

However, I also quickly thought of the many applications that this new functionality would allow. Think of traditional magazine and newspaper publications, which could now offer a single app that loads individual issues at request. What’s more, Apple even promised a subscription feature, so that a user could subscribe to, say, a month’s worth of newspapers. This might also benefit TV-stations or other video producers (and who do not have a deal with Apple for distribution trough the iTunes Store), who can now offer their premium programming and easily monetize it.

For a long time I have thought that the final missing piece in Apple’s media offerings trough the iTunes store (which now feature music, audio books, podcasts, TV-shows and movies) was books, or “e-books”. I expected them to add this department at some time, and believed that that would be one of the reasons why developers were not allowed to sell content within an app. Appearantly I was wrong. You can bet that Amazon is already working on an updated version of its Kindle app that lets user not only read their existing e-books, but also preview and buy new ones directly over the air. (And you can bet that the standard 70/30 split between developers and Apple will be negotiated on a high level for this specific developer!)

The one thing that leaves me boggled as far as in-app purchases are concerned, is the comment from Apple that this functionality would not be available in free apps. Their explanation: “Free apps remain free”. Of course, this is just another push that Apple wants to give developers to charge for their applications (as free apps of course only costs apple in hosting fees). Wouldn’t this be an excellent oportunity to get rid of all the “Lite” versions of (mainly) games that currently make up for about half of the 25,000 entries in the App Store? The ability to download a free limited “trial” version, which could then be updated to a full-featured paid version, would not only generate a much higher conversion rate (as the “update” would be a rather impulsive action from the user from within the game he is currently playing), but would also help in tidying up the already over-crowded App Store.

GPS-navigation on the iPod touch

Now that developers can include hardware support in their applications, and now that turn-by-turn navigation is officially made possible, why not add a GPS receiver to the iPod touch and turn it into a highly advanced navigation system?

The iPod touch as it is today does not include GPS circuitry. However, I can think of a manufacturer making a cradle for the touch that can be applied to the windshield, and which includes the GPS receiver. A cable from this cradle could be connected to the car’s hi-fi system, or it could even use the Bluetooth functionality that gets unlocked on the iPod touch with the 3.0 firmware, to communicate with compatible car audio systems.

All in all, I think that such a device could sell for sub $99 (perhaps in a bundle deal with a navigation app supplier), and would be a perfect companion to the now $229 iPod touch. After all, this combination offers not only routing navigation, but also a lot of other functionality that other after-market GPS solutions lack, including all of the apps that the App Store offers that come in handy on the road,  such as travel guides. Not to mention that this navigation unit could be used as a full-blown gaming device during rests, or that it can be taken in to that highway diner to check up with the latest news and e-mail using Wi-Fi.

And about music playback: Now that the 3.0 SDK even offers access to the user’s standard music library, the GPS-app might include music navigation controls (or even send this information to the car’s bluetooth audio system).

Keep an eye on the GPS space when 3.0 is released. I wouldn’t be surprised if this would not only benefit the iPhone, but also unvliels the contract-free iPod touch as a very capable car companion.

Some limitations that have been widely publicized are the inability to run more than one program at a time (leading for example to the inability to listen to an Internet radio station while doing something else), and the lack of the long promised push notification services (which among others enable instant messaging applications to receive messages when the device is idle or running another program).

But that’s not what I want to talk about. This time, I want to address another major annoyance.

There are a lot of areas when a desktop apps benefits from having a mobile app to take your data with you. Think for example of the excellent password manager 1Password, which can sync its protected database of passwords to the 1Password iPhone app. Or what about a personal assets database containing your lists of DVDs and books? It can be very handy to have these available on the go in a companion app on the iPhone. And of course you may want to upload some Office or PDF documents to a document viewer app on the iPhone.

And then we come to this other thing that has been bugging me for some time: the complexity that is involved anytime I want to exchange data between a desktop app on my Mac, and some application on my iPhone.

This complexity is due to a number of Apple’s design decisions. For one, there is no disk access to the iPhone, so a desktop app can not simply browser in the phone’s file structure to add or update some files. But even if there was disk access, Apple would possibly limit the level of files we could actually alter on the phone, to prevent it from being messed up. Apps would likely retain their “sandbox”, so that it would be impossible to change their contents.

Currently, the only way for an iPhone app and a desktop app to talk to each other is via Wi-Fi. But this has some serious limitations. First, there should be a wireless network available, which is not always the case, especially in corporate situations. Second, the desktop computer and the iPhone should be on the same network, for the handshake to work easily.  Third, the app should be actually running on the phone in order to communicate with the desktop. And fourth, it does not offer the user a streamlined interface to interact with the phone from their computer.

What about extending the iPhone SDK and modifying iTunes on the desktop, to allow desktop apps to exchange data with the phone via iTunes itself? Developers could then directly speak to the phone without getting the user involved. Another big advantage here of course would be that the program that is collecting the data on the phone is not required to be running.

Think about the examples I mentioned above. All of your passwords, personal library documents and files are copied to the iPhone without the need for any interaction on the phone itself. And when these programs automate this process, there isn’t even the need for any user intervention on the desktop either. All you current data is always synced to the phone.

Of couse, there are some possible design issues that need to be taken into account with this approach.

Currently, an app cannot receive data from anything other than itself (and the Wi-Fi connections it sets up by itself). This increases security, as no unwanted parties can alter the app. If Apple wants to maintain this security measure (or restriction, depending on your point of view), there needs to be some form of authentication in place between the the iPhone app and the desktop app that wants to talk to it. Apple could issue secure IDs for this within the SDK deployment program. And, depending on Apple’s mood, they might even loosen up things a bit, so that different desktop apps could talk to the same iPhone app (think of an app that aggregates different forms of data from different programs on your computer).

And there’s quite possibily another thing that might heaten up the discussion. For example what if Microsoft decides to incorporate my trough-iTunes communication funcationality in its Office applications to talk directly to a viewer app on the iPhone. This quite well destroys the open market for Office document viewers.

This can be solved by specifying various document types that a desktop app can parse to iTunes for communication with an iPhone app, and then let the user decide what iPhone app should be used. Compare this to the way an operating system always opens a type of file using a default program, but allows the user to select a different program to open the file if he or she wants to. Of course, for a lot of programs this makes little sense (like the 1Password example I gave above: the desktop and iPhone apps are directly linked to each other), but for many types of files and data it does. This might even create a blossoming market of new iPhone apps.

Of course, in typical Apple fashion the user interaction dialogs that a program displays when syncing or exporting data to the iPhone should be included in the Human Interface Guidelines, so that they become easily recognizable by users, and can be operated in a streamlined way. No more IP-addresses to go to with your browser to upload some documents to your iPhone app, and no more inconsistency between apps when doing so.

Some might argue that in this time and age, one should focus on over-the-air solutions to these kinds of data exchange problems. Some phones, like the Android-based ones, even completely lack any syncing with a computer via a cable. However, please remember that we are talking specifically about the interaction with desktop apps here. In general, when you want a desktop app to move something to your phone, you are near this desktop machine. It’s not something that needs to be pushed to the phone at any given moment. Furthermore, the iPhone needs to be docked to the computer anyway if you want iTunes to upload new audio, movie or photo files. And there might even be a win in it for Apple as well, as it places iTunes at yet another strategical position within the iPhone/iTunes eco-system, the added visibility benefiting its other, money-generating acitivites in the iTunes Store.

Sure Apple, give us the Push Notification Services we have been promised to get last September. But when that’s done, please have a look at how to move data between the phone and the computer. It can be greatly improved.

Currently, I listen to about a dozen podcasts, mainly covering the Mac. They range from daily shows such as the excellent Mac OS Ken from Ken Ray, who summarizes the Apple news from various sources in about 15 minutes, via the hour-long weekly MacWorld podcast, up until the MacBreak Weekly show, which, depending on its panel of hosts, can be up to one and a half hour long (my absolute favorites are the ones featuring Andy Ihnatko, the funniest and one of the cleverest Apple commenters around). My favorite blogger (and inspirator for starting my own blog) John Gruber from the Daring Fireball also hosts his own show every few weeks, simply called The Talk Show. And then there are some local shows in Dutch that I listen to, such as the One More Thing podcast (which, despite its name, is in Dutch), whose three presenters pioneered podcasting in The Netherlands in 2005.

Needless to say, I am a heavy user. I was therefore very pleased that starting iTunes 4.9 in June of 2005, Apple made podcasts a central part of its audio jukebox software and the iPod interface. Prior to that, seperate podcast aggregators had to fetch your episodes and transfer them to iTunes as playlists. There was no way to identify them as podcasts, let alone benefit from the later advantages that the official podcast support brought to iTunes and the iPod, such as a notification of what episodes are unlistened, and picking up from where you left, even if you played some other podcasts or music in the meantime. One of Apple’s motivators for including podcast support was the inclusion of a podcast directory in its iTunes Music Store, as although the podcast searching did not generate them any money directly, it was a nice way to introduce a lot of people to the other content the Store has to offer.

For the iPhone, podcast support has been there since ithe beginning. However, only since firmware version 2.1, podcast support became really neat, showing extra information fields in the episode listings, such as the name of its creators, and the remaining playing time. Actually, there was only one obvious thing missing: the ability to download new podcasts directly on the device, rather than uploading them from your computer during an iTunes sync.

As you can imagine, I was thrilled when the first rumours emerged that the iPhone 2.2 software would let users download podcast episodes directly on the device. I sync most of my other data on my iPhone over-the-air (a Mac mini running Kerio Mail Server gives me always up-to-date e-mail, contacts and calendars (the latter one including the shared calendar of my girlfriend, who is also an iPhone user), and MobileMe takes care of syncing my Safari bookmarks). The only thing that still needed a daily sync with iTunes on my Mac was the transfer of new podcast episodes.

So can I be wire-free since iPhone 2.2′s new podcast retrieval feature? Sadly not.

I think Apple made some wrong decisions in the way the handling of grabbing new podcasts is handled on the iPhone, and that most of these were based on two leading factors. First, take care of avoiding accidential downloading of data over telecom networks. And second, make sure that the iTunes Store remains the location that people need to go for new podcasts, for reasons stated above.

Let’s go into some of the details of the iPhone 2.2′s new podcast functionality:

• You cannot “subscribe” to a podcast. There is no ability to automatically download a new episode when it becomes available. I can imagine, however, that leaving a several podcast subscriptions running could easily lead to the accidential downloading of hundreds of megabytes of data. Telecom operators would not be happy. However, why not at least check a podcast feed for new episodes at a given interval, and then notify the user that a new podcasts is available for manual download? The only way to see if any podcasts are available is to click the “Get more episodes” link at the bottom of each podcast listing. This brings us to the following issue.
• Contrary to the situation on the Mac or PC, where the podcast directory and episode downloading are integrated into the same iTunes application that manages and plays your media files, on the iPhone there is a clear distinction between the iTunes Store application that handles the downloading of podcast episodes, and the iPod application that is responsible for playing them. This means that once you select the “Get more episodes” link, the iPod app will quit and you will go to the iTunes Store app. Once you have performed the needed actions for downloading an episodes, you need to go back to the iPhone’s Home screen, navigate to the iPod app, start it, go to the Podcast section and begin playback. This is the same kind of behaviour that I dislike in applications that feature a “Mail this info” button: You leave the app, go to the Mail app, and afterwards you manually need to start your original app again and navigate to where you left of. Bottom line: Why not include this downloading of podcasts within the iPod app itself?
• This lack of integration showcases one of the biggest ommissions in the iTunes app’s Podcast section. When you are looking at a list of recent episodes you can download, there is no way to see what episodes you already have downloaded. This means that you have to remember the title or date of the latest episode in the iPod app, click the “Get more episodes” link and then select the appropriate new episode to download. Bizarre.
• Worse, if you select an episode that is already stored on your iPhone, it will simply re-download the episode, and replace it (or leave it alone, depending on your view) in the iPod app. A needless waste of bandwidth.
• You need to check for new episodes for each individual podcast, there is no “Check all podcasts for new episodes” or something. This means a lot of juggling between the iTunes app and the iPod app, as you need to repeat these tiresome steps for each individual podcast.
• Podcasts you download on the iPhone are always copied back to the computer at an iTunes sync. You cannot turn this off. For most users like me, there is no need to have the podcasts stored on my Mac as well, adding needless extra time to the already lenghty iTunes sync process.
• Strange: You can delete a podcast episode on the iPhone by using the familiar swipe-gesture, but in case the podcast is listed in iTunes on your computer, it will be copied back to the iPhone during sync. The “Deleted” flag is obviously not copied to the computer.
• There is a 10 MB limit for downloading over the cellular network, similar to the limitations for applications in the App Store. If you try to download an episode that is bigger than 10 MB, you are instructed to connect to a Wi-Fi network and try again. I can understand the burden that lies with the telecom operator when people download big files over their network, but in this case it makes downloading of podcasts without Wi-Fi practically impossible. 10 MB translates into roughly 10 minutes of audio, eliminating most of my podcasts from downloading without Wi-Fi. (To be fair, there is also a “streaming” option in the iPhone’s iTunes Store app, so that instead of downloading an episode, you can also listen to it in full by streaming it. Playback continuity however largely depends on your cellular signal strength this way, and it also puts a large burden on battery life.)

But the biggest gripe for me is the fact that you cannot check for new episodes from podcasts of which there are no episodes currently stored on your iPhone. For the past years, I had the habit of deleting every episode from iTunes that I listened to, resulting in the episode being removed from the iPod/iPhone as well during the next sync. Consider this a bit like “status read/unread” practices for e-mail: it was a way for me to get an instant glance at what episodes are still waiting for me to be listened to. However, when there are no episodes currently stored for a particular podcast, its entire entry is removed from the iPhone during sync. And when a podcast is not listed, there is no “Get more episodes” link, eleminating you from downloading new episodes (unless you are willing to go to the iTunes app, search for the podcasts title, and then download the desired episodes).

I have circumvented this issue by setting iTunes on my Mac to always retain the one most recent episode, and sync every episode to the iPhone, so that there is always a listing of all my podcasts available, each containing one episode. I must leave the habit of ditching played episodes, as this would lead to the inability to download new episodes on the phone.

So to summarize: The whole procedure of looking for and downloading new episodes on the iPhone is so cumbersome, that I still check for new episodes on my Mac, and then sync them over to the iPhone. Only in these occasions that I am away from home with no new episodes to listen to, I (look for a Wi-Fi network to join and) check for new episodes of each individual podcast to download directly to my iPhone.

And I simply have to forget the fantasy that I had when I first heard the iPhone 2.2 rumors about just plugging my phone into its power charger next to my bed at night and not needing to dock it and sync with iTunes every day. Let’s hope Apple will have a good hard look at the podcast functionality in the iPhone again, so that they can surprise us with some better solutions next firmware time around.

There are of course some obvious advantages to the basic application of text messaging, but there are also a lot of technical limitations in the SMS protocol as well as some strange implementations by telecom operators and handset manufacturers, that very much limit the usability for the users. Let’s have a look at some of them.

Advantages of SMS text messaging:

• Very easy to explain
  Even the most technophobic cell phone user is able to grab the idea of text messaging. The message you enter on one handset will appear on the display of the receiving handset. The only thing you need is the receiving party’s phone number. There is no need to know anything else, such as an alternative address other than the cell phone number, or knowing the capabillities of the receiving handset or the services of the telecom operator.
• 100% installed base of handsets
  SMS is supported on all GSM handsets (the only cell phone standard in Europe, and the dominant standard worldwide), and nowadays also on handsets of competing technologies. SMS sending and receiving is supported by all mobile carriers and offered trough all mobile phone plans. Everybody who owns a mobile phone is able to send and receive text messages. No need for additional devices, no need for special subsciptions.
• No action required to receive messages
  An SMS text message will always appear automatically on the handset’s display. There is no need to “request” for incoming messages. When the phone was off during the initial transmission of the message, it will be delivered within minutes after the phone is turned back on.

As explained above, the concept of SMS text messaging is easy to understand, which undoubtly contributed to its huge popularity. Sadly, some pretty odd decisions were made during the development process of the SMS specification, which truly limit the usage of text messaging up until today.

Limitations of the SMS text messaging protocol:

• Limited length
  For various technical reasons, mostly to compromise on cost in both the setup of the mobile network and the software and hardware in the phone handset, the lenght of an SMS text message was fixed on 140 bytes. Due to the use of 7 bit characters in the western alphabet, this results in 160 characters per message. When other alphabets are used that need 16 bit Unicode (Greek, Russian, Japanese, etc.), the lenght is even further shortened to 70 characters. (Multi-part messages even cut into this per-message limit by eliminating a further 7 characters, needed within the system to assemble the messages in the right order.)
• No group chat
  Messaging is only possible between 2 users. Some handsets offer the possibility to send the same message to multiple receipients, however there is no way for the receiving party to determine to which people the message was addressed, prohibiting a “group discussion”.
• No re-retrieval of messages
  Once the message is delivered to the handset, it is no longer stored by the Message Center on the mobile operator’s network. This means that the message can never be re-sent to the user in case the handset was erased or the messages it stored were otherwise lost.
• No device-independent reading of messages
  A message can only be sent to a mobile phone number, which is always assigned to a specific cell phone. When a user has two cell phones in use at the same time (for example a private phone and a corporate phone), he is unable to retreive the messages on the other phone. When a user has no access to his phone for some reason, there is no way to read the SMS message sent to him on other devices either, like on a (public) computer.

Besides these obvious disadvantages, there are some other limiting factors in the way SMS text messaging is implemented by most telecom operators and handset manufacturers, but which are not specifically related to the SMS specification.

Limitations of the general implementation of SMS text messaging:

• Very high costs
  For mobile phone operators, SMS text messaging became the cash cow of their services. Pricing ranges from a few cents up until 10, 20 or even more cents per message. Measured in terms of “cost per megabyte”, SMS text messaging is by far the most expensive data communication protocol currently available.
• Even higher roaming costs
  In Europe, expensive data roaming costs kick in as soon as you pass the borders of telecom operator’s native country. Operators charge up to 5 times as much for sending a text message abroad, compared to the local fees. (Roaming does not apply to the various states within the US, however most American operators have the habit to charge for incoming text messages as well, which is not the case in Europe.)
• Limited message storage space
  Most handsets traditionally offer a limited space for the storage of messages. Since most basic handsets offer no possibilities to transfer these message to a computer as a form of a backing up, and operators can not re-send messages that were delivered before, this requires selective deletion of messages by the user, and eventually the loss of messages.
• Extremely un-intuitive user interface
  Most basic cell phones only offer a numerical keypad and a small display, which means that the user is required to perform text entry using 9 numerical keys (!). To me personally, having to enter 26+ different letters and symbols by using only 9 keys is a demonstration of the worst possible user experience possible. Some handsets offer a form of predictive text entry, but this still requires a great deal of attention of the user on accepting, denying and modifying the suggestions offered by the handset.

I have often wondered why, instead of using a dedicated message develivery mechanism based on cell phone numbers, the creators of the SMS text messaging protocol have not relied on e-mail based addressing instead. This would of course eleminate the first advantage that I mentioned above, in that every cell phone user is reachable for text messaging by just using their cell phone number. However, I think the advantages would have clearly outpaced this disadvantage, such as unlimited message length, the possibility to add other documents such as pictures, the possibility to read the messages on other e-mail capable devices, the capability to communicate between more than 2 people and the ability to re-retreive lost messages from the e-mail server. But I do recon the fact that when SMS was being developed (in the mid 80s), its creators were faced with the technology limitations of that time (which were mainly related to the high cost of sending data over the network, and the high cost of storing data on an electronic device).

The biggest problem with SMS as we know it today, is that it was developed about 10 years too early. Surely, a lot of the limitations of the SMS specification would not have been there if the whole specification would have been written today. Sadly however, with an installed based of more than 2 billion users as stated above, there is no way the specification can be changed now without breaking compatibility.

In the spirit of this blog’s core interest, let’s have a look at how SMS is implemented on the iPhone. I think Apple solved as many of its shortcomings as possible. For starters, it eliminates the ackward 9-key text entry method by replacing it with a full Qwerty-keyboard on its touch display, with a pretty smart auto-correction method built in. Due to the fact that predictions are not based on the entry using 9 keys, but on the placement of (independent) letter keys relative to each other, a much more intelligent correction system could be developed. And furthermore, as the basic application of SMS texting is sending short messages to one person and vice versa, often resulting in “mini-conversations” between the two users, the iPhone logically orders the sent and received messages per user. Oddly, most cell phones just place all the incoming messages in chronological order in an “inbox”, and put the sent messages in an “outbox”. This completely eliminates the possibiity to see an ongoing conversation between you and someone else, without doing a lot of back-and-forth navigation on the phone.

Also of note are some specific choices and trade-offs that Apple made in its SMS application on the iPhone. For starters, it does not display the number of characters left when entering a text message. Whether this is the result of negotiations with the cell phone carriers (because, after all, this more easily results in the user sending more than one 160-character message resulting in higher revenue for the operator), or an eastetical choice based on limiting the number of “status feedback” on the display, is anyone’s guess. I know that some users would welcome the ability to having a character-couter though.

A very clear choice that Apple made is to not include an MMS application. MMS (Multimedia Messaging Service) is an addition to the SMS standard, which, albeit the fact that the technology is now over 5 years old, is not quite as common and popular as SMS. Using MMS, users can send pictures taken with the phone’s camera to other cell phone users capable of receiving MMS messages. The iPhone can neither send, not receive those messages. I think Apple made a deliberate choice here. The iPhone’s built-in e-mail client is far superior to anything else on a phone, and supports rich messages, including pictures. This allows for users to send messages with text and pictures to other users via e-mail, and hence eleminates a lot of the limitations of MMS. Of those, the very high costs and, again, a message size limitation resulting in scaled down, low resolution images are the most obvious. And like SMS, MMS is also device and phone number dependend, limiting users from accessing the message and the pictures on other devices but their phones. I guess that, as long as the market is not crying out fool for an MMS application on the iPhone, Apple hopes that at least for rich messaging, we use the obvious, cheap and feature rich platform that has proven itself for decades: e-mail.

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.

But let’s go back for a second to the whole Apple-elitist thing. I have to admit that there is one aspect in particular that makes me proud to be an Apple-user: I choose to use an Apple computer. After all, statisitcally based, it would have been logical that I picked up a Windows PC from one of the local shopping malls, just like 90% of computer users. Instead, I made a comparison between the offerings of generic PC vendors shipping Windows machines, and the Mac. And, at least to me, the Mac won that comparison by a large, large margin. It’s beyond the purpose of this post to state why the Mac is the superior platform for me (but sure, this includes Apple’s breathtaking visual design of the operating system, the stability and security of its OS underpinnings, the world’s best industrial design, but most imporantly  the tight integration between all hardware, operating system, software and Internet service components that provide me with this exceptional and unmatched user experience). So does the knowledge that most people select their computer based on price or raw hardware specs instead of doing a little investigation on what system works best for them make me an Apple-elitist? If so, then yes, I think I have to admit that I am more of one than I initially thought.

The whole subject came up to me again lately, when I was talking to one of the many people I already know who own an iPhone. This particular guy, a young student in his early 20s, known to not be an Apple-fan to say the least, also recently aquired an iPhone 3G. He came up to me and spoke these historical words: “This time, I went with the Nintendo Wii among mobile phones: the iPhone. You know: the least capable, but most popular device at the moment”.

Yes, I’ll give you a moment to read this one over again. I know it left me baffled for a few minutes.

He choose the iPhone because of the notion that among many young people, your cell phone is a very important status symbol. The size of the thing (with the general rule: the smaller, the better), its color, the sound it makes when someone calls you or the funny way you can flip, slide or otherwise open it are frequent topics of conversation between young people these days. And appearantly, the fact that a phone gained an enormous hype for being “the coolest new thing in town” also counts. Not only did this guy not recognize the fact that the iPhone’s interface and user experience is years ahead of even its closest competitor, he even labeled the iPhone as a limited device.

While talking some further to him, things became clear to why he had this bold opinion. The iPhone does not record video clips, it does not allow you to exchange ring tones with other mobile phones via Bluetooth, but most of all, he had gripes with the fact that he had to use iTunes to manage the media on the device. As he told me, with his previous phone he could just mount it as a hard drive, and then manually move the required files over. And then he showed me his music collection on the iPhone: all single tracks from different artists, and all without cover art. It quickly became clear to me that the guy pulled all of his music from P2P networks instead of ripping CD albums, let alone buying music trough the iTunes Music Store. He didn’t care about albums, he just wanted to hear that one particular song that he knew. And I had to admit: his music collection and the way the iPhone interpreted them all as “single track albums” looked like a mess.

Of course I could have told him that iTunes is one of my most appreciated pieces of Apple software, due to its excellence in managing music, the ways that I can search my music based on various criteria and how my collection presented to me. I could have explained to him that, in an Apple universe, you actually manage music, not computer files. And that once you music is neatly ordered in iTunes, it not only provides you with the best music jukebox software available on a computer, but also neatly offers your music in any other place it might be usable, such as on your iPod, on your iPhone, accessible trough a wireless streaming station (like the AppleTV or Airport Express), but also in your movie creation software to select as the soundtrack, in your photo viewing software as background music or in your web editor for inclusion on your web site. And again: everywhere you have access to the same neat organization of your music, and nowhere you need to dig trough piles of unordered music files. It is exactly what makes the Apple experience a joy to me (and a lot of other Apple-fans), and at the same time it is what bothers people who are not willing to take the plunge and stick to their computer-skill-based ways of working on their PC.

It is clear to me that the iPhone is by far the most innovative, easy to use and well integrated combination of a phone, a music player, a gaming unit and an Internet access device that is available today. And this will probably remain so for a long time to come. However, for some people, the advantages of the Apple way of working do not stack up to the things they seem to find important and which are lacking, such as teenage-driven applications like expensive, non-email based (MMS) picture messaging, bluetooth wallpaper and ringtone exchange, the ability to record barely watchable 1 inch high and 2 inch wide video clips or in this case the capability to move single media files lacking any identifiable meta-data over by hand.

This leads me to the conclusion that the iPhone might not be for everybody. I think at least you have to make a solid choice based on your needs when you embrace a new piece of technology into your life, especially if it’s something you plan on using each and every day like a smartphone. Picking something just because of its cool-factor is, in my book, one of the least smartest things you can do.