I have been given the task of producing a compilation of pros, cons and key points on the issue of mobile native applications versus mobile web applications. It will be input for a discussion on top management level.

What are some valid and maybe overlooked topics here?

  • 6
    Besides the obvious, and what a Google search immediately proposes - You'll have to tell us what those are. If you've already done some research why not share it?
    – yannis
    Dec 5, 2011 at 8:19

3 Answers 3


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.

  • 2
    "Obviously web apps are somewhat easier to implement"—only if you already know how to do that. If your experience instead lies with native mobile apps, then it's harder to implement web apps.
    – user4051
    Dec 5, 2011 at 8:56
  • 1
    Obviously web apps are somewhat easier to implement and you just need one implementation for all types of devices... Right, because every browser works exactly the same and device characteristics like screen size somehow don't matter for web applications... Last, most platforms support developing in Flash No they don't, many do but not most.
    – yannis
    Dec 5, 2011 at 8:56
  • @GrahamLee: Even with all the browser quirks, it's less work than rewriting the UI in completely different toolkit, sometimes in different language. We currently have about 6 man-months to first usable version on new platform with native application. And we have custom GUI, so most of it is dealt with by getting a frame-buffer to display. We do have some other things (like location), but I doubt you could get under 3 man-months with a non-trivial application and I don't think working around browser quirks will ever be that much.
    – Jan Hudec
    Dec 5, 2011 at 9:06
  • 1
    Web apps don't have to require you to be on-line. HTML5 has offline mode.
    – vartec
    Dec 5, 2011 at 10:38
  • 1
    @JanHudec: WP7 uses IE9, which also supports HTML5.
    – vartec
    Dec 5, 2011 at 11:25

Where Jan Hudec gives a rather detailed/operational overview on the matter, I'm wondering if this is what you are looking for at the top management level, regardless of the requirements?

Maybe other factors come in to play, like time to market (web apps should be alot quicker as opposed to developing for a number of platforms), required skill set (standard web tech vs java objective c etc.), maintenance cost and so on.


We are taking a mobile web app approach, and making use of jquery-mobile.

It simply halves the development for us as we won't have to develop to the two major platforms separately (android and iOS). This means we do not need to care about "browser quirks" as the jquery team handles them.

Also, we are already proficient with javascript and jquery.

We may also create a very basic app for each platform that simply opens the mobile website.

  • PhoneGap can help you wrap this up in a basic app for you
    – Syg
    Jan 11, 2012 at 12:28

Not the answer you're looking for? Browse other questions tagged or ask your own question.