With the recent announcements of the Windows 8 App Store and the Facebook App Center, it seems like we are a couple of years out from everyone doing a 180 on the love fest for the app. I think the bubble is going to burst and hackers will lead a revolt against the App. From the perspective of Facebook or Microsoft or anyone else, it totally makes sense to create your own App Store right now so that you can monetize traffic using something other than ads. It is just not a sustainable trend in the long run.
The Problem
It is one thing to have your HTML-based website for most visitors and then an iOS app and/or an Android app for some mobile customers. Even building and maintaining those 2 – 3 UI clients is somewhat of a pain, but not totally unattainable even by small startups. The issue comes when there are a dozen or more popular App platforms that require the creation of completely different UI clients. It is the 1995 Client-Server wars all over again. It seems crazy that we are going backwards asking businesses to create separate clients for different types of platforms. Sure, no one is holding a gun to your head to build apps on every platform out there, but which ones do you choose? Even if you have the resources to build an app for each platform, it will be extremely expensive and difficult to maintain a dozen or more different front ends.
The Solution
What is wrong with the original solution to this problem, HTML? Yes, it is not a viable solution today because platforms have gone down the path of creating their own native app environments. There is no reason why it can’t and shouldn’t be the solution to this problem in the future. The HTML5 specs that are starting to get integrated into browsers will be a good start with WebSockets, Canvas, etc. A couple other things will be needed, however, in order to make HTML as a viable replacement for all the disparate app platforms:
- Native API Standards – Just like how HTML5 now had standards for things like multiple file transfers, there needs to be a common set of JavaScript APIs for native device functionality such as location, spectrometer, etc. In fact, since devices can have custom native functionality, there will likely need to be the basic API standards plus an extensible standard for vendors to utilize with device functionality that is custom.
- Security Standards – The use of JavaScript on a client has traditionally been heavily restricted for security concerns. The more power that is given to JavaScript, the more browsers will have to improve their ability to secure the native device. To that end, I don’t think it would work to simply allow any web client to automatically have access to a native device API. Rather, there will likely need to be a set of standards that the web client adheres to and potentially an explicit approval by the user to run.
- Speed and Visual Appeal – Using the most recent browsers, you can create a web application that is nearly as fast and look nearly as good as any native application. I think any difference that exists today will soon be negligible as browsers continue to advance.
- Money, Money, Money – Like many things in life, the crux of the issue really comes down to money. From a pure technical perspective, using HTML in place of all native apps is viable and makes a lot of sense. The problem really is that App Stores right now are cash cows for bigger companies. The key is that the application creator and the platform owner still need to make money somehow. I don’t necessarily have a solution for this, but it is something I will consider in a future blog post.
Alternative Solutions
Even though HTML makes the most sense, it may not end up being the ultimate answer to the app proliferation issue. Something will eventually need to happen, though, so a couple of alternative solutions that may also be viable:
- App Generators – Instead of having developers create one type of application that can be deployed on multiple platforms, you could have platform providers create App Generators that automatically translate applications from one or more common technologies into their native app format. So, for example, you would create one web application that would then be transformed by Apple into an iOS app, Google into an Android app, Microsoft into a Windows 8 app, etc. There would still need to be common standards created across the industry in order for this to work but it would allow individual companies to continue to run their own App Stores.
- The End of HTML – Instead of HTML eating all the Apps, what if it was the other way around? Once again, there would still need to be one common standard created because that is the core problem we are talking about. However, perhaps we get rid of JavaScript, HTML and CSS in favor of something else that becomes the de facto standards for application development. I sort of see this as a long shot because of the strong foothold HTML already has, but perhaps HTML can incrementally morph into something else so that it eventually looks and feels more like a native app from the programmers perspective.
I know there are a lot of people out there that love developing iOS or Android apps, so I would love to hear your thoughts on this. I don’t frankly care what the ultimate solution is as long a we figure something out (hopefully sooner rather than later).




