upvote
It is silly but you have to meet customers where they are.

I think the problem is also that PWAs don't have any discoverability, and no standardization. I did some consulting work for a company that had a PWA. They had a 200-line long react component that was intended to determine what modal to show the user depending on what web browser and OS they were using to instruct them how to install PWA depending on the combination of OS and browser.

This is a lot of friction for the dev, and it's not clear to an average user what a PWA is. But they are familiar with, and for better or worse, trust, the App store. If I didn't know what a PWA and a site said "open menu and click on 'install!'" I'd be very wary of following those instructions!

I think Android and iOS should provide some sort of hook between the app store and PWAs before they really start to catch on.

reply
Yeah, I had a lengthy customer service email template explaining how to install the PWA for when people asked about a mobile app. Almost nobody installed it.
reply
There's an install element in the works. Perhaps that will make it more obvious how to install it https://github.com/WICG/install-element?tab=readme-ov-file
reply
I actually don't know what you mean by PWA. Is that a mobile web site? And by installing it, do you mean installing a link to it on a phone's launcher?
reply
That, but with a little more ceremony. It gets treated as a separate app by mobile OS app switchers and doesn't show the browser's chrome or other open tabs.

https://en.wikipedia.org/wiki/Progressive_web_app

reply
Besides users being more familiar with apps in the past, PWAs are still kneecapped in some subtle ways to make them want apps. I wish PWAs were the norm, so much easier.
reply
From what I gathered with my imperfect data, almost nobody was using the app as a PWA even with an in-app nudge for it. I instantly got lots of downloads when I released iOS and Android apps. My users just don't want PWAs for the most part it seems.
reply
That's typical. I think it's mainly familiarity, which in turn comes from PWAs missing basic capabilities in the past or present so everyone made apps instead. Push notifications in PWAs is a recent thing. PWAs don't share cookies with browsers, which entirely breaks some auth flows like Firebase. It's still hard to tell users to install it as you mentioned. And PWAs didn't even exist at some point.

The other thing is, many websites have bad or broken PWAs. It's usually just the website without tabs or back arrow, which sometimes makes navigation awkward because they built it assuming a browser. I'll always use the browser over the PWA.

reply
It could be that your app is amazingly well done. But most PWAs and web apps turned into an "app" are not meeting my quality standards. It's usually a clunky experience (well, like a browser).

I think once you've seen the actual possibilities of what e.g. an iOS app can do, when done correctly, everything changes for you.

reply
My mobile app is pretty decent actually. Other than some stylistic differences, I can't tell where the native wrapper ends and then embedded view starts. The embedded view is a SPA though so it never does full page loads.
reply
How often do you need to push app updates in practice? In theory that's a one-off deployment on the app-stores.
reply
There's usually some random mandatory updates I have to do about 1-2 times a year, so you need updates even with no development.

My React-Native wrapper app handles native auth and native payments, so I occasionally need to tweak that, but it's rare.

I'm considering a rewrite in Capacitor so I can change those things without modifying the mobile app. It's not that releasing the mobile app is a big deal, but it's that it can take many weeks for users to update the mobile app, so I have to keep the website backwards compatible with the old mobile app. It makes testing new checkout flows and stuff more difficult.

reply
Ugh, I run a B2B SaaS app that's mobile friendly, but people keep asking for an app (and I really do need push notifications, I'm spending thousands per month on text messages right now), but I've been putting it off. Did the App Stores have issues with you publishing just a simple RN wrapper app?
reply
No issues at all. I have two tabs in the RN app. One tab is basically the entire app, which is just an embedded web view. The other tab is a basic account tab (sign in, log out, delete account, cancel plan). I also have native auth and native payments.

I'm not 100% sure yet, but I might regret using React-Native over Capacitor. I have to bridge things like auth and payments between the web view and the native app. For example, the web app has a flow where you need to login, so it opens the login modal. If you're inside the mobile app, instead of doing that, it sends a message up to the native app to open the native app's login modal. Then once login is complete, the native app sends a message into the webview with the auth token. Similar thing for payments. That all works great, but occasionally I want to make a breaking change. Since it takes many weeks to get an update rolled out everyone, I have to keep the webapp backwards compatible for a long time. That slows down iterating on stuff like AB testing checkout flows. I don't think I'd have to worry about this if I was using Capacitor because the native functionality would be mostly driven from the webapp code.

reply
SaasS or one-time? Did people pay via native App Store integration? Or pay via the desktop website? App price? Answers would be super helpful. Thanks!
reply
Its a monthly/annual subscription. They can pay on the website or via native payments in the mobile app. The subscription works no matter where you bought it.
reply