The Future of Mobile is the Web App
By Zef Hemel
- 6 minutes read - 1276 wordsIt 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.