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.

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.