Mobile Development: Using PhoneGap to Build Apps that Run in Any Mobile Environment — Good or Bad?

PhoneGap lets you write an HTML-based app that can be built and deployed in any of six different mobile ecosystems.  It is a compelling idea.  It’s actually a bit like Sun Microsystems’ slogan for Java applied to the mobile development landscape: Write Once, Run Everywhere.

Developing an application that can run across all major mobile platforms is no easy task.  For example, there are Apple iOS, Android, Blackberry, Windows Phone 7 and Symbian platforms to consider.  The development languages and environments used by each of these platforms is significantly different.  And that’s not to consider the form factor differences between devices, like phones and tablets.  Even on a single platform, there can be big differences in how the application needs to work across different product versions of the software OS and the hardware on which it runs.  It’s no wonder that most developers only have the resources to target development for iOS and/or Android platforms for their applications.

With PhoneGap, developers create their applications primarily by using standard HTML/HTML5, CSS and Javascript.  PhoneGap provides hooks in Javascript that permit access to native device functionality, like geolocation,  the camera, and the accelerometer.  PhoneGap applications basically run on the native browser for the mobile device, but they are packaged and made to appear to the user as native apps.  While the HTML and Javascript used is generally similar across all platforms, the PhoneGap application needs to be built and packaged separately within each of the target platform developer environments.

Since PhoneGap doesn’t create a truly native application, developers that want to develop highly interactive games are recommended against using PhoneGap, but for other kinds of applications, like ‘Enterprise’ applications which don’t use a lot of dynamic screens, PhoneGap apps may be a good choice.  More on that in a bit.

PhoneGap grew out of a Hackathon project called Gap developed for iOSDevCamp held in San Francisco in 2008.  While the project didn’t win any awards at that event, the developers that created it were convinced that they were on to something.   The company Nitobi where the developers were from continued to support and develop PhoneGap after the hackathon event.   IBM liked the idea and provided some support to the PhoneGap Open Source project.  And in October 2011, PhoneGap was bought by Adobe.  Around that same timeframe the source for PhoneGap was contributed to the Apache Software Foundation under the name Cordova.

Who uses PhoneGap?  Actually a fairly impressive list of companies are actively using PhoneGap/Cordova.  The list includes Wikipedia and Salesforce.   As owner of the project, Adobe markets and sells support for it.  IBM sells the product Worklight which is based on PhoneGap.  Mobile gamemaker Zynga has created apps based on PhoneGap.  Microsoft and Blackberry use PhoneGap and are supporters of PhoneGap because apps created with it can run not only on iOS and Android, but also on their platforms, and these apps will help them fill build out their war chests of available apps.

But does PhoneGap really live up to the hype?  Mark Zuckerberg doesn’t think so, at least now. Facebook recently dropped their efforts to build out mobile applications using a forked version of Cordova, and Zuckerberg commented that choosing HTML5 was their ‘biggest mistake’.  Facebook has since retreated to the path of native app mobile development.

Part of the problem comes down to the fact that PhoneGap is really just a fake out.  It’s based on some clever engineering that enables communication between the browser application and the native-level features on the device.  The AgilIQ blog has an interesting story where they dissected and analyzed exactly what goes on under the covers between a PhoneGap HTML app and the native device.  It’s not too pretty.  While the iOS communication stream isn’t too bad, the back and forth messaging that happens in the Android implementation creates a heavy overhead.   These observations explain why there are frequent complaints about PhoneGap apps on Android being not too snappy.

Daniel Pfeiffer noted that the ‘Reflow’ of HTML in the mobile browser is another area where many PhoneGap apps see performance hits.  Within a dynamic HTML app, there are frequently changes that are made to the HTML DOM.  Pfeiffer notes that mobile browsers are typically very slow at doing reflows which are the redraws of the entire page to reflect any new change in the DOM.  When dynamic changes happen, often consecutive calls will be made, one after the next, and each of those calls triggers a separate reflow.

There are also differences in the look and feel between standard PhoneGap apps and native ones that may need to be worked around in order to make the app acceptable to end users.

For example, PhoneGap HTML look and feel can create issues.   Those issues have prompted PhoneGap developers to be creative.  For example, attempts have been made to develop CSS themes that mimic the look of a native app running on each of the different possible target platforms.  Often in order to get the theme you need to load up on another framework that supports the theme, but adding another framework to the mix can further impact performance.  Trying to create pixel-perfect screens that match up with native ones can, for example, can also involve complicated CSS renderings that draw on the machine’s processing power and further affect performance.  Tricks have also been devised to handle things like screen transitions to make the look more like the native platform.

So, does the use of PhoneGap to create mobile apps make sense, or is it a ‘mistake’?  Do all the workarounds and clever tricks needed to successfully emulate a native app really make development any simpler, and can PhoneGap-based apps really be as good as native-built ones?

While there are numerous examples of successful mobile apps built with PhoneGap, using it does seem a bit risky.  No matter how clever you may be in your development, a PhoneGap app will never be as performant as an equivalent native one.  And as mentioned above, for simple apps that don’t require a lot of interactions with the user, it may make sense.  But prior to building your app, it can be difficult to know whether you’ll run into problems, and if you do, exactly what those problems will be.  Ultimately as mobile devices become increasingly powerful and technology like HTML5 and CSS3 become more mature, solutions like PhoneGap will either work better than they currently do or they will simply become unnecessary.  That will be great when that happens.  But until then, you’ll need to try it to see for yourself, or opt straight away for native development.