Should You Develop a Mobile Web App or a Native App?

July 11, 2011 Allan Baril

Here at Xtreme Labs, we often get asked whether it’s more appropriate to build a mobile web application or a native application. Both offer different perks, and we build on both depending on the situation. Here are a few things you need to consider before making your decision.

Since the introduction of the original iPhone, the discussion of whether to develop a mobile web app or a native app has been a popular one in tech circles. With the original iPhone, the decision was much easier: there were limited competing devices on the market. These days, when deciding whether to develop a mobile web app or develop a native app, there are generally three main things you need to consider.

1. Platform: There are many popular smart phone platforms these days, each with their own development environment. Apple’s iOS (iPhone, iPad) is based on Objective-C, an object-oriented language based on the venerable C language, while Android and BlackBerry development is focused on Java. With the Playbook, RIM decided to adopt Flash as the development environment, HP has generally leveraged web standards (HTML5, CSS3 and Javascript) and Microsoft adopted C# and .NET for Windows Phone 7.

If you’re planning on targeting all popular smart phone devices, obviously this list of different native apps and unique development environments you’ll need to consider is outright daunting. Developing a mobile web app has the promise of write once and use everywhere (except with Windows Phone 7, as Microsoft unfortunately stuck a variant of IE7.0 as the browser; although Mango should fix this). If all you need is an iOS app, then creating a native app should be sufficient, but when targeting all platforms, mobile web is definitely attractive.

2. Feature Richness: Another factor you need to consider is how rich of a user experience you wish to offer. HTML5 (along with CSS3 and Javascript) have added many important enhancements that provide great building blocks towards developing a rich mobile web application. For example, CSS3 has added simple animations, which on some devices like the iPhone provides hardware acceleration, allowing a rich, “native-like” user experience. HTML5 has also added support for off-line storage, lifting the requirement of needing a constant network connection when using a mobile web app. Even geo-location has been added to the HTML5 standard, allowing the mobile web developer to add locational-specific functionality to their app.

Unfortunately though, HTML5 does not provide access to all the unique functionality on the user’s smart phone. For example, if you wish to leverage the built-in camera, use the accelerometer, or provide complicated, OpenGL-based graphics, like those in games, you’re going to have to go native or at least take an approach where your web layer has to reside inside a native app. The other problem with a pure mobile web app approach is that each platform has unique user experience conventions. For example, the iPhone generally provides its tab bar at the bottom of the screen, with navigation at the top. Other platforms reverse this or eschew the navigation bar as they may have dedicated hardware buttons. These conventions help make your native application intuitive to the user of the platform as they don’t need to learn an entire different way to interact with each application. With a mobile web solution though, it is difficult to preserve these conventions across the board since you’re generally providing one solution for all devices. Of course, some mobile web sites will cater to the conventions of iOS, but you risk alienating users on other platforms. In general, the richer the user experience you need, the more you should consider a native solution.

3. Frequency of Use: Finally, the last factor to examine is how often your target users will interact with your application. If you envision them using your application on a daily or even weekly basis, then a native application likely makes sense. The user, who uses your application that frequently, will be happy to dedicate the space on their app launcher and the necessary device memory to keep the application around. On the flip side though, if the user is only going to use it once or twice a year, they will likely be hesitant towards loading a native application on their device. For example, consider an airline that offers a native app to help travelers check-in and determine flight status. I don’t travel that often and am not particularly loyal to one airline. I would generally be hesitant towards installing a native app from this airline, as I would likely not use it again for a long period, and would prefer to have a simple mobile web app provide this functionality. On the other hand, if I was travelling weekly or monthly, I wouldn’t hesitate from keeping the airline’s native app permanently on my device.

When determining the optimal approach, we need to weight the importance of each these factors, cost of targeting many unique platforms, richness of the desired user experience, and the expected frequency of usage. In many cases, it’s not necessarily an either mobile web or native apps choice, but one of doing both, complementing your native app with a mobile web solution. Returning to the airline example, we’d ultimately want to provide a simple mobile web solution to infrequent users, like myself. This solution would provide the basic, core functionality, while a richer native app would cater to frequent travelers, potentially providing extra features like loyalty mileage tracking and push notifications of deals and travel notifications.

Recently, mobile internet usage through native applications has surpassed that of internet usage through mobile browsers, leading people to conclude that the web, at least as we know it, is dead and will be replaced by native apps. Interesting how things turn, it was just over ten years ago, where the zeitgeist was that desktop web was going to completely disrupt and replace native desktop applications with your browser and Java replacing your operating system. What we’ve actually seen is a balance, much of what you used to do on a computer (e-mail, browse pictures, even casual games) has moved to the internet/browser, while other native apps have remained. I suspect that the mobile space will follow a similar pattern, with both native apps and mobile web apps finding their appropriate spaces and complementing, not disrupting each other.

Get in touch with us for more information.

About the Author


Writing and running Jasmine specs with Rails 3.1 and Coffeescript
Writing and running Jasmine specs with Rails 3.1 and Coffeescript

In this post I will describe one way to write Jasmine tests in Coffeescript, and test javascript files writ...

New in Pivotal Tracker: Auto-suggest for labels, improved Google sign-in
New in Pivotal Tracker: Auto-suggest for labels, improved Google sign-in

In this week's update to Pivotal Tracker, we've made it easier to apply and remove labels to/from stories, ...

SpringOne Platform 2019 Presentations

Watch Now