Gettin' mobile-webby wit it (Native vs PhoneGap vs Titanium)

Yes, that was a Gettin’ Jiggy Wit It reference.

Lately I’ve wandered from iOS land into the world of non-native app development, and I’m going to be in hot pursuit of performance boosting CSS techniques, handy-dandy HTML5 tricks, and browser-compatibility smoothing for the next few weeks. This post: two tiny but packed articles and then a PhoneGap Vs Titanium Vs Native comparison. TL;DR: I’m prototyping with PhoneGap because it has the smallest learning curve, the widest reach, and because the mobile web is improving rapidly these days.

I found two great (and very concise) articles on HTML5 from Adnane Belmadiaf last week, one with 5 need-to-know HTML5 features, one with 5 awesome HTML5 + Javascript mobile APIs. The APIs are pretty mobile-awesome, check them out.

I mentioned a few days ago that I found a great PhoneGap + AngularJS tutorial. This was after I spent a few days making the classic PhoneGap Vs Appcelerator Titanium decision. I have always been a huge Native-is-just-always-better advocate, without having done much research into any hybrid or otherwise non-native tech. However, the draw to build once and deploy everywhere is a strong business and dev-speed motivator, and a little research has pushed me into the prototyping stage. Below is my take per platform so far, according to experience plus some readings from StackOverflow, a quick post from a guy who went native over non-native, and a BIG post from a Titanium employee who breaks it all down in a very fair and very informative way.

PhoneGap gives web developers a chance to build an app for every device with a browser one time, using html, css, and javascript (assuming you don’t need any true native functionality). It runs a ‘native’ app that fires up the device’s native browser to run a web app, and connects to device features via the PhoneGap API.


Disadvantages: Titanium from Appcelerator comes with it’s own IDE and can be written entirely in Javascript (again, assuming you don’t require true native hybridization). It focuses much more sharply on iOS and Android, allowing its API to dig a little deeper into those OSs’ core functionalities.


Disadvantages: On native vs non-native apps: While non-native apps can save 60-90% of code, there is something to be said for developing a fully native app on one device (say, iOS) then asking a (say, Android) developer to build a replica app from scratch. It’s a great project, and I’ve heard tell of some success stories (and I should add some links here but am tired and will hope you trust me). It can also prevent one multi-OS-assigned developer from the headaches that a single-OS specialist would fly through. Also, native apps can provide the best user experience, although that will really depend on the team building the app.

Fully native apps, however, are not always accessible to the whole development team (unless you are REALLY stacked), and keeping content, style, and updates consistent can become a project management nightmare.

My thinking at the moment: if PhoneGap has the fastest development speed and modern browsers are rapidly improving, why not take that chance? If the UX is comparable and we can avoid the unholy Apple App Store update process with some dynamic content, then I’m sold. And if there’s anything that the mobile web can’t handle, we’ll just link to a native view for that piece of complexity.

I’m prototyping now. The new fear: if my app sucks, is that my fault or PhoneGap’s?