Plaforms HTML5 Java software

PhioneGap platform

Mohammad Rashid Founder at Windows Metro Solutions

March 19th, 2013

I am thinking about using PhoneGap as platform to write applications for different phones platforms.

Would you recommend using it?



CJ Barker

March 19th, 2013

I've run into this question numerous times.  I'm going to pull in one of my previous responses from another forum.  

The short answer depends.

Developers need to treat mobile computing more like 1980/90s micro computing.

You have limited resources with numerous environmental factors that need to be accounted for and respected (ex: bandwidth, latency, CPU, GPU, memory, UI/UX, async task handling, and most importantly BATTERY LIFE).

It is a different mindset when developing for mobile that needs to account for finite resources. If you're greedy, careless, or just don't really think through and test your app appropriately it makes for a horrible user experience.

Regarding the HTML5 vs. Native Apps:

HTML5/CSS/JS and frameworks that allow you to write once and convert to native apps (ex: Phone Gap) have their place. The core take away is that without developing native apps directly you’ll never get to maximize the phone’s hardware and performance will suffer. UIs will be sluggish and network IO suffers from high latency (wrappers).

HTML5/CSS/Javascript frameworks like Phone Gap cannot take full advantage of the hardware and SDK features like alarms, custom hardware access/config/acceleration, background services, and (taking advantage of) the standard UI controls (transitions, buttons, look ‘n feel).

If you’re focusing on content display/information consumption and your app doesn’t need to rely on high performance from hardware and the UI then HTML5 is most likely a good fit. If performance, high availability/background service, native look and feel and the such is critical to an app then native is a better route.

My 2 cents.

Bo Han tinkerer

March 19th, 2013

Is question more about HTML5 Hybrid App vs. Native App or whether to hard coding native wrapper vs using PhoneGap for a HTML5 Hybrid App?

Use PhoneGap/HTML5 Hybrid if you:
-Need a really quick MVP
-Need to support more than Android + iOS
-Have very limited experiences with Objective C + Java
-Don't plan to support it for the long term

Stay away from PhoneGap/HTML5 Hybrid if you:
-Only really care about iOS and/or Android
-Are OCD about code quality and size
-Planing on doing some very graphic intensive 
-Expect perfection or fastest interface

Depending on the complexity of project, coding a HTML5 App that offers comparable user experiences to a native app is not trivial. Here's Linkedin as a case study:

Shoukri Kattan

March 19th, 2013

