A few mobile approaches
I think it's clear for everyone now that there are a few possible approaches to creating a mobile app. Many people have blogged and presented about them, including this recent deck from Martin Fowler. We've seen each approach offers a tradeoff between many axes such as cost & user experience, and they're usually labelled like this:
Mobile web: a website specifically adapted for limited real estate and mobile usage on the go. Think m.facebook.com!
Full native: fully developed in the platform's frameworks, they offer the best experience. However developing for multiple platforms usually means writing the app multiple times.
Runtimes and abstractions: I bundle here tools that allow you to write a native app using non-native APIs or abstractions. This covers a wide range of technologies such as "write once run anywhere" frameworks, dynamic runtimes and APIs, and cross-compilers - but it's not the topic of this post.
Hybrid: the idea that apps can be built using a mix of native and web technologies is becoming a popular choice. Usually split on a feature basis, these app can benefit from faster-to-build HTML components, reuse between platforms, or even seamless updates bypassing approval processes... and still maintain a high-end user experience where it matters.
Where does PhoneGap sit?
Building a hybrid framework
A custom webview
XYZWebView, the only thing you'll have to watch for is the (decreasing) gap in HTML/CSS support between them.
Android - Java objects are marshalled into the webview, and native methods can be called directly.
Windows 8 - The web view exposes a
Some plugins please
A solid bridge is a first step, but most calls will end up looking something like this:
You don't want to write too much boilerplate code for every "bridged" method, which is why a well-thought plugin system is the backbone of a hybrid framework. It should be easy to define new native components, their inputs, how to tell when they have finished running, and their success or failure. That includes callback management and cleaning up!
So why PhoneGap?
When PhoneGap started, it really offered a single WebView with bridging capabilities. Single WebView = single webpage. This doesn't mean we have to wrap a plain old server-heavy website, we can still follow good client-side practices. Still, calling out to native code feels like an exception: you call the native bridge to set alarms, open the camera, or show a custom UI overlay. A lof of successful apps still operate this way, but it has limitations: the core of your app is always HTML, and native components sometimes feel "drawn on top".
Things have changed now. After a few years and a couple of versions, Project Cleaver is now available for iOS and Android. Think of it as PhoneGap upgrading the WebView to a first class citizen. Your app is no longer a WebView, it contains a WebView. Or several!
One app, multiple web views
Instead of having an HTML page that sometimes displays native widgets, why not turn it on its head? You can have a fully native app displaying HTML widgets when applicable. Each of these components will reside in a WebView, and interact with the rest of the app through the bridge. If it makes sense, a WebView can even host a entire flow - for example 3 consecutive pages for which HTML/JS/CSS do a great job. Hey, if it works, you can start with the entire app in a WebView. The important thing is that it's up to you.
With the ability to mix and match native and web, we can always choose whichever is more appropriate for each feature. Is HTML rendering well? Probably a good choice: you'll get the portability and development speed. Need the best experience and performance? Go native. You can also seamlessly transition components from one to the other as it makes sense.
Of course you guessed it, Cleaver (now called CordovaWebView) provides all the "bridge" features we talked about, and does so quite nicely. The plugin system is relatively well designed, and yes its evolving API is a slight pain but also an example of how the framework keeps moving forward.
What about my custom framework?
This one sounds cheesy, but let's face it: PhoneGap had years of testing on multiple devices, and a team dedicated to it. I never thought much about it until I started following the source code and bug tracker, and stumbled upon things like these:
New bridge method for iOS: the typical iOS bridge involves creating
<iframes>on the fly. I've done it this way before. Turns out this can have edge cases, which PhoneGap circumvents by switching to
HTML5 Local storage backup: a change in iOS 5.1 made localstorage no longer persitent. I wasn't aware of that, but the guys at PhoneGap have been tracking it and trying different solutions.
A bad reputation
So why does PhoneGap have a bad reputation? I keep hearing
team X tried PhoneGap and it looked nothing like a real app: slow and clunky. Or
team Y tried PhoneGap and had to throw it all away. My guess is PhoneGap effectively lowered the barrier of entry into the native territory. They made it easy for anyone to wrap a website in a WebView - done! Apply the label
built with phonegap. Unintentional brand-damage. In fact, I think it's similar to the original Apple vs Android apps debate. Yes, many Android apps were of lower quality: all you needed was a knowledge of Java, and no approval process. However it's no reflection on the actual technology. PhoneGap done the right way is actually pretty powerful. Just pick one and start building:
An HTML app with native functions and widgets
A native app with HTML widgets
A few pointers
Personally, I try to stick by these rules for any HTML widgets, and things usually turn out ok:
Use local storage. Whenever possible, show cached content to the user. There's nothing worse than a white screen "because we have to fetch new articles".
Don't hesitate to write plugins & show custom native UI. It doesn't take more than a few lines of code to show a native calendar, compose an email, or display a custom sharing popup.
Now have fun in the hybrid world