Progressive Web App vs Native App Decision Checklist

Last Updated - Wed Jan 20 2021

An online interface for every business is more important today than ever. Consumers are staying home and ordering online at record levels. Employees are working from home and on their device of choice.

Your business needs an easy and accessible presence.

As a business owner you have two choices, native applications and progressive web apps (PWA).

The web has be around since the early 1990's and is ubiquitous around the world today. People open web sites and applications using a browser like Edge, Chrome or Safari.

Web sites have offered online ordering, customer service and application experiences for almost 30 years.

When Apple introduced the iPhone in 2007 they followed up by introducing the world to native apps and the concept of the app store.

It was a hit.

There were apps for everything. Most of the time I shook my head at how many apps were available. Most seem to do little to nothing of value.

Most were nothing more than the same content and interactions available on a website.

Advanced functionality was a big reason many raced to ship a native app. In 2008 the web did not have many native features, much less a responsive design system.

Fast forward to 2020, the web has reached feature parity with native mobile apps. Five years ago we passed Peak App. The point where most adults did not download an app within a month, or even a year.

Over the past decade a new class of website has emerged, Progressive Web Apps. They are websites, but leverage the latest technologies to offer native app quality. This includes the ability to install a PWA on your phone and desktop without a store.

Native apps are also expensive to develop. They require multiple versions for each target platform. This means costs are exponential to the business.

The web reaches everyone on every device and browser with a single solution.

Yet the perception is you need a mobile app.

This creates a problem for brands. Businesses are always asking which channel should they choose to engage customers.

I have written several articles about native apps vs progressive web applications. I thought I would add to the list today a checklist to help you decide what is right for your business.

I compiled a list of common topics to help you determine if a native app or a PWA is right for your brand.

The list distills 13 of the most common points. I also hope to dispel common misconceptions propagated around the web about, well the web.

The list and if a distribution channel supports the feature is in a simple infographic. You are more than welcome to download and include in your own content.

Let's get started!

Faster Time to Market

Much is made about getting an application done fast. There are examples littering the Internet about getting to market in hours, days or weeks.

The reality is very different. Most applications delivered super fast are barely proof of concepts. It does not matter if it is a native or progressive web application.

I have inherited several of these rapidly developed applications to 'improve'. The only real course of action is to start over because they lack many key features, especially related to security.

So what about the web compared to native to reach production?

The web wins hands down. The single application codebase and language mean you can focus. This also means ongoing maintenance and updates are easier.

Native requires multiple applications and codebases. This often means duplicate developers or teams to manage. Ongoing maintenance is also multiplied across each platform.

Native requires an iPhone, iPad, Android phone, Android tablet and Windows application. Each platform has different user interface guidelines, different APIs and languages.

Sure there are tools that help, like React Native and Flutter. You still have to account for each platform and there is no real code once deliver to all solution.

Apple's fluid requirements mean they could and most likely will remove those options. This leaves Apple's proprietary language, Swift.

Developing for the web requires using a common set of APIs. Standardization bodies, not a single company define these APIs.

Modern web applications and sites are mobile-first responsive. This means they deliver a layout for the user's viewport using the same markup and CSS.

The power of a single codebase and common APIs means you have a single application to maintain. This alone means you can deliver your experience faster and cheaper than native.

Access to Device Hardware

The web did not have access to much of the device hardware when the first smartphones were released. I mean at that point there was not much demand for low level access.

Over the past 13 years web standards have evolved and added more and more functionality.

Some common examples are Geo-Location, camera, microphone, gyroscope, push notifications, GPU accelerated graphics, biometric authentication, USB, Bluetooth and much more.

The web has reached almost 100% feature parity with native applications. The few device APIs not offered by the web right now are rarely used in native apps. Others pose a privacy or security risk and should not be available in native applications.

Of course the one barrier to some of these features is Apple. Safari is a limited browser compared to Chrome, Edge, FireFox and other browsers. Plus Safari is the only browser allowed on iOS. This can limit some capabilities for this desired consumer market.

The Apple limitations should not scare you. Most are not required for create the desired user experience. Polyfils and work arounds are available for most iPhone limitations.

A couple of missing APIs in iPhones and iPads I have built applications to use are USB and Bluetooth. These APIs provide low level hardware access. They are typically used for business tools. Not something a consumer facing application use.

Since these applications were for business productivity the stakeholders used Android and Windows. The hardware was much cheaper, so they won there too.

For the most part the web can access device and platform APIs. Don't let the few, rarely used APIs deter you from choosing a progressive web application. And don't let Apple's lack of functionality scare you either.

High Quality User Experience

User experience is a subjective value. Yet, there is a reasonable amount of scientific research around what works and why.

