The great things about mobile web applications

Developing an application for mobile platforms can be done in two ways, as a native or web application. Based on its purpose and target audience, each method has its advantages.

Developing using the platform’s native language offers great performance and access to the device’s full list of functional API’s. On the other hand, you need to develop that particular application using a different language for each targeted platform. Android has Java, iOS has Objective C, Windows Phone has .NET, just to mention a few.

A web application in the context of mobile platforms is a normal browser based application that’s been optimized to run on a mobile device. There are ways of making this mobile version of a website very similar to a native application in terms of user experience. Actually, user experience I believe to be one of the main advantages of mobile web apps.

Let’s take a look on what a mobile application is, its structure, the downsides of developing one and the future of the ecosystem.

Characteristics of mobile web applications

Based on the client’s needs, such an app can be distributed through a platform’s application store and can have access to the device’s hardware functions. This can be achieved by building it as a native app using a wrapper library like PhoneGap. It acts like a bridge between the platform and the application, enhancing its functionalities. You can even make it an offline app, offering the client the functionality he needs when in an area without Internet access.

The main downside to web applications is performance loss. You cannot develop performance heavy applications (like games) using a mobile platform’s browser. Or at least not yet. But, if you have a data driven application, I consider this to be the best and fastest method of developing it. Let’s put it this way, most of the applications now present on the Internet (mail clients, document editors, social applications, navigation apps) and even a large part of the current desktop applications can be successfully implemented as a web app. As an example, Google at one point had some problems with Apple in the development of their native iOS Google Voice application (the problem being Apple wouldn’t allow it in the App Store). So, Google went ahead and developed a mobile browser version of their service, and deployed it directly over the web, skipping Apple’s App Store altogether. Also a good example is the new iOS optimized version of Nokia Maps. It’s completely browser-based, and includes support for offline navigation by storing parts of its maps on the device.

Being a web application makes it so much easier to keep it up to date from a development point of view. You can just put the updated files on the server, with no need to resubmit them for evaluation on platform’s application store (compared to the flow of updating a native app). This, however, changes when using a PhoneGap wrapper. There were some issues between developers that used PhoneGap and the Apple App Store people: the people that approve applications to go into the App Store did not completely understand the way PhoneGap works, and refused their publishing. These problems were cleared after PhoneGap explained exactly how things work.

What’s the architecture of a mobile web application?

At Yonder, we developed 2 web applications (you can access a presentation for one of them here) that had a very similar structure.

Our Web Application Structure

The application UI, functionality and page flow are implemented in HTML, CSS and JavaScript, as a normal web page.

We based our UI structure on one of the available web mobile frameworks, jQuery Mobile. This is used for handling the page navigation both visually and logically. This provides a base UI package that helps create applications close to the native look of mobile platforms.

We wrapped all of this into an in-house MVC (model-view-controller) based framework, that provides patterns for quickly adding new pages, communicating with the server or managing all kinds of UI components.

You can add to that support for offline storage, currently present on all major platforms.

In order to have access to some of the device’s functions, we integrated PhoneGap. It exposes an object through which we can interact with the platform. This library also makes it possible to build the application for multiple platforms and distribute them in an application store.

Losing on performance

On the performance level, things don’t look so good. The application can be optimized to move great on all platforms (actually I’ve seen native applications move slower than web apps on BlackBerrys), but not at the same level of user experience. On iOS, which provides the best browser of all the mobile platforms, there are animations between pages, fading for popups and other UI enhancements that provide an excellent feeling. These, however, need to be disabled on Android, where the browser is still pretty good (regarding the amount of functions it supports) but not as fast as iOS’s.We used a JavaScript mobile framework called jQuery Mobile. There are other frameworks that provide the same functionality, one of which is called Sencha Touch. A performance comparison video has been made between a mobile web app implemented using Sencha and a native application. It shows minor differences between the two.

The User Experience (UX)

Native applications provide a native user experience. That means every menu fits into the device’s UI scheme and everything follows a certain pattern established by that particular platform’s UX designers. So your app will look as an iOS app on an iPhone, as an Android app on an Android handset and so on. This isn’t exactly the best thing regarding the overall user experience and I will explain why below.

When creating an application, you design it to look and work best based on its functionalities. Of course, you should align its design to what a mobile app should look like, because there are some user interface patterns proven to work on small displays or touch-enabled devices. By trying to make it work and look best for iOS, you neglect Android, where it should have a somewhat different design, based on their user interface patterns. After all this, you end up having 2 mobile applications for the same service, that look different although they are made by the same company and should be consistent in terms of UI.

This is not a problem when developing a mobile web app. Great UIs can be implemented in a browser, and the application will look and behave the same on all platforms. An app shouldn’t be constrained to a certain look for its menus and buttons, but, instead, follow the creating company’s branding lines (or whatever branding is desired for it). The bottom line is that good design plays a major role in the success of an application.

For example, in one of our applications we had a UI component that looked like this:

iCaress synchronization popup

It is a synchronization popup dialog, that features a circular progress bar. We implemented it using HTML5 canvas and it turned out great. Consider doing this on more than one platform, each with its own primitive drawing API, and scalable for a few different device resolutions – it should add up to a lot of extra effort.

By developing natively, you encounter all sorts of issues with UI scalability to each device’s resolutions. By choosing web, you build in an environment that was originally designed to handle these issues. By building a fluid layout for your application, it will look great on all device resolutions, and even have a different layout for tablets – all within the same code.

Other solutions

There are frameworks that work in a different way. They offer the possibility of writing the code once and run it natively on a lot of platforms. You write JavaScript and the framework handles its translation into native code. Titanium Mobile is one of these solutions. Sure, the final code is native, and it runs fast, but there are some downsides to it.

It adds another development layer which complicates things. First off, you write JavaScript code, not using web standards, but using their own components. You lose control over both the JavaScript and the native layers. Everything you do is limited by their API and what it can or can’t do. You cannot tap into the advanced functionalitities for either the native or the JavaScript layers. This means there is no way to make performance improvements, structure or memory optimizations, except with what the Titanium framework offers.

It is a fast way to develop mobile applications, but with limitations on the functional and the UI side.

Comparing native apps, cross platform framework apps and web apps

Below I’ve included a small comparison on areas where differences between the platforms are most obvious.

Comparison between different technologies

Where things are going

Lately, every major player expressed an interest in providing the best support they can for mobile applications on their platform. Apple has the best mobile browser out there and, even so, they improved its performance a lot in the new iOS 5 version. Google just launched a new Android version with an improved browser and are planning to replace their mobile browser with Chrome (which is currently the fastest desktop browser). Microsoft improved the support for web apps in their Mango release by bringing IE 9 to their mobile platform. Intel, after the failure of their Meego project, are creating a new Linux-based mobile operating system together with Samsung, named Tizen. This is built around proving the fastest HTML 5 web application environment. Everybody is targeting web technologies, and with this much attention, things are bound to develop quickly. Even Adobe, with their Flash technology are moving towards HTML 5 and mobile platforms. They bought PhoneGap a few weeks ago and recently announced they’re dropping the developing efforts for mobile Flash and focus instead on supporting HTML 5.

From my point of view, mobile web applications are great. They can provide a great user experience with a smaller amount of work compared to native applications. There are bumps along the way, like in any new (new on the mobile side) technology, but things seem to be moving in the right direction and they are doing so pretty fast.