Ok, I’ll take a crack at it. Thanks!
Any updates on this?
Well, since a PWA is effectively using whatever the systems web rendering is (gecko in our case), there is not much to update. PWA is at best a bit of meta and a URL.
What would you like as an update? System integration of the packaging?
Right sorry for unclear question.
I understand that almost 6 years ago it looked like native browser did not support adding PWA as apps. Is this still correct?
Any disabilities in regards of web service workers on current version?
Is Android still only realistic option for modern PWA apps?
PWAs have full support on Ubports. But, it still doesn’t change the fact that they are just a url accessed via a Webview component. They are only ‘native’ apps in so far as they use the webview components supplied by the os. On sailfish, that is gecko. They are nothing more than a website existing in a browser cache.
When I want an isolated web app I make a QML app that just presents a webview (ie. much reduced browser) of a URL. That’s basically a PWA, although I can do much more, including adding interfaces that are not part of the Web part of the app.
Support for ‘installing’ PWAs like in ubports (or android) is missing on SFOS, but it’s also a ‘trivial’ thing to make.
I had to check on what this even means. There is no ‘standard’ for ‘service workers’. in QT/QML land there are WorkerScripts which can be used to communicate with a shim with embedded web content. I use this in my German Weather Sevice app to communicate between the native QML elements and the embedded webview of the rainradar weather service.
In short, my native app passes native service info, like Location, to a webview which is otherwise just a web page.