A light bulb goes off. You have the next great idea for a mobile app that you want to develop. It’ll change lives. It’ll make you millions. What’s the next step you need to take?

One of the things you’ll need to decide early on in your mobile application development process is how you’ll build and deploy your app. There are two main directions you can go: native app or mobile web app. In this article, we’ll talk about the differences between the two so you can make an informed decision.

Native App vs. Mobile Web App: Definition

First, let’s define what we mean in this article when we say "native app" and "mobile web app".

What is a Native App?

A native app is an app for a certain mobile device (smartphone, tablet, etc.) They’re installed directly onto the device. Users typically acquire these apps through an online store or marketplace such as The App Store or Android Apps on Google Play.

What is a Mobile Web App?

When we talk about mobile web apps in this article, we’re referring to Internet-enabled apps that have specific functionality for mobile devices. They’re accessed through the mobile device’s web browser (i.e. on the iPhone, this is Safari by default) and they don’t need to be downloaded and installed on the device.

Comparison of Native App vs. Mobile Web App

Let’s do a quick rundown and evaluate native apps versus mobile web apps under these factors:

User interface

Development

Capabilities

Monetization

Method of delivery

Versioning of the app

Strengths

Weaknesses

User Interface

Some companies choose to develop both a native app and a mobile web app. Here’s a side-by-side look at Facebook’s native app and mobile web app:

Notice that, in terms of the general look-and-feel, there’s little difference between the two, making for a consistent user experience.

Development

Native Apps

Mobile Web Apps

Each mobile application development platform (e.g. iOS, Android) requires its own development process

Runs in the mobile device’s web browser and each may have its own features and quirks

Supporting multiple mobile web browsers can result in higher costs in development and maintenance, etc.

Users can be on different versions and can make your app harder to maintain and provide support for

Users can be on different mobile browsers and can make your app harder to maintain and provide support for

App store approval processes can delay the launch of the app or prevent the release of the app

For users, it may be harder to find a mobile web app because of the lack of a centralized app store (though listings do exist such as Apple’s Web apps and you can request to be listed in them)

Native App vs. Mobile Web App: How Do You Choose?

To help you decide how you should build your mobile app, ask yourself these questions:

Does the mobile app require the use of any special device features (i.e., camera, the camera’s flash, accelerometer, etc.)?

What’s my budget?

Does the mobile app need to be Internet-enabled?

Do I need to target all mobile devices or just certain devices?

What programming languages do I already know?

How important is speed and performance?

How will this app be monetized effectively?

Answering these questions can help you make an informed decision.

Conclusion

Whether you decide to build a native app or a mobile web app depends on many factors: business objectives, target audience, technical requirements and so on.

You don’t necessarily have to choose between building a native app or a mobile web app. As mentioned earlier, companies like Facebook maintain both native apps and a mobile web app. However, for many of us, budget and resource constraints will require us to decide if we need to build a native app or a mobile web app (or, at least, will require us to prioritize which one to develop first).

Related Content

About the Author

JT Mudge is the co-founder and technical director of LitmusBox, a web development services company. He’s been involved in web development and Internet business consulting for over 15 years. You can reach JT via his website, LinkedIn and Twitter (@jtmudge).

23 Comments

Of course, the big problem with this article is that Facebook – used as the real measure here, is actually mostly HTML5. There is an Objective C frame, but ultimately, Facebook’s content is written in HTML. It’s loaded – all the HTML, JS, and CSS – and rendered and displayed locally. That’s why the app is dog slow.

Rumors that Facebook are just days away from releasing a true native story are everywhere. Only then will I consider Facebook a “native” app. Any app that is just a wrapper around Webkit is more like a “halfway native” app.

Charlie

I guess you’re not aware, but the Facebook app is just a wrapper around a web app. So, as far as representing native apps, it really doesn’t. Path would be a better example of a native app, if you want to stick with social networking. Others would be Tweetbot, Paper, or Netflix. If you’re going to try and compare the two, choosing a proper native app will make for a much better comparison.

Solid info. One criticism though is that you use Facebook as your example of Native vs. Mobile Web apps. As far as Facebook’s iOS “native” app is concerned, only the chrome of the app is actually native. All of the other experiences inside of the window are actually HTML5 and not truly native. This leads to a far degraded user experience and it’s quite slow.

A better example might be to show off the Twitter native app vs. the Twitter mobile web app.

The comparison is great except that the example is a hybrid app and not a native app as others mentioned here. I think if there was a hybrid app comparison in there would have made more sense. As @DyanGalih mentioned, phonegap is one of the tools to create these hybrid apps. Basically with hybrid apps you are running a mobile web app in a native code frame.

Hans Sandholt

Great article. One major advantage with native app’s is the app can be useful even if the phone is not connected to the internet. This is crusial if information stored on the phone should be available for postprocessing etc.

Mimmis

Nice overview, JT!
With a cross-platform development environment like the MoSync SDK (www.mosync.com/sdk) and with MoSync Reload (www.mosync.com/reload), you don’ have to settle for all these limitations in mobile web apps vs. native apps. You can create apps for up to nine different platforms at once using the same code base and one SDK. If you prefer to use standard web technologies (HTML5/JavaScript) for your development, you can use MoSync Reload to easily create and output true native apps, taking advantage of all the native features of modern smartphones. Check it out – it might be a good fit for all those developers out there that want to create apps for multiple platforms and who want to enter mobile.

This is an excellent comparison of native vs. mobile apps. My only comment would be to point out that there is significant work being done by browser developers to add javascript device APIs to their browsers, which will allow web apps full access to the device’s hardware.

appMobi released “MobiUs” on iOS about a year ago, and it had full device API capability. Unfortunately Apple pulled it from the app store when it was open sourced in November. More recently, Mozilla and Dolphin have both announced or released betas of browsers with JS APIs that allow web apps full access to the device.

If you take away that distinction between Native and Web apps, the only thing left as a defining difference is UI speed, which can be an issue depending on what the app is trying to do on screen. Plenty of work going on to fix that as well – appMobi has delivered 10x speed improvement for games with directCanvas, and the jqMobi web app framework delivers native-like UI features on webkit browsers on both iOS and Android.

Probably the key advantage of web apps is the avoidance of the “Apple Tax” of 30% on all your monetization, and not having to be approved by the Apple App store before your app can be used. The downside, of course, is that you have to promote and deliver your web app yourself, as there is no central “web app store” yet.

The earlier comments are right on, Facebook isn’t a good comparison app.

The conversation of native vs web isn’t a simple one, the right choice is different for each situation – and there are times where you can roll a 80% native app and 20% might be served through mobile web, the trick is to make the entire experience feel like a native app. If a user doesn’t know then you’ve achieved your goal.

LinkedIn – All of LinkedIn’s native apps that you can install on your device are mobile web apps “wrapped” in a thin device specific wrapper so they can get into the devices app store. LinkedIn relies heavily on Node.js for speed and try and recreate a native app like experience. In a lot of ways they were successful, but for some users ( and if you’re looking for it ) you’ll see areas where movement, gesture interaction and loading of content that lower level of experience.

Example: On the iPad compare LinkedIn’s news section to flipboard. For the main app experience on Flipboard its all native – now there are places depending on the source of content where you will see web views pulled in – but overall the experience is of a much higher caliber. Now use LinkedIn on the iPad – this is all web app driven – its impressive what they did with mobile web – but its not the same as native.