The Future of Mobile is the Web App

By Zef Hemel

April 27, 2010 - 6 minutes read - 1276 words

It was January 9th, 2007, a highly anticipated date for many. Steve Jobs got on stage of MacWorld and, for the first time, pulled an iPhone out of his pocket. He showed off the device and spoke: “We figured a really great way to develop applications for this amazing device, and we call them ‘web apps’.” Today, three and a half years later, the users of this amazing device go crazy buying and downloading native applications from a locked-down AppStore. What happened? Where did things go wrong?

The development of mobile applications has always been a complex and expensive endeavor due to the large number of different mobile phones (with different screen sizes, processor speeds, color or greyscale screens) running different software. While J2ME promised to be the unifying platform, it did not work out that way due to wildly diverging implementations of this “standard”. Therefore, as a mobile developer you had little choice than to develop separate implementations for a huge amount of phones.

But then the iPhone gave the struggling category of smart phones an enormous push. Smart phones quickly converged toward iPhone-like form-factors. They all started to have large screens operated with touch, GPS, a considerable amount of storage and 400+ Mhz CPUs. Examples include the iPhone, Android devices, BlackBerry, Palm Pre and newer Nokia devices. While this type of phone is still a minority in the mobile space today, its market share is rapidly increasing and it doesn’t take a stretch of the imagination to believe that within a few years everybody will own a device like this.

While smartphone hardware converged, its software did not. While HTML and Javascript was initially the way to develop software for the iPhone, developers weren’t satisfied and demanded to build native apps. They got what they wanted. Today, iPhone native apps have to be developed using Objective-C or C. Applications for Nokia Symbian phones are developed using Java or C++, for Android using Java, and Palm Pre developers use HTML and Javascript. It is pretty challenging to share code between these platforms. Adobe briefly attempted to turn Flash into the platform to rule them all, but Apple shot them down by changing their developer agreement to mention that applications need to be originally written using Objective-C, C or Javascript. With this decision, Apple essentially forced the arm of many developers: either you develop for iPhone or you develop for another platform, but you can’t do both at the same time. And even if you decide to develop for iPhone you rely on Apple’s approval of your applications for its AppStore; Apple can decide to reject an application for any reason, or pull it off the AppStore any time it likes.

But the obvious alternative remains. After Google’s Google Voice application was rejected from the AppStore, they redeveloped it as a web application. However, it is not just to work around Apple’s rejection of Google applications (Google and Apple do not seem to get along so well lately). Google also develops other major products as mobile web apps, including Gmail, Google Buzz and maps.

In an interview, Google’s Vic Gundotra, Google Engineering vice president, said Google sees the future of mobile applications on the web:

He claimed that even Google was not rich enough to support all of the different mobile platforms from Apple’s AppStore to those of the BlackBerry, Windows Mobile, Android and the many variations of the Nokia platform.
“What we clearly see happening is a move to incredibly powerful browsers,” he said.
“Many, many applications can be delivered through the browser and what that does for our costs is stunning.
We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.”

Still, Apple initially launched web applications as the way to develop mobile applications on its platform. Why did it not work then?

There are three obvious reasons that can be identified:

The state of hardware. The original iPhone hardware was slower than today’s hardware. The use of web technologies comes at a cost and will always be slower than native code.
The state of web standards. HTML5 did not exist yet (a first draft was published early 2008). Web applications had no off-line capabilities (meaning applications had to be redownloaded every time they were invoked), no local data storage, no access to position information.
Not close enough to “the metal”. Developers wanted to build 3D games, applications that used other phone applications such as the calendar, SMS and so on. There was little integration with the operating system beyond the ability to link to a phone number. Interestingly enough, native apps on the iPhone at this point still have only very limited ways of integrating into the iPhone OS.

But it’s 2010, what is the state of the mobile web today? Is it a more viable alternative to native applications? While it is very difficult to develop a web application that feels and behaves completely like a native application, it is possible to get very close, as Apple itself has proven, John Gruber found out:

It ends up there is a company, however, that has developed an amazing iPhone web app framework which:
Completely hides the address bar, even when running not from a saved-to-the-home app icon, but within a page in MobileSafari itself.
Allows for fixed-position toolbars that never budge from the top when you scroll.
And: sets its own scrolling friction coefficient, allowing you to fling long lists.
The company behind this web framework is Apple. And the framework is apparently named PastryKit.

The only known application that uses PastryKit is the iPhone user manual (view on the iPhone) and uses a number of HTML5 features, including the ability to store data locally on the device in a SQL database and the ability to install an application as an offline web app. Both HTML5 features that work on Android, Palm Pre and likely on future versions of BlackBerry as well. HTML5 also specifies a Geolocation API that is supported by Android, iPhone and Palm Pre. In addition, SVG and Canvas support enable (2D) drawing and animations. Touch input is handled through touch events. And in case you were wondering, yes, Apple developed a similar framework for the documentation of the iPad. So the question is: what can’t a web application do today?

That question applies to mobile as it does to the desktop. What can’t a web application do on the desktop? It does not integrate well with the OS. It cannot access arbitrary files on the file system (although iPhone native applications cannot do that either), it is not very suitable for advanced graphics (although it should be noted that Apple’s impressive iAds demo advertisements are implemented with HTML5). While a web application’s abilities are limited, we still move more and more of our daily workflow to the web. Why would the same thing not be true for mobile? Many mobile applications we use today are glorified websites: Foursquare, Twitter, Weather, TV Guides, Facebook — they are all thin wrappers around web services.

I can’t see another way than mobile phones and other touch screen devices — like the iPad and undoubtedly dozens of other touch tables that are about to come out — to eventually move to the web. Just like happened on the desktop. It only makes sense. Mobile applications would become portable and cheaper to develop. And you’d finally have your “f5 software upgrades” on your phone, no need to wait 6 weeks for an Apple employee to get around to it.

Just wait and see.