Yes. The "Trusted Web Activities" (TWA) API referenced in this article is just a convenient way to turn a web page into an Android Activity. (An Activity is a screen in an Android app.)
They don't let you paste an URL into the Google Play Store and convert it to APK automagically. You still have to install Android Studio, build your app as an APK, and upload it.
You could do this before by coding up a full-screen WebView, but TWA is just nicer in a number of ways.
If your app is a paid app, you'll pay Google 30% of that. TWA offers no convenient way to do in-app purchases; if it did, you'd still have to pay Google 30% for those IAPs.
> You still have to install Android Studio, build your app as an APK, and upload it.
:(
Not having to do that was what I was hoping for with stores allowing PWAs. Maybe it at least means that the APK only needs to be built once? If it has to be rebuilt for every release, I don't see what this offers that Cordova can't do better.
No. With Cordova or other hybrid solutions, you are typically shipping your web resources (HTML, JS, CSS, etc.) within your APK package. Also, the engine is different and isolated from the users’ browser, so no session or cache sharing.
With Trusted Web Activity you don’t need to package any resource file from your PWA (only native components, in case you want them); all your resources will be downloaded and updated on the fly from your Service Worker. Your PWA will still be rendered with the installed Chrome version, sharing all storage, cache, and sessions with the browser. Therefore, if your user has a session on your website opened when the user installs the app from the Play Store, she will still be logged in. The user is just installing a shortcut to Chrome using a special mode."
If I already have a web app with a built-in recurring subscription functionality, I shouldn't be required to abandon it just to get it published on the Google Play Store.
The entire idea of allowing PWAs on Google Play Store seems to be a part of Google's wider product strategy, which includes ChromeOS and Android Go, where using a native app is not always the best choice.
Microsoft Store has already been doing this for a while for a different reason: a lack of Windows alternatives to the most popular mobile apps.
Apple, on the other hand, has no business case for integrating PWAs into the App Store, because they would just reduce its revenue.
If they allow PWAs to get around the 30% IAP feature, then in 5 years there will be no more native apps, only PWAs. I doubt they will allow any non-google play in app purchases to take place.
I think the essence of a web app is that it works on any platform. It shouldn't know anything about Google Play Store or Apple App Store. Otherwise, it's just a native app with a webview.
They are called PWA, not WA, with P meaning Progressive.
The idea is that the app should check for available browser/OS APIs that progressively enhance user's experience.
And no they aren't necessarily just a native app with a webview, on UWP a store delived PWA has full access to the UWP APIs, just like .NET and C++, no need to write extra FFI manually.
They don't let you paste an URL into the Google Play Store and convert it to APK automagically. You still have to install Android Studio, build your app as an APK, and upload it.
You could do this before by coding up a full-screen WebView, but TWA is just nicer in a number of ways.
If your app is a paid app, you'll pay Google 30% of that. TWA offers no convenient way to do in-app purchases; if it did, you'd still have to pay Google 30% for those IAPs.