There are several approaches to building cross platform applications targeting mobile platforms.
Frameworks such as Mono allow development of a common application core, with a native user interface and platform specific integration developed on top of this for each platform.
Not a website
Although a plain HTML website can be packaged as an application and distributed in the same way as a native application with the help of the tools covered in this post, there are some problems with this approach.
Firstly, Apple will not approve applications for distribution on the App Store that simply wrap a website, or provide a website look and feel. Adobe has written about this, and various posts from users discussing App Store submissions being rejected can be found on the PhoneGap newsgroup.
Secondly, user expectations are established around what an application provides over a website, and how the user experience of software installed on their device differs to viewing a web page. Some application distribution methods that do not enforce following platform guidelines may accept the application, but users will most likely not.
Taking a web page and packaging it is not the intended approach for these tools. They exist to provide the ability for application development using web technologies, with additional device integration that may not always be possible through a web browser; for example, they provide access to the camera, local data storage, user contacts, system notifications, checking network state, and using sensors such as the compass and accelerometer.
If the additional functionality provided by the tools is not required, or the application does not work while the user has no connection, there may be little value in making use of these containers rather than providing a regular website.
Three cross platform mobile development tools investigated
PhoneGap is a branded version of the open source Apache Cordova project (Apache 2.0 licensed, which allows unrestricted commercial use), developed and supported by Adobe and others. Deployment targets for PhoneGap are extensive and include iPhone, Android, Windows Phone, and Blackberry.
PhoneGap provides a web application container, as well as allowing applications to access the camera, device storage, perform network detection, access device sensors, and more (see PhoneGap Supported Features for a full list). It is also possible to integrate with custom native code where required.
Adobe monetises PhoneGap through features such as an online build service, in addition to it being an environment that Adobe’s own development tools can be used for. The full functionality of PhoneGap is not tied to using these services.
Like PhoneGap, Appcelerator Titanium is Apache 2.0 licensed and free for commercial use. The developers of Appcelerator Titanium monetise Titanium by making integrated cloud services available.
Sencha Touch is dual licensed under the GPL 3 (unsuitable for development of applications that are closed source, or licensed under an open source license incompatible with GPL3) as well as a no cost commercial license. A paid commercial license is also available that provides technical support, the ability to package applications for use on desktop operating systems, as well as providing additional developer tools. See http://www.sencha.com/products/touch/license/ for further details on licensing.
Some of these include:
- jQuery Mobile – Demonstration
- Sencha Touch/ExtJS – Demonstration
- jQT – Demonstration
- Enyo framework / Onyx UI library – Demonstration
- Dojo / Djit – Demonstration
Things to keep in mind when considering an application framework and UI library to use for mobile deployment are its performance and memory footprint, minimal effort to achieve a UX that feels right for the target platform, support for embedding within an application container such as PhoneGap, and the ability to write the application as a ‘single page’ to prevent unwanted flashes as pages load.
Factors to keep in mind…
A web application running in a mobile app container such as PhoneGap is still subject to the same managed application lifecycle imposed by the operating system on any other application.
One of the purposes behind the managed application lifecycle implemented on modern platforms is to present the illusion that once an application is installed, it is always running – users should not need to worry about starting and stopping applications, or managing memory. In reality, an application’s process may be killed at any time by the operating system as part of normal operation, or the device’s battery may run out of power. In both of these situations the user will not expect their work to be lost.
As with any other mobile application, the application should be designed keeping in mind that it should ideally be able to save and restore application state at appropriate times in a way that is transparent to the user.
Application Look and Feel
Applications for iOS distributed via the App Store must act and appear as applications, not as web pages – buttons, lists, toolbars, and other elements should behave like an application written using the native user interface controls. Information is available online with tips for helping to get this right, such as this blog.
Android applications distributed via Google Play will not be removed from the store for not looking like a native application – however, creating an application that does not look and feel like an Android application will likely result in low review scores and reduced user uptake.
Each platform has its own patterns and style guidelines. The design of the application should keep target platform design guidelines – such as minimum size touch targets, fonts, element spacing, and application navigation – in mind while designing and implementing the user interface. For example, see the Android guide on Metrics and Grids.
While the application should look and feel similar to a native application and not appear as a web page, you should also be wary of the uncanny valley of user interface design.
Handling offline scenarios
Applications must provide some form of functionality when the user has no network connection. If the application’s pages and resources are all downloaded from a server, the application should still provide some form of feedback to the user indicating that a network connection is required, rather than silently failing.
What others are doing
To get a feel for what web based mobile applications can achieve, take a look through the PhoneGap application directory here. Some notable applications are the travel planner TripCase and the social application Untappd.
For an example of platform integration that can be achieved using PhoneGap, take a look at the Wikipedia application for Android. It uses the native Android sharing system, so users can share articles to any other installed application that works with the share action. It also registers that it handles Wikipedia links – pressing a Wikipedia article link in a web browser will present the user with the option of opening the article in the Wikipedia application when it is installed.
As with any technology decision, whether to write a mobile application using web technologies in conjunction with a tool such as PhoneGap is something that should be decided based on a project’s requirements. When used appropriately, it can offer a way to more easily reach a wider audience by reducing the time and cost to support additional platforms.