What's the Better Choice: A Native Mobile Application or Web App?

p>We spend much time developing new products for clients whose ambitions are to be as multi-platform as possible. Frequently, during the discovery, the conversation comes up about the order in which the applications are developed, or if one pathway is better than the other. Inevitably, that will result in a debate about whether to develop for native mobile or to create a web application instead.

What is the right answer? Well, at the risk of sounding like a broken record - it depends. Each approach has it’s own pros and cons, which you will have to weigh accordingly. Rather than try to convince you that one method is better than the other, I think it makes sense to lay out some of the benefits and disadvantages of each approach. As I always say, every project is different, so it’s important to consider how these factors compare against the desired goals for your project.

Now, I want to forewarn those that are very technically oriented that this post is meant to serve as a primer, and at best should be viewed as a web or mobile development “101” level piece. So, please don’t write me telling me how much I left out (which has been known to happen). Also, this article is not delving into the possibility of native, installable applications built utilizing web-based libraries. Rather, this is a conversation about web applications, usable via browser, and native applications which are installed on a device. 

Now, let’s dig in.

Web Applications

For this post, I’m going to define “web application” as any application that can be hosted via HTTP and served up within a browser or similar environment. That means these are applications that must be loaded via a URL, and not via a download from the Play Store or Apple App Store. Sure, you can run a web application within a native application shell, but we won’t go down that route in this example, as that has all sorts of implications of its own that can distract us from the spirit of the post.

With that said, here are some things to consider when it comes to web applications:

They Are Easier to Iterate: Web applications must be hosted online, and are accessible to users via live requests of files. As such, they are much easier to iterate. Instead of coding, compiling and submitting to the relevant authorities (Apple, Google) and then waiting for approval, web applications can be iterated many times per day, if they need to be. By amending the files that serve the app, you have effectively just released a new version. Therefore, bug fixes and new features are more flexible to develop, test, and release.

Cheaper to Develop: As the release cycle is faster and making changes is made easier, it logically makes sense that it’s cheaper to develop web apps versus mobile apps. However, this isn’t the only factor that determines why. One primary reason is that native mobile applications take on another layer of complexity when it comes to architecture. First, you have multiple operating systems – namely Android and iOS. While development across platforms is a bit simpler now and there are ways to make it less tedious than in the past, each platform still has its own rules to follow.

Secondly, native mobile applications are more involved in that they usually require some level of interactivity with a centralized server. This connectivity happens typically via an API or programming interface. Think of an API as a system composed of a series of pipelines between an application and a centralized server – without such a system to send data back and forth, there would be no way for a mobile app to function. So, when developing mobile applications that are native, you aren’t just building the applications but also building a series of API endpoints, or locations within an API that accept and send data.  This is an entirely different development project, which just doubled your work. Web applications don’t necessarily need an API. Though the web development world is quickly making the transition to be API-based, it isn’t necessary to go this route, which can result in significant savings for the development of a web application as opposed to native apps.

No Approval Needed: As stated above, there is no necessary approval from any governing body, such as Apple or Google, for web applications. This means that you can pretty much do whatever you want to do in building the application. This may or may not matter to you, but it is something to consider. 

Multi-Platform From Day One: Since it’s web-based, and running via HTTP, a web application is naturally multi-platform. As long as the design is built to be responsive to various devices, and is thoroughly cross-browser tested, there is no reason that a mobile web application won’t work on almost any device.

Native App Development

As I had explained with web applications above, I want to start by defining what a “native” app is. A native application can be best described as one that is written specifically for users on a particular platform. So, a native application for iPhone would be written specifically for iPhone utilizing perhaps the Objective C or Swift languages. The equivalent on Android would be Java. This approach has its benefits, but also some drawbacks worth mentioning. First, let’s review some advantages.

Offers Better Access to Native Functionality: Native applications make utilization of native functionality much more accessible. Whatever access is afforded to a device's functionality by the operating system can be made accessible to your applications when building natively. Examples of that can include access to the camera and it’s deeper functionality, access to the microphone, compass, accelerometer, certain gestures, and even near field communications (if you are developing on Android - Apple doesn't allow this). Web applications will not be able to dig into the depths of a device like natively developed applications will because those features are inaccessible.

Performance: The most reliably fast and responsive experiences will happen as a result of building natively. The simple reason is that the load and burden of the user interface rest on the device, and the data being funneled back and forth between the application and the external database is just that – data – which has a smaller payload and quicker transit times. By offloading the primary assets of an application as a downloadable package, the user experience will be faster for each user, and less dependent on bandwidth issues.

Work Offline: Speaking of bandwidth issues, native apps can be coded to work offline. While this is becoming less and less of an issue these days – even airplanes have wifi now – it is still handy in certain instances, depending on the functionality of your app. Web-based apps will always need a server which limits their capabilities in a low or no-bandwidth scenario.

Push Notifications: Native push notifications are reserved for applications that are installable on a device. As such, web applications cannot notify a user of anything when in a locked state. This may or may not matter to you, but if it does, you must go native. Also, on that note, it is worth noting that web applications can’t live on the home screen of your device, which means only by natively developing an application and receiving approval from the companies that oversee those processes can one have their applications loaded on user device home screens.

Beware…

It’s worth noting that native development has some negatives as opposed to developing web applications:

• It’s expensive: native development takes more time and therefore costs more money.
• You need approval: I’ve already mentioned this a few times, but I must reinforce: Apple or Google will review your application. Be confident you will receive approval before spending too much time and money on the development.
• It may not port from one OS to the other well: It is entirely possible that you’ll rebuild on another OS from scratch, even though there are now some libraries and tools to make this easier.
• You still need an API, Server, and Database: I am struggling to think of applications built today that won’t require some level of server interaction. So, remember that you’ll be required to create all of these components.

The Best Approach

It’s challenging to recommend what the best approach is for any particular person without having more details about a specific project. However, I’d use the following questions as guides in determining which route to take on your development project.

Are you budget sensitive, just proving concept, or otherwise bootstrapping the development of your project? (and, are you building a multi-platform environment that will work beyond mobile?)

If so, then build a web application that can capture the majority of your application's requirements. Then, you will have enough to either prove the concept works, run actual usability tests, and arrange for how you will get through the next step of development. Why invest more than you need to for something that is effectively an experiment?

Does your app REQUIRE access to native device functionality?

If so, then you clearly must natively build the application. Make sure before you develop that you are confident all of the device functionality you need access to is allowed.

Is your product or service mobile first?

If your goal is to build the next Instagram, a killer navigation application, or any other app that only makes sense on mobile platforms – then it probably should be built natively first. In this case, creating a web application wouldn’t get you anywhere from a foundational perspective. I’d only recommend making a web application first IF your project is intended to be multi-platform from the start.

Is this for internal use or global?

We see many development projects for use internally only. For example, internal workflow tools, sales management tools, and other systems that may require users in the field to access are all cases where there is no mass audience requirement. In this case, it may make sense to utilize a web application provided you can meet two criteria: first, the end-users have access to the internet at all times. Moreover, you don’t need native functionality as we mentioned above.

Final Thoughts

The question of web application versus native application comes up very early in almost every new project we are discussing with potential clients. While it seems like a topic which is different depending on client circumstances, the overall pros and cons of each approach stay consistent regardless. Hopefully, this post will help you better determine which pathway works for you. If you have any questions – reach out and ask!