Cross Platform Mobile

Fowler's summary is:

- Don't use cross-platform toolkits

- For maximum reach: built a web app that looks like web app

- To appeal to a particular platform: build a native app for that platform, with a experience design based on that platforms interaction style

> Getting good UI controls are almost impossible, but that's not the biggest issue - which is more about the overall user experience. Different platforms have different ways they expect you to use them that alter the entire experience design.

In my experience, he is right, but it's more subtle than that.

We once built an iphone app with phonegap and HTML5 (back when phonegap had native iphone tab controls). It looked native, it seemed native, but it just didn't feel right.

Our current iphone app uses titanium mobile, which (from a UI perspective) is native - and it feels completely native. Even though under the hood it's interpreted Javascript and not objective C.

The advantages of using Titanium over Objective-C are; I'm already quite handy with Javascript, and Titanium comes with a honking great API example called KitchenSink.

I tried several cross-platform tools and web toolkits. Appcelerator is too clunky, flaky and community support is virtually non-existent (this is not a blame, mind you, as their business model is built around paid support, and I totally understand the lack of answers on community forums). I'll take another look at them once they integrate with Aptana (IDE that they acquired).

jQuery mobile (boxed into PhoneGap or not) is dog slooow once your page sets or lists get too big, and like some mentioned, interaction just does not feel right sometimes.

One approach that I like is that of applitude (http://applitude.org/). It is DSL for description of view-based applications that is translated source-to-source to Objective C (It is iPhone only). Unfortunately this project looks like one man effort and is not under active development. But I wonder if this is the approach that some cross-platform toolkits should take.

I think he is saying we shouldn't use jQuery Mobile because it's a web app that tries to look like a native app.

I question Martin's line of thinking. If customers don't want the resulting product, jumping straight to native apps risks slow, misuse of effort times N.

PhoneGap, SproutCore and the like are great if there's a need to get something going right now. Then, in all likelihood, such would be replaced with native apps later.

For example, it seems an obvious approach to have hybrid apps begin with a native skeleton app continually evolve with cross-platform web flows backfilled with more native as the product gets traction and has an opportunity has time to specialize.

Evernote did this on a RIM app. It's not shameful either, it's brilliant expedience.

Update: forgot to mention up-and-coming portable js platform Game Closure.

I'm stumbling around this very issue right now, but his recommendations would not work if you need to interface with native hardware functions such as the camera. It would be great if there were a web interface into native functionality, however. What are the obstacles to os developers providing it?

My advice is take jQuery Mobile, extract the parts you care about and build your web app your own way. You don't have to use the whole thing. I agree with not trying to emulate native apps.