I'm currently developing an app, targeting both iOS and Android, using Titanium. So far it's going great - I have one codebase with only a few platform specific branches for UI, and completely platform independent business logic.

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.

In my experience, the best way to test Android is on device(s). You're going to want to test on device anyway, and it's very easy to do, so just skip the emulator.

Keep in mind that the iOS Simulator is a simulator, not an emulator. You'll have the full CPU and memory of your dev box, so there will be a fair number of bugs that occur on the device but you won't see in the simulator.[1]

[1] A tool that's useful for testing in the iOS Simulator is Network Link Conditioner, which allows you to simulate 3G connections on your dev box. You can download it from developer.apple.com through your developer account. From XCode: click on the menu item XCode>Open Developer Tool>More Developer Tools... and you'll be taken to a web page with a downloadable disk image containing the Network Link Conditioner Systems Preferences pane under Hardware I/O Tools.

Using a virtualised Android (x86) tends to help.

Also, make sure your emulator image is set to take snapshots at shutdown, to make start-up time reasonable.

Another upside of Titanium (I'm busy with an app using Titanium) is that it's open source. See something that's not implemented? Hack some Objective C (for the iPhone client) and build Titanium, done. So you're essentially free to do what you want.

However, what I've also noticed that is that doing an iPhone-only app in Titanium definitely didn't go faster than doing it in ObjC, I'd say about the same speed. But that's my experience, for the app I'm doing now.

Thank you for sharing your experience. That is what I expected in the article, actually.

The article just brushes the surface of these issues:

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.

Disagree, Titanium is not lowest common denominator. It takes a stance that you should develop your UI specifically for the deployed platform but gives you a consistent api for doing so.

With titanium the vast majority of your applications logic is un-touched between platforms and you generally have about 50% reusable front-end code.

If you structure your application properly, swapping out UI pieces by platform is simple.

User interface is only the surface manifestation of OS architecture. Both Android and iOS have very distinctive userland technologies layered over open UNIX-like kernels. While a cross-platform SDK might give you access to almost all of both platform features, it is very unlikely to be able to abstract those features in a way that results in portable code.

For example, Android's component-based app architecture runs very deep in Android implementations. If you subvert it, or plaster over it with an abstraction, you lose the ability to minimize your app footprint by having relatively small components "destroyed" or swapped out of memory in Android's unique approach to making Java memory management work across component and process boundaries.

Windows 8 for mobile devices is yet another distinctive OS, with a unique kernel and similar, for still very distinctive managed language runtime, plus legacy compatibility.

We're in an era of OS and managed language runtime innovation. Each one is striving to provide the optimal feature set, and that often involves the way in which apps and components of apps communicate and cooperate. plastering over the semantics of those large and deep architectural differences is going to result in a lowest common denominator result.

I have worked with Titanium extensively and I'd say if you do it right, you have a LOT more than only 50% re-useable code -- probably closer to 80-90% that works perfectly cross-platform. Of course it depends a lot on what UI elements the project requires, so I imagine the range is quite large, but 50% still seems really low.

I'd expect an article with this title on the front page of HN to offer a bit more than the obvious bullet-point rundowns of each of these approaches.

Been using Titanium extensively in the company I run, and to this day it has been the biggest mistake we've done, followed by not migrating away from it soon enough.

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.

I was kind of hoping for an article that actually started where this one ends. Since I run a mobile focused startup, I think a lot about what to put your money (well, time actually) on: PhoneGap / Titanium / native (or simply web browser based).

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.

The article offers little value, but I'm always interested in conversation about this topic so I'll add my experiences here:

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.

I've been doing HTML5 app development (via phonegap) on iPhone and Android for some time now, and I agree with a lot of what you said. You can make a really smooth, native feeling app using HTML5, but there are lots of things that don't work well. On iphone, there are lots of problems with fixed positioned elements, and on Android there are issues with translate3d. Both platforms have problems with "tap" events. These are all things that are important if you want a "native feel" in your app. However, there are workarounds.

I also agree that needing 3 front-end teams for app development just doesn't make any sense, especially for a small company. Since you can get near native performance with HTML5, it seems well worth the compromises.

FYI, my app doesn't use any mobile js frameworks, just Backbone.js (and phonegap).

I'm inclined to agree. I've been doing native iOS apps for over a year now but I'm cross-training myself with the HTML5 apis because I think that's where more of the work is going to shift over time.

I don't see any reason why mobile should be qualitatively different than the desktop in this respect. There will always be an equilibrium point between web and native but I expect it to come to rest heavily on the web side just as it has on the desktop.

  > The vast majority of the apps out there today would work
  > just as well as HTML5 apps.

Except that you will need to load a bunch of frameworks to get the functionality which iOS already provides.

Not a "bunch of frameworks". In our case, just one, that being Sencha Touch.

Can you share your app? I am also working on a HTML5 app for android and iOS. Always looking for a good app to let other know what is possible in webapps.

It's called "Kona" - just search for that on the app store and you'll see a brown icon with an orange K. Feel free to contact me if you have any questions, my email is in my HN profile.

Cool, works pretty good.

I think we can get it to feel even more native too, we haven't done a whole lot of optimizing on the transitions and whatnot. Overall I'm pretty impressed with Sencha and HTML5 in general, so far.

I've worked with Titanium extensively, and a lot of this article is just plain wrong regarding Titanium. It seems like Sapan just read some older docs or articles on Titanium and did a write-up for traffic.

* 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.

Be warned though, it's not easy to debug the embedded webviews. I put some HTML5-based charts into a Titanium app and it took so long that I wished I'd gone full native ObjC from the get-go.

I didn't think that the V8 engine was available on iOS in native apps.

I realize this is a bit nit-pickery, but the text has a bunch of broken smart-quotes in it that makes it really hard to read.

My choice to go with Phonegap really comes down to the capabilities I want the app to have. If I only really need a wrapper that gives access to a camera (hell, GPS even works out of a browser), then an app like Phonegap is more than enough. And I have no doubt that in the near future, phones will be able to handily run HTML5 and CSS3.

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.

> And I have no doubt that in the near future, phones will be able to handily run HTML5 and CSS3.

With the iPhone S we're pretty much there. HTML5 apps run beautifully on it.

Just want to point out that you can use external JS libs in Titanium. I use underscore.js and several others. For simple apps it's a great platform -- you'll hit one or two weird gotchas, but still knock out the app quickly.

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)"

How is this front page? It's barely informative and not completely correct at parts.

Thank you for point to point study! I am starting to build mobile phone apps and this post has provided me a nice overview.