undefined | Better HN

0 pointsusrusr2y ago0 comments

A separate app per PWA that is little more than a tiny shim for whatever API Apple refuses to provide in the browser (many of them for very good reasons) and a script for spinning up another instance of the system browser with the API shims available. That's the Tauri model: you wouldn't install tens of browsers, but tens of configurations for the browser that is already there.

0 comments

layer82y ago

It means that the PWAs wouldn’t appear as separate apps, but as tabs within the same browser app.

Also, unlike native PWAs, you couldn’t have per-PWA notification badges on the app icons (because there’s only one). A browser app could maybe emulate this by providing different widgets per PWA, but still it would be a less straightforward experience.

usrusrOP2y ago

On iOS, native app are not allowed to ship their own html renderer implementation and therefore have to delegate to the renderer provided by the OS. If that happens, does the markup appear as a view in the app instance, or does the content appear as a tab in the browser? I assume that it's the former. iOS Firefox is famously not gecko but a Firefox-flavored safari and if that would cause markup to appear as tabs in regular safari, FF-iOS would be little more than a URL bar. Each "PWA+" would be its own "safari dressed up as a different app", just like Firefox-flavored safari is.

This was about "PWA+" installed from the app store, individually, just like you can install both FF-iOS and Chrome-iOS (and it's still hardly more than a parody of Microsoft's troubles with forcing internet explorer into win98). Conventional PWA that don't come packaged from the app store appear as tabs or as separate depending on whatever mood Apple had been in the last update cycle I guess.

Klonoar2y ago

To be clear, you can ship your own renderer (I’ve done it for e.g Apple TV). You get fucked when you want your own complex engine with a JIT JS engine.

j / k navigate · click thread line to collapse