True, just as writing in any language you're not familiar with will take longer.
For even a semi-experienced iOS/Android developer, it can be faster than writing an HTML/web app.
My experience with Titanium is that you code in js or Alloy, then when building and deploying, you get native code, with native elements and everything.
Comparing it to PhoneGap, which purely runs in a slowish WebView isn't quite fair I think. Or has your experience been different?
Oh, and yes, it is 'cross-platform', except for the fact that there are so many things not working on Android (either bugs or non supported in the API for Android) that you need a seperate build for android to make it reasonably useful.
This is al based on my experience with Titanium Mobile from around 2 years ago, so it might be better now.
All business logic is still running in JavaScript. In fact, Titanium spins up a V8 engine just to run your app. This may be fine for the most simple apps, but if you need to kick off a long running operation to a background thread, for example, you're in for some gymnastics.
I'd rather have Grand Central Dispatch, CoreGraphics, CoreAnimation, etc. all at my disposal. Using Titanium felt very restrictive. Their API is a one-size-fits-all between iOS/Android/etc. As soon as you want to step out of that least common denomination, you've got to write native modules. Which, if the people on your team don't know native development, can be a problem.
You have to get in a kind of different mindset than with HTML, where you use div's for everything - here you create windows and views - but shouldn't take more than a couple days to get dangerous with it :)
There's a few quirks though - differences between iOS/Android for a small number of things, when coding, which can take up a lot of your time to troubleshoot.
An example of such an issue can be on Android, an imageView which you've applied rotation to, suddenly appears to be not rotated, if you put a backgroundColor on it as well as rounded corners. The fix here could be to use a regular view instead, and use a backgroundImage. Thankfully those kinds of weird things aren't as plentyful any longer, the company behind, Appcelerator, are in my experience pretty helpful and fast with bugfixes.
Just a small point of clarification, you can access the camera on Android using the Camera API. You can access accelerometers / gyroscopes and location in both Android and iOS.
What do you mean by this? That doesn't match my understanding of the current state.
where exactly does the cut off line exist? native/html5 is kinda gray.
- Native apps take a lot of time to build, especially when you are a web-developer without in-depth knowledge of the extensive frameworks available to the native platforms.
- Wrappers work, but are not nearly as great and snappy as native apps; They might contain a lot of hard to fix bugs as well and are harder to debug if they tend to crash.
- HTML5 only apps are not available in the market/store so no free advertising, you can't access things like the camera with HTML5 only, you therefore need a wrapper.
My vote goes to native development; Although it's more work and code to write it's much faster and stable if done correctly. You've got more freedom and bugs can be solved. A native app just feels right, where a HTML5 only app won't give you the best user experience you can get, no matter how much time you put into it. If you need a flexible, big, cross-platform app without a lot of budget to build at least 2 native apps a HTML5 app with wrapper would be a decent option, but for anything else (especially the more simple apps with just 2 or 3 different views) you should go with native.