Native App vs. PWA: Which Is the Best Choice?

When it comes to mobile apps, the question we hear most often is: “PWA or Native: which one wins?”

The questions that immediately follow are:

• What are the differences and limitations of the two technologies?
• What are the costs and benefits of each option?
• Which option is the best fit for my project?

Of course there is no absolute answer, just a set of pros and cons for each approach. And when you choose a technology for a project, you can’t just look at feasibility and available features: you also have to weigh build costs, maintenance, development time, performance, usability, maintainability, resilience, SEO, discoverability and so on.

The goal of this article is to demystify the choice between the two types of app, while also giving an overview of the secondary aspects that orbit around building an app, and scoring the key features as if “PWA vs Native” were a virtual boxing match in an imaginary ring.

But before we start listing differences and strengths, let’s define what we’re talking about.

A native app is an application built in the native language of the device it runs on, meaning its views and features are created specifically for the operating system of the phone or tablet. Most target the two most widespread platforms: Android (written in Java) and iOS (written in Objective-C).

Native apps run on the device, and their defining trait is the ability to take full advantage of the device’s software and hardware capabilities (such as cameras, GPS, Bluetooth and notifications) and to interact with other apps or operating system resources (for example contacts, the phone, social apps).

The concept of a native app has broadened a lot in recent years, especially with the arrival of frameworks such as Swift (by Apple, 2014), React Native (by Facebook, 2015) and Flutter (by Google, 2017), which let you build a single hybrid app, which we’ll call “cross-platform,” and compile it into multiple native versions for the target platforms.

This has dramatically sped up native app development, cutting both costs and production time, while opening development up to a wider audience, such as people working on the web.

This spread, the growing demand for apps, and the levels of abstraction introduced by widely used languages have allowed these frameworks to grow quickly and reach a high level of quality, to the point that these cross-platform apps are indistinguishable from apps written in native code.

PWA stands for Progressive Web App.
A PWA is a web application, so technically a full-fledged website, that aims to give users an experience very close to a native mobile app in terms of interface, interactions and performance.

The word Progressive describes several aspects of how a PWA behaves. Mainly it refers to the “progressive enhancement” technique, which means splitting the initial load (the very first one) into two phases: the first, almost instant, for the app “shell,” the elements essential to using it (such as menus, navigation bars, footer, etc.), and a second “lazy” phase covering all the dynamic and heavy content.

After this first render (done once), the PWA provides tools for targeted content caching, so that from the second render onward you get an instant version of the app, restored from cached content, while new content updates are “lazy loaded” in the background.

Through aggressive cache tuning, this progressive technique lets you have an app complete with content that is available even offline.

PWAs have many advantages, but these are the main features that drove their adoption:

• Installable: you can add an icon to the home screen
• They receive push notifications from the browser
• Remote: they run on a server, not on the user’s device.
• Built with HTML, CSS and JavaScript.

The ability to add a website to the phone’s home screen like an app was enough on its own to earn this approach quite a few points in the “locked-down” mobile market.

Here are the main features that define a PWA, as listed by Wikipedia:

• Progressive - They work for every user, regardless of browser, because they are built from the ground up on progressive enhancement principles.
• Responsive - They adapt to any screen size: desktop, mobile, tablet, or sizes that may become available in the future.
• Connectivity independent - Service workers let the application work offline, without a connection or on low-quality connections.
• App-like - They behave like native apps for the user, in terms of interaction and navigation.
• Fresh - Information is always up to date thanks to the data update process provided by service workers.
• Safe - They are served over HTTPS so that the connection doesn’t expose information and content can’t be tampered with.
• Discoverable - They are identified as “applications” thanks to the W3C manifest[10] and the service worker registration scope, which lets search engines find them.
• Re-engageable - They make it easy to bring users back to the application through features such as push notifications.
• Installable - They let users “save” the apps they find most useful, with an icon on their mobile device’s home screen, without going through all the steps and hassles of the app store.
• Linkable - Easy to share via URL, with no complex installation required.

So PWAs and native apps are two separate worlds, but they get compared because they are two tools for the same goal: building a product that can reach the countless users of the mobile world.

Although PWAs are now used in a broader sense (for example as a performance tool for websites), and many web frameworks ship them preconfigured by default, they still have some way to go to close the feature gap with native.

A big point in favor of PWAs is that, since they sit outside the app store chain, they can avoid paying commissions on sales, and they are not subject to approval by big players like Google and Apple.

Native apps, on the other hand, have to use “In-App Purchase” mechanisms defined and approved by the stores.

When it comes to development time, for the same features, native apps cost far more than the equivalent PWA.

That’s because native development is much harder and slower; it also demands more care and precision in the interface and can rely on a smaller pool of integrations and plugins.

💁‍♂️ This round goes to PWAs.

When we talk about engagement on mobile, we mainly mean push messaging: the feature that delivers notifications and asynchronous updates, even when the app is closed, to engage users and regularly bring them back to the app.

But that’s not the only factor: how the app is “perceived” matters just as much for user engagement.

While both PWAs and native apps can send push notifications and build rich, functional, good-looking interfaces, PWAs have limitations on both counts.

Push

