Obviously (see below) web apps are somewhat easier to implement and you just need one implementation for all types of devices, while native programming requires some changes for different plaforms. However, there are couple of reasons why users might prefer a native application over a web one:
- Native application works where coverage is poor.
- Users may not want on-line application when roaming; the roaming prices are still absurdly high in much of the world.
- In some parts of the world, mobile internet access is still not exactly cheap even in home network, though that's getting better rapidly.
- Web applications can't be shown in applications menu on Android and perhaps other platforms as well (bookmark on home-screen is possible).
- Web applications can't run in background providing e.g. notifications nor wake up on timer.
There are however lots of problems if you want to have native application on the various platforms. From my first-hand experience:
- Android is probably most useful to have. Core can be implemented in C or C++ and we could get all libraries we needed to compile there, but some Java glue is needed. Both Qt and SDL can be used to reduce the amount of platform-specific code. It does not support MIDP (Java ME), but it does support Java, so Java core with Java ME and Android UI is also an option.
- iOS (iPhone) is programmed in Objective C, but almost any C++ compiles there just fine. There are Qt and SDL ports that can reduce the amount of platform-specific code. We use SDL there and had to work around some bugs in there. Still saves some work in porting. Java is not supported.
- Windows Phone 7. Forget this platform. It's not possible to get C nor C++ code there, only .NET and that is not supported anywhere else. We even tried asking Microsoft for hints how to port to Windows Phone 7 (we have the application running on Windows Mobile currently), but got no useful answer. With the minimal market share this currently has, I'd not bother with it.
- Bada is programmed in C++, but the toolchain is a bit flaky, the API is not similar to anything else and we are really struggling to workaround all it's deficiencies. There is a Qt port, but I don't know how far they are; I didn't hear about SDL port yet. We have some specific customer interested in it, otherwise I am not sure whether it would be worth the effort.
- Symbian S60. It's still common, but it's not clear what future it has. Nokia's strategy is currently unclear. They still sell phones with S60, but also sell some with MeeGo and announced they will start using Windows Phone 7. It's one of the last platforms still supporting MIDP. It's also officially supported by Qt (Nokia ported it there when they bought it).
- MIDP/Java ME. Most new platforms don't support it anyway, platform integration is minimal (i.e. can't run on background, provide notifications etc.) and the UI options are abysmal.
We spent about 6 man-months to get our application running on each new platform. Granted, it's pretty complex application, but on the other hand it has custom GUI, so we only need to display a framebuffer and don't redo all dialogs. So don't count with less than 3 man-months for anything non-trivial. You might get below that with Qt (we don't use it (we do custom GUI, so there is not that much point) and started to use SDL too late, so we don't use it on some platforms where we could), but some of the ports are still beta and some don't yet exist. I don't expect working around quirks of the various mobile browsers to take that much.
Last, many platforms support developing in Flash, but I have no experience with that. I do have experience with Flash on some custom embedded device and it was not too pleasant (but it had custom OpenGL-only display driver and they had some trouble porting the player at all, so we ended up doing quite a lot of performance tuning). Might be an option for something simple though.
In the end, you should first define your requirements, have somebody look at the options and make estimates (means to spend a few weeks on it!) and only than discuss it at top management layer. Top management can't do reasonable decision without numbers that are at least in the right ballpark.