When you log onto your computer at home and go to Facebook, most of you will type "facebook" into your browser.  Some of you might click a bookmark in your browser.  You certainly don't locate and open up the Facebook Desktop app Version 1.2 for OS X (such a thing does not exist).  However, on our internet-enabled mobile devices we behave quite differently. Strangely, we have trained consumers to expect the distribution of services on mobile to come via apps instead of the open web.  Why is this?

• Write once, run on any device.  In theory.  In practice this is not always so smooth thanks to different screen sizes / interface quirks of devices on the market.  But overall this is a net-win for the business, maintain one codebase that works across multiple platforms.
• Massive distribution.  Again, in theory.  If something is on the open web then anyone can access it at any time, but accessibility is not the same as reach - what good is open distribution if consumers are searching for your service in the app store anyway...
• Play by your own rules. Providing a service on the open web there are no terms of service for your business to agree to, no middlemen to give a percentage of your revenue to, and no hand of god to anger and see yourself shut down on a whim.  The same cannot be said for those playing in walled gardens such as the app store.
• Instant Deployment. Found a bug? Patch it and deploy the update.  Now it's fixed for everyone.  With the app model, the bug is only patched when the distributor approves your patch and, crucially, when a consumer actually gets round to downloading it.

• Access to Native APIs. This means that your app can do things like take a picture with the device's camera or receiving push notifications. Access to device functionality is a huge stumbling block and probably one of the main reasons businesses create native apps instead of web apps.  Could an app like Instagram be made 100% web-based if it had access to the camera API? Absolutely yes and it would likely be better for it.  That so many businesses have to make a decision like this is unfortunate.
• Consumer Bias. We have trained consumers to look for things in the app store. When you download something from the app store you press a button and get a shiny icon on your home screen. This is good.  Web bookmarks are less shiny and although the means exists to place a bookmark on the home screen, it is not a common consumer behavior and more of a power-user action.
• Profit. All parties to the app economy have a somewhat simpler path to profit than the open web. One-click purchasing means consumers have ultimate ease-of-use and as a bonus don't have to give up credit card details to anyone - conversions stay high for app developers. The app economy owner claims a transactional fee.  It is an altogether smoother experience than the clunky purchasing flows of the open web which are entirely different depending on which site you are on.  This also means there is a direct incentive for the app economy owner to further improve the experience of the app economy and indirectly lure developers away from the open web.

Popular apps need access to device APIs.  The camera.  The photo album.  It's not a giant leap of logic to assume that device manufacturers would be unwilling to give web-based access to device APIs if it means that app developers can sidestep their app store economies and deploy near-native applications to the open web. Too much money and opportunity would be lost. There would also be some security concerns since at the end of the day a device manufacturer does not want bad things to happen to their customers (e.g. visit a malicious website, your phonebook gets deleted), hence a regulated environment is the safest.

I wonder though if there's a happy middle ground for both the developer and the device manufacturer.  What if web-based device API access was regulated with a license fee and an agreement? Then both the criteria of profit and safety would be fulfilled and the developer is free to exploit the advantages of the open web with the advantages of native APIs.

One thing that's going to be much harder to change is consumer behavior.  While in the mobile web of the future you might be able to build Instagram entirely as a web app that sits at Instagram.com and any user on any device can log on and take retro photos with their device's camera... all is lost if at the end of the day the consumer expects to find your app on the app store, download it and get a shiny icon.

That web apps are not welcome on the app store is Apple's (or Android's) business prerogative.  Why give scrappy web app developers who are independent to the app store economy a piece of the spotlight when there are so many other $1 apps with in-app purchases and subscriptions etc to feature? Same goes for the shiny icon which is tremendously important for creating the sense of ownership and retaining the consumer - a consumer can't go to your mobile site and click "download" to "get" the web app and shiny icon.  They have to go to Options > Add to Home Screen (who does that??) or Options > Save a Bookmark or something other than simply the word "download" or "install". There's sadly no API for initiating a home screen add.

For interests to be aligned between the device manufacturer and the web developer, there needs to be some mutual benefit.  Clearly, access to native APIs in a web based app would create massive opportunities for developers. Device manufacturers should seek to enable that to their own benefit.  Regulated API use could be one step towards that. And remember it's not just hardware features that developers could benefit from accessing.  I am certain that developers would go crazy for a one-click payments API that can be used on the open web, that simply uses the app store credentials of the mobile device user.  This negates some of the advantages of the open web (e.g. "play by your own rules") but for traditionally brittle actions like payments, speaking as a developer I will accept convention over configuration any day.

I am hoping for a future where we see something called the App Store Web API. It will provide native API access to device features (such as camera) for web-based applications and it will provide a plug-and-play payment system using App Store credentials for web-based applications.  Everybody wins.

Oh and bonus points if Apple, Android and Blackberry can work on making it an open, common standard so we don't have to write device-specific code :)