2

When you put a Progressive Web App inside an APK, to sell on Goolge Play, for example by the use of Bubblewrap and Trusted Web Activity, the PWA can not interact with the Android APIs. Correct? If I have misunderstood this, please correct me and point me towards documentation.

So even though it is an APK, and it comes from a trusted source like Google Play, the code it runs (Javascript) will not be allowed to do the same things a normal Android app can do. What is the rationale behind that? Google has a mission to make PWAs just as capable as native apps, so it makes no sense to me.

For example, I need access to the file system from my PWA. I mean real access, not a neutered access like with the upcoming Native File System API. The user accepts file access at installation, and then my app can do whatever it wants. So I thought I'd just use the Android APIs to get access, but they are off limits. How have you solved this issue in your own PWAs?

Björn Morén
  • 693
  • 5
  • 14

1 Answers1

0

When you put a Progressive Web App inside an APK, to sell on Goolge Play, for example by the use of Bubblewrap and Trusted Web Activity, the PWA can not interact with the Android APIs. Correct? If I have misunderstood this, please correct me and point me towards documentation.

Yes, that's right, event though it's something frequently reconsidered.

So even though it is an APK, and it comes from a trusted source like Google Play, the code it runs (Javascript) will not be allowed to do the same things a normal Android app can do. What is the rationale behind that? Google has a mission to make PWAs just as capable as native apps, so it makes no sense to me.

The goal is to enable a PWA, which is built for the web and uses standardised Web Platform APIs, to be opened as part of a native app (it can be the single Activity in the app or the app can have other Activities).

Overall, you can think the Web APIs as an abstraction layer on top of the native OS /APIs that allows the application to run in many different Operating Systems without any changes - developers shouldn't have to branch their PWAs to different OSs.

Providing access to native APIs would mean developers would mean two things: 1 - Developers would have to build their own abstraction layer to bridge the gap between OSs. 2 - Parts of the application would stop working in a regular browser tab (eg: when not opened in a Trusted Web Activity or equivalent in other OSs).

Therefore, even though we know there are APIs missing to enable every possible use-case, the preference is for enabling those APIs as Web APIs, via Project Fugu , instead of giving direct access to the native APIs.

I have asked the PM exactly this question recently on the web.dev/live event. Here's the relevant section of the video.

For example, I need access to the file system from my PWA. I mean real access, not a neutered access like with the upcoming Native File System API. The user accepts file access at installation, and then my app can do whatever it wants. So I thought I'd just use the Android APIs to get access, but they are off limits. How have you solved this issue in your own PWAs?

I'm not very familiar with the Native File System API. There's a thread on the WICG Discourse where it may be worth sharing the feedback.

Finally, Trusted Web Activity are not supposed to be a replacement for the Android WebView, and serve a slightly different use-case. When the web content is tightly coupled to the Android app (eg: is only supposed to work inside the app and not being loaded inside the regular browser or in other OSs), developing for the WebView will allow hooking up to all native APIs (at the expense of support for many Web APIs, like push notifications and others).

andreban
  • 4,621
  • 1
  • 20
  • 49
  • Thanks Andre, very informative! I think this is a strange design choice. Why not offer two publication paths: A. Upload the PWA directly to the store (Google Play, Windows Store, etc), and have it live in a sandbox. Inform the user that he is installing a web app. B. Embed PWA in a APK or EXE to access the native APIs through interop, when you need to break out of the sandbox. Treat it just like any other native app. As it is now, they are putting an artificial limit to what PWAs can do, for no good reason. – Björn Morén Jul 23 '20 at 10:22
  • If I use the Native File System API, it will require that I show a dialog for each new file you want to load/save from the PWA. Imagine having a data structure that is better saved as multiple files, and the user must give his ok on each and every file that is saved. That will never be accepted by the users. – Björn Morén Jul 23 '20 at 10:24
  • I'd also like to know where the PWA developer community is. Where can I discuss PWA development with other developers and provide feedback and ask questions to the API designers? Here on Stackoverflow there is very little, and if you don't ask the question in an approved format, it will be removed. On Google forums and Mozilla forums there is virtually nothing. This makes PWA development very hard. – Björn Morén Jul 23 '20 at 10:28
  • https://progressive-web-apps.slack.com/ has a lot of the folks from the community and may be good place to start. – andreban Jul 24 '20 at 20:23
  • Andre: That is a private workspace on Slack, and I don't know who to contact to be invited to join it. – Björn Morén Jul 26 '20 at 04:42
  • Sorry for that, you can use this link to get invited: https://join.slack.com/t/progressive-web-apps/shared_invite/zt-3dh4j6xz-6CeYdLUV14bnROnJMTT39A – andreban Jul 27 '20 at 12:26
  • Thanks Andre. I joined. But not much happening there either. One message in the #needhelp channel in four months. Now I realized how spoiled I was when I worked with Microsoft technologies like C# and NET. MSDN, Codeproject and many other great places. Looks like Google and Mozilla don't care about the community of developers. How do they even know what the programmers think of their APIs, if there is no way to contact them? – Björn Morén Jul 28 '20 at 13:58