Why “Progressive Web Apps vs. native” is the wrong question to ask

Updated February 2018

Even though PWAs have been around for more than two years now, there are still a bunch of misconceptions about them: <strike>they only work in Chrome, they can’t be as smooth as native apps, there’s no full-screen mode, they have to be SPAs, building offline-first isn’t worth it etc</strike>.

All of these are false, and I wish Medium allowed strikethrough text, so I could emphasize the point.

Progressive Web Apps are a sufficiently established technology that big players like Twitter and AliBaba have adopted them with great success.

Also, Progressive Web Apps actually offer more hardware access than commonly thought. Here’s a screenshot of whatwebcando.today (itself a PWA, try it!) from my Chrome 52 stable on Android, as of September 2016 (in the meantime Chrome added Bluetooth support):

Hardware access includes

Upcoming hardware access

These features are being implemented or already work in some browsers:

Here’s Firefox 48:

Another important point to note is that the Origin Trials Framework (implemented in Chrome) enables manufacturers to expose and test hardware (or software) capabilities without having to go through the standardization process. For example, a phone maker could expose an API for reading the values of a pressure sensor, refine it, then submit it for consideration to the W3C.

Anyway, access to hardware features are only a subset of what makes a great app. There are also software features traditionally employed by native apps that are now available to web apps.

Traditionally native features that PWAs can also use

These features cover a lot of use cases, and many popular native apps nowadays could be rewritten as PWAs. Take Slack, for example. Its open source alternative, Rocket.Chat, is building a PWA version. For more PWA demos, see https://pwa.rocks.

While PWA capabilities are rapidly evolving, there are still somethings you can’t do yet.

Native features coming to PWAs

Native Android features that PWAs currently lack

  • contacts, calendar and browser bookmarks access (though lack of access to these could be viewed as a feature by privacy-conscious users)
  • alarms
  • telephony features — intercept SMSes or calls, send SMS/MMS, get the user’s phone number, read voice mail, make phone calls without the Dialer dialog
  • low-level access to some hardware features and sensors: flashlight, atmospheric pressure sensor
  • system access: task management, modifying system settings, logs
  • registering to handle custom URL schemes and protocol, or file types

For most use cases, PWAs can do the job and also be a much better investment — you don’t have to develop and maintain three separate code bases for Android, iOS and web. PWAs also have certain features that native apps lack.

Progressive Web App advantages over native apps

Source: https://youtu.be/qmE_jpnYXFo?t=96
  • discoverability — content in progressive web apps can easily be found by search engines but a content-centric native app like StackOverflow won’t show among app store search results for content that it does offer access to, such as “pwa vs. native”. This is a problem for communities like Reddit, which can’t expose their numerous sub-communities to the app store as individual “apps”.
  • linkability — any page/screen can have a direct link, which can be shared easily
  • bookmarkability — save that link to access an app’s view directly
  • always fresh — no need to go through the app store approval process to push updates
  • universal access — not subject by app stores sometimes arbitrary policies or (unintended)geographic restrictions
  • large data savings, extremely important in emerging markets with expensive and/or slow Internet access. For example, e-commerce website Konga cut data usage by 92% for the first load by migrating to a PWA.

PWAs in app stores

At the Chrome Developer Summit in October 2017, Google announced Trusted Web Activities — a new way to integrate your PWA with your Android app. You publish to the Google Play store a shell Android app that loads your PWA, so that users can discover it via Google Play as well.


Safari supports Service Workers in its Preview version, so full PWA support on iOS should arrive relatively soon — probably sooner than you’ll be ready to release your PWA.

Right now though, even without Service Worker, progressive web apps still offer all the other features listed above, except working offline and Safari/iOS push notifications (Mac OS Safari push notifications work). Users can still add your app to their iOS home screen and launch it in full screen.


“PWA vs. Native” is the wrong question to ask, because if you already have a product, you already have an app, a web presence, or both, and you should improve both. If you don’t have a product, then if you have the resources to build native Android + native iOS + web apps, and keep them in sync, go for it. Otherwise, choosing to build PWA first is a no-brainer in most cases:

Traditionally, you’d have to build

Desktop/mobile web + native Android + native iOS

You can, right now, in most cases, just build

PWA + iOS app

And once Safari implements Service Worker, it will be just


It’s not “PWA vs. native”, but rather “PWA vs. [web + native + native]”.

And in terms of reach, no native solution beats progressive web apps.

[This article was re-posted here from StackOverflow, given the danger of hosting valuable content there]