The (Eventual) Return of Mobile Applications to the Web

I don’t think that I’m overstating things by saying that the web has changed the world. There is no doubt about it in my mind. The past 20 years or so have been a continuous stream of innovation. We’ve seen the web transform from a simple platform used by government agencies to share information into something whose capabilities seem limitless. Streaming media, e-commerce, full fledged office applications, real time news from more sources than you can imagine, and much more. It truly is amazing what we’ve been able to accomplish with a platform whose original purpose was to share static documents.

The Rise of the App

However, the web does have limitations. One such limitation has long been the ability to interact with the hardware you are using to browse the web. Over the years technologies have been developed to help with this limitation (Java, Flash, etc), but I see those technologies as extensions the web, and not part of the web itself. Those technologies have carried their own set of drawbacks as well, such as requiring the installation of client software, performance issues, and security vulnerabilities.

Nowhere is this limitation more obvious then in the mobile arena. Today’s smartphones are amazing. You have a camera, a GPS, a MP3 player, a web browser, oh…and a phone too, all wrapped up in one device. It’s like walking around with a tiny computer in your pocket. But currently, the web is only able to utilize a tiny fraction of this functionality. Its document centric design, which has been stretched, twisted, and pulled in directions that its creators never could have imagined, appears to have finally reached its limit.

In addition to hardware access limitations, may web applications were not designed to be viewed on a device with such a small screen and no mouse. It can be very difficult to view a 900 pixel wide web page on a screen that is only a couple of inches wide. And while you can zoom in over certain areas of the page, not being able to view and interact with the page in its entirety introduces some big usability issues. Also, many web applications rely on mouse over events to interact with the user. Drop down menus are a perfect example of this. There is no mouse on today’s touch screen smartphones, making these sites very difficult to navigate when viewed on a mobile device.

These limitations have given rise to “the app”. The app, a native application that runs on the smartphone itself, it not a new idea. Smartphones have been around for quite some time, and these phones have always had native applications. But only recently did Apple change the game by providing independent application developers with a way to easily sell and distribute their applications. As a result, there are now hundreds of thousands of applications out there for various platforms, many of which do incredible things with the hardware on the mobile device. Things that simply could not be done via a web application.

The rise of the app came on so quick and so strong that many began to ask if the app killed the web. This is certainly a reasonable question to ask. A native application has access to all that the device has to offer; the camera, the GPS, and yes, even the web. Apps are also designed to run on a mobile device. So, the text is easy to read, the controls are easy to use, and the user experience is generally much better than a web application.

Problems with Native Applications

While native applications have full access the the hardware and address many usability issues that web applications have on mobile devices, they introduce a new set of problems.

Some platforms charge program fees that must be paid to develop applications for the particular platform, even if you plan on creating a free app, or an app you never plan on releasing. While generally inexpensive, it is a new cost that web application developers have never had to deal with.

Deployment is more complicated for native applications than it is for web applications. Even though Apple’s App Store, Google’s Android Market, and other application marketplaces have made the distribution and installation of native applications much easier, it still does not compare to the ease of deployment of a web application. On the web, you have complete control over what you deploy, when you deploy it, and to whom you deploy it to. This is not the case with native applications, which can be subjected to drawn out, illogical review processes before being made available to the public. If you have a critical bug that needs fixing, or you’re trying to beat your closest competitor to market with some killer new feature, this process can be agonizing. And, even after publishing the latest version of your application to the marketplace, there is no way to force your users to upgrade. This could leave you supporting older, buggy versions of your application, or maintaining old services still in use by those old versions of the application.

If you charge for your application, distribution of that application is not free, or even cheap. Apple’s App Store, Google’s Android Market, and Palm’s App Store all take a 30% cut of the sale price of your application. Some may argue that this is a small price to pay for distribution to such a large audience. However, the audience is larger on the web, and distribution is piratically free.

The development of native applications is largely platform dependent. Programming languages and APIs vary significantly from platform to platform, making it practically impossible to develop a single application capable of running on multiple platforms. Cross platform development tools, such as PhoneGap and Rhomobile, address this issue by allowing you to develop native applications using HTML, Javascript, and CSS. However, these tools don’t address the other issues mentioned in this section. In addition, you also run the risk of some App stores outright banning applications not built using their tools (looking at you Apple). Though Apple has recently softened their stance on this issue, I would not rule out future restrictions.

A Mobile Web App in Native App’s Clothing

The sad part is, the majority of today’s apps don’t need to be native applications. They do nothing to utilize the features exclusive to native applications. Most of these apps simply fetch data from a web service and display it nicely to the user. Some take advantage of the GPS, or store data locally on the device. However, these apps could just as easily be mobile optimized web applications.

“Look and feel” is often cited as a reason to develop a native application instead of a mobile optimized web application. Though this argument certainly has its merits, there are plenty of options out there to help make a web application look and feel great on a mobile device. A bit of mobile optimized CSS (fluid layouts, properly sizing images, etc) can go a long way in terms of making a web application look awesome on a mobile device. And, there are projects out there, such as jQTouch, jQuery Mobile, and Sencha Touch that can help your web application look and feel more like a native application if that’s what you are looking for.

Web applications also have access to a few features that, just a short time ago, were only available to native applications. The device’s location is accessible via Javascript’s Geolocation API, eliminating the need to build a native application solely for access to the device’s GPS. Web applications also have access to persistent local storage on the mobile device via the HTML5 Web Storage API. While the Web Storage API falls short of a being a true database (it’s more like a hash, allowing you to store key/value pairs), it can go a long way in addressing the storage needs of most applications.

A good comparison between mobile apps and native apps can be found here.

Making the Web a Friendlier Place for Mobile Web Apps

The mobile web is growing by leaps and bounds, but much work is needed in order to make the web a friendlier place for mobile web applications. The W3C realizes this, and have started a Device APIs and Policy Working Group to create a specification that will allow web applications to access device hardware and services (contacts, calendar, camera, microphone, SMS, MMS, email, etc) in a standardized way. The specification is far from complete, and it will likely be quite some time before these APIs have been implemented by the various web browsers. But, the mere fact this is being worked on is a great sign for the future of mobile web applications.

There are non-technical hurdles preventing the web from being a more mobile friendly place as well.

First, browsing the web on a mobile device isn’t a very pleasant experience right now. Having “real” web browsers on mobile devices, such as WebKit, have gone a long way in fixing this. However, many sites are not optimized for mobile devices, making them difficult to use. I think this prevents the majority of people from browsing the web on their mobile device like they would on their desktop or laptop computer.

Second, we’ve been told for years that “There’s an app for that”. Personally, when I’m looking for a mobile application take care of some task, the first place I hit is the Android Market. Having one place, where apps are broken up into categories, and searchable, makes finding the right app for my needs incredibly easy. There is no such place for web applications. This used to be the case for desktop applications as well, but not anymore. The Ubuntu App Center, and now the Apple Mac Store, aim to serve the same purpose as the App Store or the Android Market, but for desktop computers instead of mobile devices. Perhaps it won’t be long before we see a categorized, searchable index for mobile web applications as well.

Conclusion

Opting to build a mobile optimized web application instead of a native application is not a new idea. However, the idea has been slow to catch on, due to some of the reasons I’ve outlined above.

Obviously, even after the Device APIs being worked on by the W3C have been implemented, there will always be a need for native applications. Games that need hardware accelerated graphics, or apps with complex user interaction will most likely stay native applications for the foreseeable future. But I hope that the other applications, especially the applications that are simply a front to a web service, are re-born as web applications at some point in the near future. For these apps, it’s time to come home.