When you log into your computer at home and visit Facebook, most people type “facebook” into their browser. Some people may click bookmarks in their browsers. You certainly won’t find and open version 1.1 of the Facebook desktop app for OS X (no such thing exists). However, on our internet-enabled mobile devices, we behave completely differently. Curiously, we’ve trained consumers to expect services to be distributed on mobile devices via apps rather than the open web. Why is it like this?

Advantages of Mobile Web

• Write once, run on any device. In theory. In practice, this is not always smooth due to the different screen sizes/interface quirks of devices on the market. But overall, it’s a net-win for the businesses, maintaining a single codebase that works across multiple platforms.
• Mass distribution. Again, in theory. If something is on the open web, then anyone can access it anytime, but accessibility is not the same as coverage — what good is open distribution if consumers are searching for your service in the app store anyway?
• Play by your own rules. When offering services on the open web, your business doesn’t need to agree to terms of service, no middlemen taking a percentage of your revenue, and no hand of God to provoke and see yourself shut down on a whim. That’s not the case for those who play in walled gardens like the AppStore or Playstore.
• Instant deployment. found a mistake? Patch it and deploy. Now it’s fixed for everyone. With the app model, bugs are only patched when the distributor approves your patch, and crucially, when consumers actually gets around to update it.

Advantages of Mobile App

• Access native APIs. This means your app can do things like take a picture with the device’s camera or receive push notifications. Accessing device capabilities is a huge stumbling block, and it’s probably one of the main reasons why businesses create native apps instead of web apps. If an app like Instagram can access the camera API, can it be 100% web-based? Absolutely yes, it could be better. It’s unfortunate that so many businesses have had to make this decision.
• Consumer bias. We’ve trained consumers to look for things in the app store. When you download something from the App Store, you press a button and a shiny icon appears on your home screen. This is good. Web bookmarks are less glamorous, and while there are ways to place bookmarks on the home screen, this is not a common consumer behavior and more of a power user behavior.
• Profit. All parties in the app economy have an easier path to monetisation than the open web. One-click buying means ultimate ease of use for consumers without having to reveal credit card details to anyone – and app developers still have high conversion rates. App economy owners demand payment of transaction fees. It’s a totally smoother experience compared to the clunky buying process of the open web, which is completely different depending on the website you’re on. This also means that app economy owners have direct incentives to further improve the app economy experience, and indirectly attract developers away from the open web.

Popular applications require access to device APIs. The Camera. Your photo album. If this means app developers can sidestep their app store economy and deploy near-native apps to the open web, then assuming device makers are reluctant to provide web-based access to device APIs, this is not an option Huge logical leap. Too much money and opportunity will be lost. There are also security concerns, as end-device manufacturers don’t want bad things to happen to their customers (like visiting a malicious website, your contact book being deleted, etc), so a regulated environment is still the safest.

I wonder if there is a happy middle ground for developers and device manufacturers. What if web-based device API access is subjected to license fees and agreements? The criteria for profit and security will then be met, and developers are free to take advantage of the open web and the advantages of native APIs.

One other thing that will be harder to change is consumer behavior. In the mobile web of the future, you might be able to build Instagram entirely as a web app on Instagram.com, and any user on any device can log in and take retro photos with their device’s camera.

If all is lost Ultimately, consumers want to find your app in the app store, download it and get the shiny new icon.

It’s Apple’s (or Android’s) business prerogative to not welcome web apps in the app store. Why put scrappy web app developers who are independent of the app store economy in the spotlight when there are so many other $1 apps with features like in-app purchases and subscriptions? The same goes for shiny icons, which are very important for creating a sense of ownership and retaining consumers – consumers can’t go to your mobile website and click “download” to “get” the web app and shiny icons. They have to go to Options > Add to Home Screen (who does that?) or Options > Save bookmarks or something, not just the word “download” or “install”. Sadly, there is no API for launching home screen additions.

Conclusion

In order to align the interests between device manufacturers and web developers, there needs to be some mutual benefit. Clearly, accessing native APIs in web-based applications will open up plenty of opportunities for developers. Device manufacturers should seek to achieve this for their own benefit. Regulated API usage could be a step towards this goal. Remember, it’s not just hardware features that developers can benefit from access. I’m sure developers will be crazy about a one-click payment API available on the open web that simply uses the mobile device user’s app store credentials. This negates some of the advantages of the open web (such as “playing by your own rules”), but for traditionally fragile operations like payments, as a developer, I’d accept convention over configuration any day.

I hope in the future we will see something called the AppStore Web API. It will provide web-based apps with native API access to device features such as the camera, and will provide web-based apps with a plug-and-play payment system using App Store credentials. Everyone wins.

Oh, and if Apple, Android, and Blackberry could make it an open common standard, then we wouldn’t have to write device-specific code — but I know I’m dreaming.