I would recommend Appcelerator Titanium ( 
You code in javascript and it "compiles" to native. So Your UI is native, you have access to all the native APIs , and you get to re-use as much as possible. 

Titanium also has extensions so worst case you can build your own Native modules. 

Jonathan Bond-Caron

March 20th, 2013

It depends on your experience with JavaScript, HTML and CSS and understanding of Webkit. For iOS, Phonegap and Webkit performance is really good while Android WebView is an ugly fragmented, slow mess. If you are targeting Android 4.1+ only and iOS, you should be fine. IE 10 is the only platform not WebKit based so there's some slight learning needed there as well, but performance is great.

Going HTML5/web is a more complicated environment to develop in but in the long term definitely a better investment of your time. I'd highly recommend using Phonegap, JavaScript is a language that will be around for a long time (for better or worse).

Disagree with everyone about 'experience' polish and not being a good long term solution. You can use 'native' components and use just HTML/CSS for presentation. A hybrid PhoneGap app can be 20% mobile (html, css) and 80% native code (objective c, java, etc...).

 Like I said, it will be complex but IMHO a better investment of your time in the long run.


Keenan Wyrobek CEO at Open Reading

March 19th, 2013

I second Bo. I second most of CJs comments.

I have used Phonegap for a few products successfully and when I was starting with Phonegap I tried to use it one some products that really could only be done native.

I can give you better guidance if you can tell me a little more about the app you are making.


Kevin Cocco Strategic Consulting at SproutLoop

March 20th, 2013

I really like and agree with Bo's above pro/con lists. 

I have written a PhoneGap/Cordova app and here are few links that I think you will find useful in understanding PhoneGap:
-  PhoneGap Build:   Service pulls code from GitHub and builds your apps:
-  Great PhoneGap examples open sourced by Christophe Conenraets:
-  List of Native controls avail to PhoneGap apps (but, yes not all):
-  JQueryMobile, PhoneGap friendly, one of many UI options:

Happy hacking

Steve Cosman Co-founder of Shoebox

March 20th, 2013

Typically executing well on 1 platform is better than a mediocre implementation on many platforms. Unless it really has to be cross platform, focus on 1 and kill the execution. PhoneGap apps are always a little slower and less appealing that native equivalents.

If you absolutely need to be on many platforms (most ideas don't) it's a good tool for a MVP, but you'll end up rewriting it if you are successful.

Bubba Murarka Managing Director at Draper Fisher Jurvetson

March 19th, 2013

If your primary product experience is via mobile and you have no existing userbase I'd recommend starting native on either iOS or Android in order to reduce development surface area while iterating.  Would say I strongly advise that if you are building a consumer product.  :)  

In regards to iOS vs. Android the biggest trade off is velocity of iteration.  You can feature test on Android faster (no review gate & autoupdate) while iOS apps are usually faster to polish'n'make shine once core product market fit is figured out.  I tend to see companies betting on android initially if viral growth is their primary distribution lever.  

Once you have a native product working on a single platform I'd quickly bring up a mobile web version of product where you move your feature testing / iteration too (assuming possible - and always is as you can do hybrid for single feature) as you invest in building native clients for the other mobile os platform(s).  

For context, I worked on FB Mobile apps while we were in the thick of HTML vs. Native throes. :) 

Shawn Burke CTO, Buddy Platform

March 19th, 2013

The major factor should be about how important it is to deliver an excellent UX in your app.  If you're displaying information that just needs to be accessible, this is a reasonable way to go.  But for any experience polish, you'll be in a world of hurt.  If you need to use any native experiences (say, a Map control since a JS map on a mobile browser is terrible), then you're out of luck.

As said above, just go write an awesome iOS app, then see where you stand.

Jon Cooper Chief Technology Officer at Colchis Capital Management

March 20th, 2013

It depends a very great deal on what you're building.

It is almost certainly easier to hire for and maintain a wrappered app. Folks that can go from a visual design to a reasonable HTML/CSS/JS implementation are much easier to find than Cocoa hackers. And the average visual designer has more experience designing for the web (i.e. one long scrolling view) than for mobile SDK widgets.

Wrappered apps have a hard time maintaining a perfectly idiomatic (in a platform sense) UI/ UX. Little things like scroll momentum, nearly invisible gradient overlays, and control events firing events against background threads instead of the main UI updating thread are subtle but noticeable, especially in their gestalt.

Over time it is more difficult to provide a best-in-class user experience without building a native app. Typically you will end up tinkering with your client-side proxy to your remote data store + API in order to add things like store-and-forward, exponential backoff, etc. You can build a library and link it to your PhoneGap. But at some point you will end up with a monstrous FrankenApp that is difficult to maintain and new feature momentum will slow to a crawl.. 

If the app isn't your product, but a bolt-on to your product, it may not matter if the UX is a bit wonky. If you're providing a convenient way for people to access your product (especially if they have an instrumental motive for using it) they will use any app that lets them get it done. If the app is your product, I would recommend against it, with the possible exception of games, where something like Unity makes sense.

Certain kinds of interaction are considerably more appropriate for native implementation than wrappered. Novel gestural UI (like a drawing app) or a requirement for low latency / high throughput (realtime sound synthesis, video transformation) are going to require a native app.

It is also worth considering carefully whether you really need to be multiplatform. In my opinion, in most cases it's better to have an ass-kicking implementation on one platform than a crappy implementation on many.