While native apps have full control over this tool, PWAs rely on web push, which depends on the browser hosting them. Safari currently doesn’t support web push while Chrome does, so to make it work on iOS, users would have to install the PWA with a browser other than the default one. Safari will probably support this feature in the future, but it doesn’t look like it will happen anytime soon.

Look and feel

A PWA’s interface is HTML and CSS built specifically to look like an app. To do this, developers often turn to Material Design libraries, which provide navigation bars, components with touch feedback and other refinements, but the result is often not as satisfying as a native version.

And, as we said, PWAs are websites running in a browser, so in some cases the feel can be less smooth and less responsive, for example with maps, scrolling and swiping, pinching, heavy animations and other edge cases.

🙋‍♂️ Two points to Native.

The main channel for finding a native app is the app stores, and they are a double-edged sword. On one hand they certify the quality of the app and give users a central place to search for apps and judge their quality from reviews; on the other, the growing number of apps in the stores (an estimated 2.5M+ on Google and 1.8M on Apple) doesn’t make life easy for app makers who want to be found.

Also from the makers’ point of view, rating policies among apps in the same category can make a difference in search ranking and download numbers, so an app has to go viral first to really benefit from the stores.

Native apps often have a dedicated web page too, to make up for searches through search engines.

By contrast, PWAs can use SEO tags and are indexed automatically. A PWA also has a manifest file, a descriptor of the app that makes it searchable and categorizes it as a mobile-ready app; its only discovery channel is the web.

That said, it seems possible to wrap PWAs and make them available on Google Play.

🙅‍♂️ In this round, Native and PWA each take home a point.

PWAs are self-contained and platform independent: you just put them online and they are instantly usable. They aren’t subject to store reviews and don’t need to be downloaded, but can be installed when users visit the app’s URL.

Putting a PWA online only takes HTTPS hosting and possibly some DNS configuration; today hosts like Netlify, Surge and Zeit let you do it quickly and for free.

Publishing an app on a store is no small feat, because it requires these steps:

• create the app listing;
• sign and upload the app to the store;
• manage versions;
• enable test users;
• check device compatibility;
• wait for approval.

All of these steps are required for publishing, they lengthen development time, and they often fail for a variety of reasons.

There are other distribution channels too, such as unofficial stores (Aptoide, Amazon Appstore), which let users install apps by enabling third-party installs, but usually anyone building a native app has every interest in being found in the official stores.

💁‍♂️ When it comes to ease of distribution, PWA wins a point here.

Updating a native app follows the same procedure as publishing it. With every update there is a risk of data incompatibility or errors with previous versions; and since it’s the user who decides whether to update the app on their device, updates have to be backward compatible.

Over time, the app can also run into incompatibilities and end up with features that are deprecated or no longer compatible with certain classes of devices, due to SDK updates, new permissions and new platform operating systems.

When that happens, you have to go back into development to update the app.

With PWAs it’s all much simpler, since the app is remote (not on every single device like native apps): you just update the application and everyone immediately gets the new version. It’s also free from device incompatibilities, and not hackable because it runs over HTTPS.

💁‍♂️ For this reason, this round goes to PWAs.

Native apps average around 40 MB, while a PWA is a few megabytes at most on average, which is the weight of the initial web page.

From this point of view PWAs are much quicker to use, since they don’t need to be downloaded and opened. And one of their strengths is loading performance, even on first use.

One of the big drawbacks of PWAs is memory and CPU usage, which drains a lot of battery. This is because the mobile browser hosting them has to work hard to interpret the JavaScript, and mobile browsers aren’t exactly built for that.

🙅‍♂️ This round is a draw: Native earns a point for performance, PWA for being a featherweight.

A native app typically accesses one or more of these device features: camera, Bluetooth, GPS, media player, contacts, microphone, accelerometer, NFC and many more. Native apps can also interact with other apps and accounts on the device, on top of deep linking and sharing between apps.

Take a social login with Google or Facebook: it can happen automatically using the app’s current session on the device, without entering credentials.

Doing the same with PWAs isn’t as straightforward: the features they can access are mainly those that have an equivalent web API and are supported by the browser in use.

Some features aren’t available in any browser, such as reading contacts or SMS from the device or interacting with installed apps.

Several features are available in Chrome and Firefox, but far fewer in Safari, which for example doesn’t support push notifications.

Below is a list from What Web Can Do Today of the features supported by Chrome and by Safari respectively.

🙋‍♂️ Flexibility and access to every smartphone feature give native apps two points in this round.

🤦‍♂️ PWAs risk a knockout if those features are essential to how the app works.

So who won in the end? On points, it’s an honorable draw between two very different fighters. 

All in all, PWAs are a solid alternative to native apps, with plenty of side benefits and a bright future ahead.

To boil it down: if you don’t need advanced or unsupported device features, can accept partial push notification coverage and are willing to skip the app stores, a PWA is a satisfying, cheaper and versatile solution.

In every other case, native is the way to go.

https://www.codica.com/blog/progressive-web-apps-vs-native/

https://codelabs.developers.google.com/codelabs/your-first-pwapp/#0

https://dev.to/uyouthe/pwa-checklist-2019-25j4