3 Answers

• It's not really a web application even though you write the code in javascript, it gets compiled down into an Android or IPhone app which you can then submit to the respective market.

  But to answer your question, the idea of it is to be cross-platform but in reality it isn't. For example, it seems that Titanium put more time into IPhone development so there are a lot more bugs and missing features in their Android framework. Also layout and positioning of UI elements are totally different between the two. Basically, you're going to have to build your app for one, then will have to tweak it to get it to work on the other side.

• Nobody can give an "exact answer" to your question because it will very much depend on what features you want to exploit. But in general, yes, this is a cross-platform solution.

  Blackberry support is still in beta, and (so far) only available to pro or better (i.e. paid membership) developers. I am not one of those, so can't comment on Blackberry support or what the minimum Blackberry OS level will be on the device.

  Regarding iOS and android, they are not a 100% feature match. In part because of the difference in capabilities themselves, and in part because so far Titanium Mobile seems to have focused more on perfecting the iOS side. That said, the focus of the next release level (1.5.x whereas 1.4.2 is the current "stable" version) is said to be android enhancements.

  It isn't clear to me if by "web application" you are expecting the UI to be HTML5/CSS/Javascript or you meant it in the more generic sense of the word. Unlike some (all?) other alternatives, Titanium Mobile doesn't just give you the ability to run HTML5/CSS/JS locally. While you could simply use "webview" controls covering the whole screen to mimic that behavior, the intended paradigm is to create projects where the UI gets mapped into controls which are truly native to each platform deployed.

  What this boils down to is that if you only use HTML5/CSS, the UI may end up basically identical but if you use Titanium UI objects, they get mapped to what is the "native" look and feel for that control. For example, an "option dialog" under android has a series of rows with radio buttons on the far right whereas under iOS they look more like a stack of push buttons. You code one consistent method, and it gets mapped to true native controls when compiled. So you maintain the true look and feel of a native app (as opposed to a UI done via HTML/CSS).

  That said, differences in the underlying native controls means there isn't always a common denominator. For example, the iOS "navigation bar" seems to have more inherent capabilities than android. So you end up with a choice of tweaking your code to take advantage of some platform specific stuff and create an alternative on the other platform(s) or restricting yourself to UI constructs which are available on all the platforms.

  I suggest at a minimum you take the time to review these links to understand what I am trying to convey here:

  http://www.appcelerator.com/products/native-iphone-android-development/

  http://stackoverflow.com/questions/2444001/how-does-appcelerator-titanium-mobile-work/2471774#2471774

  I am also very new to this platform myself, and just doing my first prototype of more complex app so take my comments with a grain of salt. I figure the only one I will truly know if this environment will fit my needs is to try a complex app and see what happens.

  The bottom line is, IMHO, there is no single, "exact" answer to whether Titanium mobile is right for your scenario.

  YMMV.

• I think Doug and Justin gave good answers, but here's our take on the cross-platform nature of Titanium Mobile.

  Titanium (like the native SDKs) provides a web view component to render local or remote HTML. If desired, a developer can develop their entire UI in HTML/CSS and then 'call out' via a messaging API to the wrapping Titanium application to take advantage of native features like the camera or compass. In this way, it might be possible to have almost zero platform-specific code in your project.

  But our goal with Titanium is not focused around building that kind of application. When a user opens a native app, they expect a native user experience. That's why we try and expose as many of the native UI elements as we can through our JavaScript interface to let you build a real native app that feels 'right' and performs at native speed.

  But in so doing, often times it is difficult to keep our UI APIs normalized in such a way where every API and every argument to every API is supported on both iOS and Android (and soon BlackBerry). Because the UI components and modes of interaction are so different on different devices, you'll end up writing a good amount of code to build a UI one way for one device and another way for another device.

  Titanium is not intended to be a 'write once, run everywhere' type of solution. It is intended to give developers the chance to reuse 70-80% of their code (basic visuals, and all non-visual APIs), but still provide the 'right' kind of native user experience that a platform/OS' user expects.

  Also, as the other folks mentioned, 1.5 (and our currently available continuous builds) has a ton of new features around Android - better animation support, more granular control over activities, more styling options and more controls, and lots of other great stuff the Android guys have been slaving over for months. It's taken longer than we would have liked, but we're trying to make sure we get things right and have a very stable 1.5 release which bolsters Android (and iOS) a lot. We literally have folks working 24/7 on it, and hope to deliver ASAHP. Stay tuned, and feel free to check out our continuous builds to get a sneak peek.