Why “Progressive Web Apps vs. native” is the wrong question to ask
Updated October 2022
I wrote this post in back 2016, when Progressive Web Apps were very new. Fast forward to 2022 — PWAs have been embraced by Instagram, Twitter, Tiktok, Pinterest, Telegram and many other brands, enabling fast, reliable, engaging and installable websites.
The road here wasn’t easy, and many misconceptions about PWAs stood across: <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 Single Page Apps, 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.
Not only that, but PWAs offer key advantages vs. mobile apps: only one codebase, much smaller download size, seamless installation, and no need to keep pushing updates to the app stores (and hoping users install them).
Also, Progressive Web Apps actually offer more hardware access than commonly thought. Here’s a very old screenshot of whatwebcando.today (itself a PWA, try it!) from Chrome 52 stable on Android, as of September 2016 (many capabilities have been added since):
Hardware access includes
- geolocation — supported in the vast majority of browsers
- camera and microphone via the getUserMedia/Stream and the MediaStream Image Capture APIs
- Bluetooth via Web Bluetooth API
- device vibration
- battery status
- NFC
- device motion / position (accelerometer, magnetometer and gyroscope sensor access)
- screen orientation
- VR & AR
- hardware-powered shape detection API — available since Chrome 83 to detect faces, text and QR codes in images
- USB — available since Chrome 70 in dedicated workers
- fingerprint sensor — available since 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)
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+)
Here’s Firefox 48:
Another important point to note is that the Origin Trials Framework (implemented since Chrome 51) 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
- “installation” (adding an icon to the home screen), with the added benefit of an unobtrusive banner users can see when they first navigate to the home page of the app
- receiving shared data with the Web Share Target API
- triggering the native Android share dialog
- launching in full-screen
- clipboard access
- persistent auto-login using the Credential Management API
- hardware-accelerated 2D/3D graphics using CSS3, HTML5 Canvas or WebGL — check some of the HTML5 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
- registering URL and protocol handlers
- 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, has built a PWA version. For more PWA demos, see appsco.pe.
While PWA capabilities are rapidly evolving, there are still somethings you can’t do yet.
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
- alarms
- 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 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
Using Trusted Web Activities, you can 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.
iOS
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.
Conclusion
To recap, here’s why “PWA vs. Native” is the wrong question to ask. Assume you have a service with a web presence (if there’s no web presence yet, developing one is the first order of business).
- If you don’t have an app for it, it makes most sense to build a PWA and cover all your bases (web + mobile)
- If you do have an app already, then if you have the resources to build native Android + native iOS + web apps, and keep them in sync, go for it. If you don’t have the resources, a PWA offers the tremendous advantage of a single code base.
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 iOSYou can, right now, in most cases, just build
PWA + native iOSAnd once iOS Safari implements push notifications, it will be just
PWAIt’s not “PWA vs. native”, but rather “PWA vs. [web + native + native]”.
And in terms of reach, no native solution beats progressive web apps.
[Rre-posted from StackOverflow, as a backup]
