Why “Progressive Web Apps vs. native” is the wrong question to ask
Updated September 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
- geolocation — supported in the vast majority of browsers
- camera and microphone via the getUserMedia/Stream and the upcoming MediaStream Image Capture APIs
- Bluetooth via Web Bluetooth API
- device vibration
- screen orientation and accelerometer access, including compass and gyroscope
- battery status
Upcoming hardware access
These features are being implemented or already work in some browsers:
- ambient light sensor (works in Firefox 48+)
- proximity sensor (works in Firefox 48+)
- accelerometer, magnetometer and gyroscope sensor access
- fingerprint sensor — available in Chrome 70 beta for Android devices and macOS’s TouchID (if you’re looking to accept payments, use Google Pay, which uses the Payment Request API if available)
- hardware-powered shape detection API — available in Chrome 70 beta to detect faces, text and QR codes in images (if the underlying hardware has the corresponding detectors)
- USB — available since Chrome 70 beta in dedicated workers
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
- push notifications
- working offline
- adding an icon to the home screen
- being installed into Android (i.e. in the apps drawer and in Settings)
- receiving intents
- triggering the native Android share dialog
- launching in full-screen
- clipboard access
- persistent auto-login using the Credentials Manager API
- hardware-accelerated 2D/3D graphics using CSS3, HTML5 Canvas or WebGL — check some of theHTML5 Canvas demos, WebGL sites or the three.js library. Game engine performance in WebGL is close to native.
- accessing the filesystem (Chrome and Opera) and reading user-selected files in any browser
- really slick, smooth UIs with 60fps animations
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
- handling intents — being the share target, e.g. a PWA chat app that receives an image to set as the user’s avatar
Native Android features that PWAs currently lack
Note that lack of access to many of the features below can be viewed as a security feature by privacy-conscious users.
- contacts, calendar and browser bookmarks access
- telephony features — intercept SMSes or calls, send SMS/MMS, get the user’s phone number (use properly marked up form fields instead, and let the browser’s autofill do the work), 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
- low friction of distribution — if your progressive web app is online, it’s already accessible for Android (and other mobile) users. 65.5% of US smartphone users don’t download any new apps each month. PWAs eliminate the need to go to the app store, search for the app, click Install, wait for the download, then open the app (until Android Instant Apps launch). Each of these steps loses 20% of the potential users.
- 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.
PWA support is “almost there” now that Safari 11.1 has added support for Service Workers with Safari 11.1, released on March 30, 2018 and available on iOS 11.3 and macOS 10.11 or later. Push notifications don’t work yet and there are some other low-level feature limitations compared to native apps, but Mac OS Safari push notifications do work.
“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:
- If you target the Next Billion Users, PWAs are the way to go. Android users are the majority, and data is expensive.
- If you have desktop users, build a PWA. Note that on Chrome OS and soon on other desktop environments, PWAs can run like native apps, in their own window without a browser bar.
- If you don’t need Android-specific native features (see the comparison above), build just a PWA (which will cover mobile web and Android), and maybe a native iOS app. Building a native Android app isn’t worth it because it won’t help you on the iOS front anyway.
- Building a PWA can bring up adoption even on iOS: AliExpress (Alibaba’s eBay) saw 82% increase in iOS conversion rate after building a PWA.
Traditionally, you’d have to build
Desktop/mobile web + native Android + native iOS
You can, right now, in most cases, just build
PWA + native iOS
And once iOS Safari implements push notifications, 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.