Titanium vs Phonegap vs Native application development

It's remarkable how little code you have to write to achieve good results with Titanium. Plus, contrary to what article saids, you CAN use external Javascript libraries, but they have to be adopted to CommonJS before usage. There are also many components written by the community.

The downside of Titanium is that they don't cover 100% of APIs that both platforms provide. For example, there is no Radio Button / Radio Group APIs for Android, you have to invent your own solution. I'm sure there are more gaps like this. But even considering this, you'll probably end up having a working prototype much faster using Titanium.

Edit: For anyone more experienced - is there a better Android emulator out there? The stock one is painfully slow, compared to iPhone Simulator.

Edit 2: Developing with Phone Gap seems attractive, but then you dive in and discover that you have to either load up enormous UI library to mimic native behaviour (which always is far from perfect) or reinvent the UI and touch mechanics yourself. Ouch.

Web applications are appropriate for information applications. Not a surprise, since the Web originated in hypertext. Web apps are good for presenting and navigating ad hoc multimedia information. If the target of a Web app is appropriate, a Web app will be the least expensive way to go.

Native apps produce the best looking, most touchable, and fastest apps, but be ready to pay to get results that are significantly better than a Web app. Make sure you are doing something that requires direct manipulation, and that takes advantage of how the underlying OS works. On Android, for example, make sure your app takes advantage of Android's fragment-based UI features, inter-app cooperation, and device hardware, if applicable.

Cross-platform panacea SDKs like Titanium result in lowest-common-denominator apps. If you are considering Titanium, you should probably make a Web app. There is only a narrow category of apps for which cross-platform SDKs yield the best result.

Every win you get for "writing code only once" you pay for tenfold (at least) in working around quirks, lack of documentation, unsupported native API's, performance issues, building issues, unannounced API breakage, etc, etc etc. On iPhone it's bareable, although far from pleasurable. Android is to this day barely beta quality despite the company claiming "hundreds of thousands of developers".

Custom modules can usually be built to work around core stuff not working, but involves "guess and try" programming for a long time, as not all APIs are documented/exposed.

Bug reports lie around for months and years, sometimes really critical ones that break major functionality. Pull requests in github also lie untouched for indeterminate amounts of time.

In fairness, things have gotten much better in the last year, but still far from being workable, and to anyone thinking of building anything bigger than a quick prototype of anything in Titanium I'd suggest to rethink, and do a quick Google, that would reveal the hordes of frustrated people and bad reviews.

PhoneGap seemed like a wonderful thing when I first started working with it. Even if speed is not an issue, the 300ms click delay is, and so are all the hassles to get around this and around other peculiarities. And that's only when testing on a single platform. Same holds true of course for in-browser apps. So far I found myself spending way too much time on debugging and coming up with workarounds. The problem being that the more freaky you get with JS/HTML/CSS, the less compatible things will get, so the more time will be spent debugging.

My current opinion about this matter is: I'd rather spend this time on coding the whole thing twice. This is of course, all under the assumption that Android + iOS support will do.

Yes, then there's Titanium. I haven't tried it. But as with PhoneGap, I think that adding an abstraction layer creates a dependency, and this by itself is a downside (which requires justification). I feel that once you're working with native UI, you could just as well work with 'native' IDE & code, because that brings you much closer to the actual system (and benefit from its strong points) and you are not limited to whatever has been opened up for you by the abstraction layer. But I've been coding since I was like 8, and I already worked with Java a lot. So adding one more language seems doable.

But perhaps I should try Titanium first before using it. Then again, trying takes time that could also be spent on learning objective C.

So, that's basically what I would have liked someone else his/her perspective on, something I miss in the article.

I'm on a contract with a company that has run the full gambit of mobile strategies over the past year. They started out by outsourcing native development of their mobile app overseas. After about 9 months of development they determined that for whatever reason, whether it be communication issues or poor product planning, the apps weren't where they wanted them to be so they decided to do a complete 180 and go with the HTML5 approach, which is what I've been working on.

We decided to go with the Sencha Touch framework because it's the most complete native-style mobile framework out there today. We've managed to recreate the native apps in just over 2 months, which is impressive considering it was a rewrite from scratch. A week ago we submitted to the app store and it was approved by Apple.

Performance on the iPhone 4s is surprisingly close to that of a native app, which gives me hope for the future of the phonegap approach. Phones and javascript engines are only going to get more powerful, so in a few years this experience should be ubiquitous for most people.

However, we're at a point in time where there are a lot of older devices, mostly running Android, that don't run HTML5 apps as nicely as they do native ones. For instance, our app is very usable on a 2 year old Android, but scrolling isn't very smooth and transitions are mostly non-existant due to the fact that hardware accelerated CSS3 animations aren't supported. I should mention that our app is mostly data (it's a productivity/collaboration app), so that helps.

I'm primarily a web developer but I've started diving into native iOS development for a side project where UX is more important. Native development isn't as bad as I had feared, but it certainly takes more time. If you're not very good at it, you'll end up with an app that really performs no better than what could have been done using HTML5. Bad code is bad code, no matter what it's written in. What keeps me from being sold on the native approach is the increasing fragmentation we're seeing on the marketplace. The thought of having to maintain three separate code-bases for Android, iOS, and Windows Mobile gives me cold sweats. Sure, there are strategies for sharing the basic logic between the three, but not nearly as turn key as simply dumping the code into Phonegap like we've done with our Sencha app.

In my humble opinion, given that we've seen near native performance on bleeding edge devices, I think that native apps will only be necessary for games and intensive content creation apps like iMovie and iWork. The vast majority of the apps out there today would work just as well as HTML5 apps.

* Titanium uses the V8 JavaScript engine on both platforms (not JavaScriptCore or Rhino anymore)

* Titanium does not support the Windows phone platform (at least not yet), and the desktop app support has been discontinued so it technically doesn't even support Windows anymore either

* Titanium also produces Web/HTML as as output target for mobile web sites if desired (with little/no code changes)

* You can still embed webviews if you want and make "web wrapper" apps, just like PhoneGap (so yes HTML and CSS IS possible)

* Using external JS libraries IS possible, and is highly encouraged through the use of CommonJS modules

I appreciate comparison articles for the sake of the discussions that follow, but this much bad information is just not excusable.

Really, I think the argument comes down to what do you want your end product to be, rather than what do you want to have to deal with as you're making it.

When I attempted a larger project though, I wanted to ragequit by about the 12th time I typed a comment like "//Doing it this way because (Date.parse doesn't work | Retina images don't scale right | the documented API is wrong)"