I don't have enough time to wander in your documentation to know the exact answer for my question.
I want to know if I write a web application with this platform, am I able to view my web app via iphone, android and blackberry browsers properly and have all native apps that i used?
Is there any need to write different code for each brand?
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.
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:
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.
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 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.