Web vs. Native On Mobile: The Never Ending Struggle

It seems to be an everlasting battle: what’s “better”: developing mobile nativeapplications or developing mobile web applications? Sadly, the answer is boring: it depends.

What matters to you as the developer?

Multiple-platform support. Web applications are a cheap way to go. Develop your application once, run on many platforms immediately. You can reuse the same code base on multiple platforms. When going the native route you will likely have to entirely redevelop (and maintain) your application on every platform.

Quick iteration. Iteration can happen quickly on the web: simply deploy a new version and all users get it instantly. Deployment of native applications requires an explicit update action from the user, plus a (possibly lengthy) approval process on some stores (e.g. Apple’s AppStore).

Integration with the OS. Web applications can do less than native applications. Need access to the camera, file system, address book, notifications (or even extend those features)? That’s a no-go for pure web applications (at least, for now). However, you can wrap your web app using PhoneGap to get access to many of those APIs as well, the drawback is that you lose the advantage of being able to iterate quickly, because you have to deploy your applications through app stores.

What matters to your users?

Performance. Web applications are typically slower than native applications. Of course, it is possible to write extremely slow native applications, but assuming good development practices: a native application will always outperform a web app. That’s the way it is, that’s the way it will be. However, on the long term, the performance of native and web apps will converge. The question is: what are your performance requirements? Is a web application fast enough?

Native look and feel. By default, a web application is not going to have a native look-and-feel. You can get quite far in mimicking a native look and feel (e.g. by using similar colors, similar transitions), yet — very likely — your users are going to be able to notice the difference. I have yet to see a web app where I couldn’t notice it was not native. The question is: does it matter? How important is it that the user notices a difference? Take the Gmail mobile web application, for instance. It doesn’t look native, but it looks clean and it works well. Does it bother me it’s not a native application? Not enough not to use it. I prefer it over Apple’s native mail application because I choose functionality over looks.

User experience. The way the user interfaces are laid-out and operated differ slightly from platform to platform. Although iPhone and Android appear to be extremely similar, there are subtle differences in how the user interfaces are organized and operated. Android makes use of the touch screen, as well as three (hardware) buttons: back, menu and search. No such buttons exist on iOS. The back button is typically an on-screen button, but the idea of a pop-up menu is inherently non-iOS-esque. For web applications this is a problem. First of all, a web app cannot take advantage of additional hardware buttons (other than the back button), but beyond that, you will likely not want to redevelop the way your UI is laid-out for every platform. Thus, you have to come up with some sort of greatest-common denominator: pick the user interface elements that all platforms support and use those exclusively. Is that a problem? Depends who you ask.


Even though I develop mobl (a language for mobile web application development) I’ll be honest. As user, if I could choose between a web app and a native app, having the same feature set, I would go for the native one. However, from a developer’s perspective it’s a much more difficult choice. It completely depends on target audience (what do they care about, what devices do they use?) and specific requirements of the application (do I care about performance, do I need OS integration?).

And I haven’t even touched on development models and tools yet.