First and foremost, I'd like to point out that the aim of this article is not to explain what a Progressive Web App is. If you're interested in learning this, you can find plenty of resources online.
If you're still here, I'm assuming that you know what a PWA is and that you're probably considering to build one for your own business.
I'm going to use our own experience in building one for one of our products (eBeauty Asia), in order to give you an idea of the difficulties we have encountered along the way.
A bit of background first; our company decided to build an On-Demand Booking Service Platform for the Taiwanese market, and we thought that developing a web-based version first would be a good idea (instead of going into building 2 natives APP for both Android and iOS platforms).
We were in the middle of 2018, and by that time Google was really starting to push the PWA concept forward, specifically by directly prompting the user to pin the "APP" on their home screen on Android (if your website was fulfilling the PWA requirements).
For us, it felt like the right moment to try to build a product with a PWA-first approach. It wasn't.
If you look for some statistics online, you will find that for most major brands, by making their app/website PWA compliant, generally had an increase of user engagement and revenue. I think this is very true, but particularly valid when your brand is ALREADY on the market, and well-established. But as a new brand, choosing to build ONLY a PWA is probably a mistake.
There are still several issues that can't allow a PWA to completely replace a native app for example, so here is the list of the most critical ones.
Before I start, I'd like to precise that Apple (iOS) is mainly responsible for all the headaches found in the PWA space right now, and that we very rarely had any issues on platforms running with Android.
PWA in Standalone mode are actually not powered by a 100% Safari engine
As surprising as it sounds, and for some obscure reasons, when you decide to pin a PWA on your home screen on iOS, the process running your app will not be Safari. It's a "bastard" version of it, with its own sets of bugs and implementations. This usually means that all the new web standards implemented into iOS Safari are not going to be automatically reflected to the engine running your app in standalone mode. They could be, but it's not guaranteed. The WebRTC protocol is a good illustration of this for example, or the Camera Video Stream in the case of a QR code scanner.
The behaviour of your app will change from one iOS version to another (even between minor updates)
If you app is relying on oAuth login, and that your users are using an iOS version prior to 12.1, then you can forget about it. It will never be possible for your user to login in your app, for the simple reason that any links out of your app scope defined in the manifest file, will open Safari and quit your app. Also, the APP state is not kept neither restored when switching between the oAuth provider screen and your login page. So every time you go back to it, the app just restarts from scratch.
In order to solve this problem, Apple pushed the 12.2 update which allows to use the in-app browser (cool for oAuth !) as well as keeping a snapshot of your app last state. Which leads us to our next issue.
If you app is frozen for some reasons, it becomes impossible to kill it
N.b: sometimes for some unknown reasons, your app just start with a white screen and is impossible to kill. The only way is to "uninstall" the App from the standalone mode and to pin it again from Safari. Obviously, your users are not going to do this and will just consider that your app is buggy.
As opposed to Google, Apple is not prompting your users to install the app on their home screen
Not only are they not prompting the user to install your app, but there is also no way to know if the user already did it; just in case we wanted to design our own custom prompt. And even if we did, the "beforeInstallPrompt" API not being implemented, there is no way to do it programatically right now. So the user still have to do it manually by clicking on the share button.
Web Push API is not available
It is currently not possible to send Push Notifications to your users on iOS Safari using the Web Push API, so you might want to highly consider this fact if sending push notifications is a crucial feature for your App.
Not possible to debug in PWA mode
As if it wasn't already hard enough to debug issues from iOS Safari, it's not even possible to use the web debugger to inspect the app in PWA mode.
From our observations, people are just not used at all to "install" a website on their home screen. If you describe your website as being an "APP", the first thing they will do is to go on the App Store / Google Play. You can't blame them, this is exactly what Apple and Google educated people to do for years, since this is where their revenues come from.
The second issue about discoverability is that a PWA is still a website. So if you try to promote it through social media, such as Facebook, Instagram, or even by sending the link to your friends on communication apps such as Line or Wechat, your website will be open in the In-App browser, which, guess what, is making your PWA capabilities completely useless (unless you detect that the user is using it in an embedded webview, and gently ask him to open it in Safari / Google Chrome - But he has the liberty not to do that, and just to leave your APP).
Even worse, sometimes users will just scan a QR code that lead to your PWA. If they do it using the phone native camera app (on iPhone for example), it will open it in Safari and they will have a track of it in their history. But in most case scenario here in Asia, people will scan the code using their default communication App (Line or Wechat for example), and your app will be open in the In-App browser, which brings us back to the previous issue, with the extra problem of not knowing how to come back to your website again (since they scanned it from a QR code, they do not have access to the link, unless they save it afterwards, which is something that people won't do).
Alright, so with all of these considerations, what is a good use case for developing a PWA ?
I would say, for any situation that will bother your user to download and install an app for a specific and limited usage in time, and by keeping the following points in mind:
QR code scanning is not available on iOS
oAuth Login (depends on the user version of iOS, but you can always expect to find people that will not update their phone).
Web Push Notifications is not available on iOS
You're not specially expecting your user to come back and use your PWA on a daily basis, but you want to be able to take the opportunity to engage them to your brand by getting their information.
You're already a well-known established brand, so people will easily discover your PWA by typing your brand name on Google.
In the end, I believe that everyone should definitely make their website PWA compliant, as it could be a good opportunity to increase user engagement, but if the target is to build an "App-like" product, then this technology is far from being ready.