I upgraded my iPhone to 2.0 and downloaded a few of the apps. Glad to see my favourite mobile app - Shazam - now available on iPhone, including links to iTunes, which is just what I wanted.

Immediately, there are a couple of early trends to notice:

1. Many of the iPhone apps are photo and location enabled, even for services that didn’t previously have an overt location or photo attribute. Why? Just because it’s there and it’s easy to do. This is fantastic and is exactly how the mobile ecosystem should work. Might this be the tipping point for ‘photo messaging’ (previously known as MMS) and location services? Perhaps. I’m still using an original iPhone, so don’t yet have the pleasure of GPS, but I remain convinced that users will get used to ‘GPS enhancement’ of applications and there will be no turning back - goodbye cell ID!

2. Many of the Web 2.0 browser-only services out there have opted to develop a native iPhone app. This is partly a marketing strategy, exploiting the ‘iPhone effect,’ but it will be interesting to see how the browser versus SDK struggle plays out on the iPhone, if there is a struggle. The plain fact is that a native application offers a nicer user experience. However, some of these services have released only an iPhone app, so it isn’t really indicative of the general app versus browser decision tree because distribution and fragmentation aren’t an issue if you’re only developing for one device.

What might the future hold?

I think that Apple will focus on improving the browser experience still further, incorporating features like offline storage and widgets, tipping the balance back towards web-based apps in terms of a technology play, even though there is a stronger business interest in the apps store. However, one possibility here is the concept of ‘packaged’ web applications to get extended browser features. In other words, think of a wrapper or launcher application downloaded via the store that uses the browser as the main UI and uses the SDK environment for utility features, such as offline storage. This architecture would work, its main advantage being that apps providers (and therefore Apple) could charge for access to applications via the apps store, should they want to.

This does pose the question as to why should there be a different commercial model for using applications that are installed versus ones accessed via a browser. Of course, there is no logical reason for the difference, apart from the fact that applications are downloadable and therefore accessible via the iTunes ecosystem, including its payment mechanisms. One has to ask whether or not Apple might consider offering a payment API in the future for browser applications (e.g. subscriptions for premium services).

[This blog has moved to here]