Microsoft, Google and Apple publish their user experience guidelines, which you can follow using HTML and CSS. I am personally a fan of Google's Material Design and Microsoft's Fluent languages. I try to integrate these concepts in my applications as much as possible.

User experience is about making the user successful with the least amount of friction. There is no real technical limitation here. The web is suited for great user experiences.

You are free to design and organize you application as you like.

A key difference between PWAs and native is you are completely free to chose your design and experience. Before you can publish or update a native app it is subject to platform review

If you have heard the web is slower than native you heard wrong. Developers can code any application or website to render slowly.

Properly architected websites should render and be interactive within 1 second on desktop. Within 3 seconds on cellular connections.

Support for 3rd Party Integrations

Third party integrations can refer to several things. First is an external service provider like a payment processor, think Stripe and PayPal. Any good third party service provider should provide an API. APIs integrate with any platform, web, native and server-side.

Many of these integrations are done on the server. This means the client is not concerned with the integration.

Other third parties may manage analytics and marketing data. These two are often scripts or tracking images you include in your progressive web application or native app.

Again, from the client application perspective there is no difference between web and native. In fact I would wager there are more third party integrations available for the web. It has been around longer and reaches more consumers.

Security and Quality Assurance

The primary selling point Apple seems to make today in favor of the app store model is central security review.

On the surface this may sound nice, but does it mean the user's data is secure. No, not really. Apple, Google and Microsoft can review the actual bits for common security patterns and reject in a similar way virus scanners do. They also evaluate the business model to see if users data is being used in any unapproved ways.

What they are not telling you is browsers do the same thing. Microsoft Edge, Chrome, FireFox, etc all have automatic security scanning features. The companies even maintain a list of known bad sites and may even prevent a user from accessing any of the site's content.

Progressive Web Applications must use HTTPS, a secure networking protocol that encrypts all interactions between the customer and the cloud.

This means the user or consumer's experience is just as safe as a native app.

But there is more to the story.

Security does not stop in the device or network. Most of your security concerns should lie in how data is managed in the cloud. Apple, Google or Microsoft does not perform security reviews of any application API. This is important because the majority of any application is on the cloud. The application experience, what is provided by a PWA or native app is just the user interface to the back-end.

Hackers tend to focus on these backends due to the large volume of data available with less effort.

You might be surprised at how many applications use unsecured back-ends. Just last year I was asked to migrate a native application to a PWA. The application's API had no security in place, not even proper use of authentication.

This was a health care application that I was able to download the entire database within 20 minutes of my initial access. For the record there was no documentation, just a few example URLs to start with. All the patient data was accessible and if I wanted I could have run a remote SQL script to delete the entire database.

The app was in both Apple and Google app stores and had passed their security review.

App stores to not add any value to app security.

Single Codebase

I already covered the concept of a single code base in the time to market section. But let's review.

The web uses HTML, CSS and JavaScript to create an application. These languages work in all browsers and use common APIs. This means you can code once and deliver everywhere.

Native requires at least three different codebases and often more developers and teams. Each app stores requires its own design guidelines and tools.

The web has no single required design aesthetic. This gives you the freedom to chose and express yourself and brand as uniquely as you like.

Three applications and code bases is a minimum. This fragments even more when you want to reach iPhone and iPad or multiple Android devices.

Responsive design means your single codebase just works everywhere.

Can Work Offline

Offline capability is a great user experience, when executed correctly. The key value to having an application that works offline is the ability to work even when the network connectivity is poor.

I am asked all the time to upgrade applications to make them work offline. Offline functionality and requirements vary, so no one solution fits every application.

Most apps, native and web, still lack any offline functionality.

For over 10 years the web has had the ability to function offline. I started building web applications that worked offline back in 2010. Today the offline control offered through service workers is amazing.

Service workers make it possible for the web to work offline. They also make it possible to include much of the server-side rendering and logic handling in the browser.

Since both native and web offer this functionality there is not a difference between the two platforms.

Inexpensive

The topic of cost to deliver an application is a loaded question. The answer, not matter the platform is 'it depends'.

Native and web both have to contend with stakeholder expectations and personalities the same. We will assume that factor is a push.

So let's go back to the codebase factor. One codebase and application is much cheaper to code than 3 or more applications.

Is it 1/3 the cost? Probably not, but 75% cheaper for a PWA is not unreasonable.

I would also point out when comparing PWA vs native you are focusing on client application development. Much of application resides in the cloud, behind an API. This part is common to all client application interfaces.

Sorry, as much as I love the client I spend at least 75% of my billable hours working on the application's server-side components.

With the remaining 25% (and that is a simple example) dedicated to the client-side of a PWA, native apps are closer to 40%. Native apps need an extra 15% of both time and money to deliver the same experience.

