Skip to Navigation

Web App vs. Native App

Have you ever had an awesome idea for a new app? One that could potentially transform your business, an entire industry, or maybe even the world as we know it? If you have, we’re guessing you’ve probably hunkered down, worked out all the details, and possibly even come up with a snappy name for it. You know exactly what the app will do, what its value to users will be, and how in good time it will make you a multi-gazillionaire (yeah, right) …

Web, native or hybrid? Making the APP-ropriate choice

First you need to actually develop the app. To do this, there are multiple avenues you can take. And depending on functionality, UX and other requirements for the app, some options will better serve you than others. So let’s explore these development options and determine which one makes the most sense for your project (or future project). We’ll even conclude with a case study illustrating how we decided which approach was best for an app we recently developed.

There are three distinct development paths to choose from:

  1. Web app
  2. Native app
  3. Hybrid app

Let’s go through these one by one:

1. Web app

Build it once, run it everywhere

Pros:

  • Built on a single codebase, making it cost less to produce.
  • Uses web technologies, less expensive to develop than native technology.
  • Performance issues are diminishing as mobile browsers become faster and their Javascript engines continue improving.
  • No app store approval process needed, and updates to the app can happen instantaneously.
  • No revenue sharing with an app store.

Cons:

  • Some people believe web apps will always be slower than native apps.
  • You are limited to the functions made available by the device’s web browser. As it stands now in Mobile Safari, this means no camera, compass, video capture, microphone, user contacts, file uploading or push/local notifications.
  • Can’t be found on the app store. Being a featured app in Apple’s store, for example, can provide a huge marketing boost for apps with broad appeal and purpose, like games.
  • If you are looking to generate revenue, it will be up to you to build an e-commerce model and platform, just as you would do for a website.

When budget is limited and your required functionality is basic, the web app is a great option. Easier to build than native apps, web apps require an internet connection along with a mobile browser to work. This eliminates the download and install process associated with native apps, and means that gaining “real estate” on the user’s home screen requires a more convoluted process. Updates to the apps are pushed through the server, and not slowed down by app store approvals. Web apps can be harder to find than native apps (depending on your use case) since they don’t exist in the Android or iOS app stores. They cannot access all of the mobile hardware available to a native app, which can potentially stand in the way of your ideal user experience.

 2. Native App

The need for app speed

Pros:

  • Full access to the device’s hardware (GPS locator, camera, accelerometer, etc.) and OS features.
  • Better performance than today’s browsers, quicker animations, transitions and load times. The performance difference between native and web apps is far more pronounced on older devices and operating systems slower devices (e.g. iPhone 4 running iOS6)
  • Can store additional data offline.
  • Can be featured and searched for in the app store.
  • Implicit installation of an app to the device’s home screen. On iOS devices you can add any web app to your home screen, but it’s a convoluted and little-known process.
  • The designated app store handles purchase transactions on your behalf.

Cons:

  • Almost always more expensive to build, even on a single platform (Android, for example). Build costs, effort and timeline increase significantly – close to 100% – for each new platform.
  • Your app’s compatibility is highly subject to market penetration of mobile device operating systems.
  • In the case of iPhones, your app can only really be accessed through the device’s app store. This means, in turn, that your app must go through an approval process (which can be lengthy and arbitrary) and if your app generates revenue you must share a percentage with the store (30% for Apple’s App Store, including in-app purchases).
  • App updates must go through a new app store approval process each time you release one.

When your need is highly functional and your budgetary restrictions are less severe, the native app is likely your better option. Native apps are typically downloaded from Google or Apple’s App Store and operate on your device without necessarily being connected to the internet once they are installed. Being native to the device, they can access device hardware such as the camera or accelerometer to provide a more interactive user experience. Since each platform – Android or iOS – has its own native programming, the user engagement experience is quick and less intrusive than a web app being served through a mobile web browser. Differing programming languages for both platforms, however, translates to an increase in development costs, assuming that an app specifically needs to live under both platforms (Android and iOS).

 3. Hybrid App

An intriguing compromise

Pros:

  • Save development costs by building in a single codebase, yet still market your app in each of the major mobile app stores.
  • Access some, if not all, of the features locked out of the browser, such as camera, compass, contacts. For example, here’s a list of PhoneGap’s supported features.
  • Purchases are managed by the app store.

Cons:

  • Still subject to the app store’s approval process and revenue sharing. No instant updating.
  • The app’s performance is still dependent on the device’s browser capabilities.

Like the title suggests, hybrid apps lie somewhere in the middle of the two routes outlined above. Similar to web apps, they are built using one framework and then packaged inside a native container to take advantage of some device hardware. Available through app stores, they take advantage of store search discoverability and simple home screen installation. Notifications can be served to the user bringing them back to your content, whereas pure web apps rely on email or SMS to do that. The hybrid approach lacks in performance when compared with a native app.

Still not sure where to begin? Follow our trusty decision tree below to reach a conclusion!

Web vs. Native vs Hybrid App Decision Tree | Trigger

Click to Download: Web vs. Native vs Hybrid App Decision Tree | Trigger

Applied approach

We applied this same decision logic when developing an app that we pitched to one of our clients.

The app’s main objective was to eliminate wait times for customers by directing them to a vendor location that could provide service quicker than any other location. This would be based on the driving distance/time and the customer’s position in the queue. To make this happen, accurate GPS map functionality was needed that displayed vendor locations and helped the users weigh their vendor location options based on their turn in the queue and current distance from the location.

To make the app aware of the user’s location, display the closest vendor locations, and eventually provide turn-by-turn directions to that location, we needed to tap into the operating system’s native map applications along with the device GPS. We were also concerned about having a potentially sluggish browser struggle to handle the location functionality, and since our future development path included inherently native features, like the ability for the user to keep photo records via their mobile device’s cameras, we knew we had to explore native app development as our first choice.

It was going to be expensive. To achieve the required level of market compatibility, we would have to develop two separate codebases for iOS and Android (these two operating systems represent the majority of active mobile devices currently in use). Luckily, we had partners willing to invest in this effort. Having those additional resources meant that we could tackle the extra development and maintenance that the native route demanded.

Those were our circumstances. Yours will differ, and we hope that sharing our experience helps you choose the best path for your next app project.