I need to develop applications for a company on some major mobile OSes, specifically, iOS, Android and WP7.
I was initially planning to code three separate applications
Disclaimer: I've kept track of the cross-platform tools that you've mentioned but never have built anything with them. If you read through this post, you'll probably be able to guess that at the moment I'm mostly an Android developer.
The answer is: it depends. There certainly are advantages to native apps, but the question is whether you care (or care enough) about those advantages to incur the overhead of developing for multiple platforms. Since you haven't given much detail around what kind of apps you are planning to build, I'll give you a rundown of what I know.
I'm going to assume that you are talking about HTML-based cross-platform solutions (like PhoneGap, Sencha, and Rhodes) and not cross-platform gaming-oriented platforms like Corona SDK or Moai and also not the always interesting Mono via MonoTouch and Mono for Android. I'm also excluding Titanium which doesn't support Windows Phone.
Some of the gaps I see between native and those HTML cross-platform solutions are as follows:
Users of each platform build up certain expectations about how things work. Apps in iOS often have certain UI paradigms (that bar thing up top with the back button on the left, those rounded table/list UIs, etc.), apps in Android may have another (ActionBar for example which is similar, but not quite the same as the iOS bar, or long-pressing items for context menus), Windows Phone users yet another (tiles and panorama views). If you generate the same HTML UI, you probably won't be able to take advantage of that. Those familiar UI patterns make the app more intuitive and comfortable for the user who usually doesn't spend their time learning multiple platforms.
Another advantage of native is performance, especially UI-related performance be that raw graphical rendering power or just calculations. If you have simple UIs this might not matter, but if you have complex animated UIs then some things may end up not as smooth. This is particularly true in Android where you have a huge range of devices including some fairly low-powered ones.
Another downside to using an HTML cross-platform tool is that different phones deal with HTML/CSS/JavaScript differently. It's funny because this is a bit of a double-edged sword. On one hand it's great that HTML is inherently cross-platform, on the other, you still have nagging device-dependent issues. This is especially true once again in Android where you have so many varying devices and where manufacturers love to tinker with the implementation of WebView
s for some reason. You end up with little bugs where certain devices do weird things. If you go full native, you tend to have better compatibility (at the price of putting in more work of course). Support for older versions of Android also tends to be lacking.
Debugging JavaScript is not the most wonderful experience on a mobile platform. You end up doing a lot of logging to the console. It's workable, but certainly not as nice as stepping into your code line-by-line. There seems to be some progress on this front (see this tool called weinre for example) but I can't comment on how good it is yet as I haven't gotten around to digging into it.
Not only is that kind of debugging harder, but noticing bugs is harder too. Errors in your JavaScript code won't end up in your logs unless you manually catch and log them. You can end up with things just silently failing.
In general the big players that you've mentioned have pretty decent hardware support. Features that you mentioned like camera, GPS and local storage are pretty high on the list of features important to app developers so they include them. For a full list of features you'll probably want to go to the website of each one (here's PhoneGap's high-level feature support chart by platform for example), but generally the big "phone feature" things that you think of are there. Even so, there are a bunch of more complicated things that as far as I know these frameworks don't do or don't do as well, particularly things that are less to do with phone features and more platform-related. Threading is one example.
this is one of those questions for which there is no answer and there are plenty of decent answers -- in general the answer is that unless there is some specialized device-driver code that is proprietary the general case of using the API as designed will avoid blunders
Java provides a rich abstraction layer though there is a proprietary protection exposed intentionally for licensing - my suggestion is to look at that as though you were going to protect something & that will answer your question better than any post can
I personally use PhoneGap. I keep my ui library at a minimum, maybe use only Jquery Mobile. And as long as the javascript code is well written, maybe use a mvc framework, I don't really notice any performance loss.
I sometimes use a remote php server for the database, and the ajax calls run smoothly, some other times i use the html5 storage witch works smooth as well.
So unless you want to learn java or objective-c... :)
Cross platform development requires inserting an intermediation layer between your code and the native APIs. There are several potential costs to these kinds of intermediation layers, including:
performance (interpreter overhead, JIT lag, or loss of cross-compiler optimizations),
memory footprint and app loading time,
whether the intermediation API keeps up with the the latest and greatest device APIs and hardware features soon enough (if you need them),
whether there are device specific (non-cross-platform) APIs that the intermediation API does or does not expose, and whether you can add them,
whether the intermediation layer provides or allows you to override its UX/UI presentation capabilities to make the app seem to behave and look "proper" within each targeted device community or App store,
write once, debug everywhere (plus multi-platform regression testing of a fix for any one platform), and etc.
Note that performance inefficiencies might manifest themselves in faster battery drain in addition to or instead of visible UI lag.
You may have to benchmark and/or mock-up and user test core portions of your particular application to determine whether these kinds of benefits are worth the addition development costs required.