These numbers are hypothetical, bust representative of real projects and budgets.

Long-term Investment Protection

Software development is not cheap, at least not for a real production application. So you want something you can rely to be usable for a few years.

Native applications are beholden to the app store gods and their whims. This means every year you may and most likely will have to completely update your application.

Your app(s) may be removed from a store also at any time for any reason. The app store may randomly decided they did not like you, see Apple.

And yes, I have had more than one business that contact me about this very scenario. They want to migrate to PWAs, where there are fewer regulations.

Since the web does not have these restrictions you are free to keep your design and user experience as long as you feel they are viable. Your updates and deployments are always accepted since you control distribution.

This of course assumes the cost of normal maintenance and updates. Just like your car, your application will need updates over the course of its life.

The web means you can keep that car till the wheels fall off. Not until Apple or Google decide you should rewrite and spend more capital.

Direct Linking

When it comes to marketing nothing beats being able to create direct landing pages. You can track what works and does not work easily. You can create ads to target specific landing pages with specific offers and more.

Of course you can use those same landing pages for native. Then direct a user to their app store. Next you pray they fall through the 6-10 step app installation process to install your application.

Most don't make it to the end.

When a consumer visits your PWA landing page they install your application. That's right, no more is required to have your PWA locally run.

In fact you have already installed Love2dev just by reading this article.

Of course, as a brand you want more. You want that icon on the homescreen or start menu. You can then nudge the user to that point of engagement. Its a nice feature, but not required.

If you code your service worker correctly it can pre-cache your progressive web application assets. This installs the progressive web app. You are also in control of when those assets are updated.

As you build the customer relationship you can gradually ask for more engagement. I already mentioned adding to the homescreen. You can also ask for permission to send push notifications, location, using the camera and much more.

Plus PWAs work great for SEO since they use URLs, which directly link to specific content. Apps do not show up in search results. So your website is the front to pass them along to your app. Might as well skip the extra hassle to get an app install when you can accomplish the same thing without the store.

This is the biggest reason to chose PWA over native. How much easier it is to market your application.

Easy to Market

The less you spend on customer acquisition the better. The web is superior to native when it comes to customer acquisition costs.

Search engine optimization is cheap. It can drive hundreds of thousands of page views a month if done right.

Paid search and other online advertising channels amplify organic search's power.

Paid search often generates a visitor for $0.05 US. And like I explained before the user has your application installed as soon as they visit. You have to build the relationship to increase that lifetime value.

For an app you can use the same marketing channels. It takes several more touches or visits before most will bother to load your app's app store page. Then you hope they proceed through the download and install process.

Research shows most who start the app download process never finish. Even worse, only 1 in 10 will use an app more than once before deleting it.

App download costs range from $5-100 per app install. A huge range to be sure. Based on my research I think you can budget $10-20 per download for Android and Windows. For iPhone budget $25-40.

Compared to pennies for the web this is a no brainer

Control Distribution

If I have not convinced you yet to chose a progressive web application over native by now this one should.

When you chose native as your customer engagement channel you are outsourcing the control of your brand's distribution to a third party. That third party often does not care about your success.

Recent headlines only amplify this problem. Epic games (makers of Fortnite), Spotify, Match.com and dozens of other well known brands have gone on the attack against Apple. They cite Apple's unfair and ambiguous app store guidelines and taxes.

Other brands, like Twitter, Starbucks, Hulu and Netflix have been migrating from native to PWA over the past few years. Most of their native apps are their PWA in a native wrapper.

Netflix will not let new subscribers enroll through the app store. They funnel those sales through Netflix.com. It saves the millions each year in fees.

The battle has gotten so nasty in the past few months. The US Congress and EU are holding hearings about Apple's treatment of app developers. Apple has also sued app developers over their complaints.

Its ugly.

My advice is avoid the stores and control your own destiny.

Summary

As you can see the web has many distinct advantages. I did not even cover how much search engines drive direct engagement, where apps don't.

Don't believe the fake news about the web. 99% of what I read is not true. The web has not only added many layers of capabilities over the past decade plus it has also increased its security and privacy protections.

Most businesses are concerned with the cost to deliver an app. The web offers a more cost effective path to develop your customer engagement tool. It is also more cost effective for your internal line of business tools.

You should also consider the ability to engage. Yes an app install is a strong customer engagement signal. Online orders are an even better signal and you can do that without a native app.

Marketing PWAs is also far cheaper. Traffic is cheap and instantaneous installation.

Use this infographic checklist as a tool to help you sell the use of progressive web apps in your organization.

Progressive Web Application Development by Example

Fortnight Fights Back, Apple Pats Itself on the Back

The PWA Starter

Spotify, The Apple App Store & Why PWAs Rule