Integrate PWAs into Native Sharing UIs with Workbox | Hacker News Reader

Integrate PWAs into Native Sharing UIs with Workbox

web.dev

95 pointsfeross82 comments

Can someone point me to a successful PWA in the wild? I hear a lot of them as a web developer (usually the first thing I do after create-react-app is delete the service worker) but I don't think I have ever seen/used one.

I use the Twitter PWA rather than the Android client.

Wikipedia is one. I also use my American Express Savings bank page as a PWA. Its a very minimal PWA too which I love.

we recently converted Hookpad, our chord and melody sketchpad for teaching and writing music, to a PWA. Prior to being a PWA users often had to redownload samples each time they visited the site, and now they only have to download a sample once (our AWS bill has gotten smaller as a result). It was also really nice to suddenly be able to install the app locally and be able to use it without an internet connection.

Getting all that capability just by adding a manifest file and a service worker was pretty cool. I won't comment on the pros and cons of just releasing a native app (we are in a lot of schools that prefer a web interface so this made sense for us), but we are very happy with the added functionality and don't see any downsides.

https://hookpad.hooktheory.com

I only use Twitter via their PWA installed on my phone.

Also Discourse (where I work) is PWA compatible out of the box, so you can read previously visited topics offline, and install to browse in full screen.

In my view PWA has a limited scope in terms of kind of application which can be made with it. The number of things one need to deal with to build a PWA is just complex, troublesome hard to maintain and hard to debug. Like PWA relying on complex tooling (typical with JS front-end development), implementing local db and associated complexity and security implications (like what to use indexdb or localstorage or something else), making sure relevant data is always in sync with the servers.

So it's much easier to build a native cross-platform app instead of a PWA which is neither optimized for desktop web nor for mobile web (its a hybrid with it's own set of limitations on both the sides). I think framework like flutter is one viable way to build a cross platform desktop and mobile application including web (although it has it's own set of complication for building webapp).

Still I feel the best approach is to build a webapp for desktop browsers and do a mobile cross-platform development using technology like flutter (react native and others are still not very good when it comes to mobile apps). If the mobile app is sufficiently complex than just use SwiftUI or Kotlin directly with common services layer.

There are real drawbacks to native apps:

  - 30% app store payment cut
  - users don't like dealing with updating apps all the time
  - employees don't like installing apps on their phones for work
    unless it is a work phone (not as common anymore)
  - cross-platform frameworks have their own bugs and
    performance issues
  - dealing with app rejections / takedowns / searchability on the app store

There is a lot of accidental complexity in web technologies, but it isn't insurmountable, and there are of course plenty of successful native apps and apps written on cross-platform technologies. At the end of the day, the technology matters less than whether you are solving the problems your customers want you to solve. Many of the technical issues you list are also true for other technologies, cross-platform or not, and picking something that you and your team are comfortable with is almost always the right decision (assuming you aren't trying to do something at the hardware level that PWAs don't have API access to do, of course).

iOS / Android both auto update apps these days.

and i'd turn that off, since auto-update allows apps to remove features that i may want to keep by using the old version.

How is a PWA any better in that regard?

Auto-update allows app developers to add new features and fix bugs. And these are much more likely reasons for an update than removing a feature.

therefore, i have to spend time to read the update changelog, and make a decision to update.

If it was possible to rollback, then i would be inclined to enable auto-update. Case in point - i used to really like the youtube app on android, but newer versions have usability issues, poor video playback on 2x speed (this didn't happen on an even older phone on the old version of the app). And i cannot get the old youtube app version, even if i try to factory reset (it's literally removed from the OS image when i updated android).

It's these reasons, plus more, that i distrust auto-updating.

Like old uTorrent? Riddled with security issues? You're better off with the latest version, or with security backports (these are generally FOSS apps, or vendor supported proprietary software). If an application removes features you wish to keep, and there's an interest in such in the community, a fork generally happens (with FOSS). For proprietary software, there's something like OldVersion.com or APK Mirror. Either way, when developers don't listen to their users, it is time to quit being a user.

The PWAs of today are the tip of the iceberg. They've already made huge leaps in the last couple years. Google has talked multiple times recently about their internal goals to bridge the gap between web apps and native apps: https://www.youtube.com/watch?v=JKVZMqpiY7w - In my view, it's just a matter of time before the limits you speak of are non-existent.

Before PWAs I was pretty much on the field "native will win".

Nowadays I think that long term, the only area that native will have over PWAs will be gaming, as WebGL/WebGPU will never provide full GPU access.

What do you think about WebAssembly?

For one side I find it over hyped, it is just a bytecode format like many that came before it since UNCOL (1958), oversells security because while it is sandboxed, it won't prevent Heartbleed as bounds checking is only done at the edges of linear memory not to its internal contents, when multiple data structures are mapped into the same linear memory segment.

On the positive note, I find WebAssembly + WebGL/WebGPU has opened the door to the return of Flash like tooling and I am myself playing around with this, being a big fan of ongoing Unity, Blazor, Uno Platform efforts.

Not really, a large majority of mobile applications are nothing more than web widgets doing CRUD workflows.

Everything that I have coded in either Cordova/Ionic (not my decision), is perfectly doable in mobile Web, without having to deal with the platform idiosyncratic, specially on Android.

https://suttacentral.net/offline

https://github.com/suttacentral

I have a couple of CRA-based PWAs I wrote that are in production today, but I systematically do delete the service worker as well.

My fear of dealing with caching issues related to it kind of stops me from taking the time to dig into how to deal with it properly.

I use the Uber PWA a lot.

For all those who responded positively on using PWAs in the wild, can you explain why you prefer the PWA over the native app (if available)? I am curious why someone would choose it.

My favorite aspects: more restrictive hardware access (e.g. no tracking through Bluetooth or running in the background), having access via platforms that typically don't have apps (e.g. desktops), ability to modify behavior through extensions, caching can clear asset data if I don't use the app frequently (e.g. ridesharing)

The main thing isn't really about it being preferable, feature-wise - it's that it's the future of cross platform apps. If I could have apps like Photoshop or Ableton on Windows, Linux, Mac, ChromeOS, Android, etc - and they all work the same, that's a huge win all around.

First, you'd have to provide the web with 90% missing features that make such apps possible. And then make them available to PWAs.

So no, it's not the future.

There is extensive work being done to bring more native APIs to the Web

https://www.chromium.org/teams/web-capabilities-fugu

I wouldn't count on any other browser to be anywhere onboard with that. Chrome is known for implementing things in a quick and dirty way with complete disregard for input.

Also, Fugu will definitely no bring a signinficant amount of native APIs to the web. Here's the full list [1]

For example, the post I'm replying to mentioned Ableton. Well "I don’t know who the Web Audio API is designed for" [2] Oh, and then there's no guarantee Chrome will not break it the way it broke automatic audio previously [3]

The web is not the long-term future for any foreseeable future

[1] https://bugs.chromium.org/p/chromium/issues/list?can=2&q=pro...

[2] https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud...

[3] https://twitter.com/mcclure111/status/993627449991688193?ref...

The vast majority of native apps need next-to-no extra features on top of what the web provides. Facebook, Uber, Seamless, etc. etc... all they really need is an internet connection and location. And the web provides that.

The post I was replying to specifically said:

> If I could have apps like Photoshop or Ableton...

These apps require way way more than just internet connection and location. For example, you might have to implement your own renderers from scratch: https://www.figma.com/blog/building-a-professional-design-to...

One thing I like is that I can use them in my browser with tracking protection. Also nice to know it only has access to browser API's I give it access to - I'm always somewhat weary of what native apps do in the background.

And of course, there's the first-use hurdle. I probably wouldn't even have tried Pinafore if it hadn't been a PWA (in fact, I haven't tried any Mastodon apps). I could just go to the website, sign in, and I'm off.

I have a chat app that my girlfriend and I use. It's an installable pwa, has push notifications, does some caching of images and code, mobile and desktop views. Simple username and password signup and login so it's easy to use on a work computer.

The big hindrance is that iPhone doesn't support browser notifications. So it is really only app-like on Android. I think they are awesome but you are missing half the market.

> iPhone doesn't support browser notifications

Wow. What a joke.

Yeah, it also clears local storage if iOS is running out of space, which is common for a lot of these users.

It's not a bad thing. I have an Android and sometimes it's easy to miss out and allow push notifications on a website. Next thing you know, you're getting bombarded with push notifications about "12 things cats like to do in spare time" . It's not exactly straightforward to revoke a website's push notification authorization either and you need to go into settings to do that.

how do you not have the default set to 'deny all' for notifications in browser?

Non-HN users have it worst.

My parents (~75yo) have Androids and they essentially ignore all notifications. They allowed notifications on a few clickbaity news websites that spam then with tens of notifications a day. So they just don't know what it is and ignore them all, including potential relevant ones (like Whatsapp messages from family).

I, as a creator of a web app that would benefit a lot from notifications, would appreciate Apple adding push notifications to web. But I understand their choice

Thing is with iOS notifications as they are, if you ignore them the system suggests you to revoke the notification permissions so it's not really an issue

I am not exactly sure what you are saying as I don't have an iOS either, but I was talking about their phones that are Android.

Anyway, a mere suggestion to turn notifications off will be likely as ignored as the spammy notifications themselves. That are a lot of assumptions that people used to phone technology make about what is logical, easy, intuitive or obvious that do not hold for people who lived for 50 years before mobile phones existed

IIRC, my movie booking app has permission to read SMS OTP and once tried to bait me saying my Amazon package was delayed. Seems it read my package notifications too.

Hi soneca

This is unrelated to your comment, but I saw a past submission of yours https://news.ycombinator.com/item?id=12276956 and was wondering how your experience went (as I am now in the same position), but did not see an email in your profile to contact you.

Hi, I just saw this now. My email is in my profile, the last line.

Anyway, my experience went terribly! lol

Not much learning though. I stayed there for only 5 or 6 weeks because of a very toxic work environment, with a workaholic culture and a very micromanaging boss that did not trust me (not sure why I was hired in the first place). After that, I decided to study fulltime to learn to code and now I am a happy frontend developer.

But if you want to email me with details of your position, I do think I can help you.

I wish it was enforced somehow to have the user need to click a button signaling their desire for push notifications. The auto pop up is so slimy. Same with installing as an app. Very few first time users want to install your pwa. It would be much higher if it didn't offer an install till N regular visits.

It's already the case that the a user engagement heuristic (along with other criteria) must be met before the prompt appears, but the engagement heuristics vary between browsers, see https://developers.google.com/web/fundamentals/app-install-b...

Assuming you're talking about web push notifications in general and Chrome for Android it's super easy and exactly the same as Chrome for Windows & OSX:

- When on the site in question just tap the padlock/favicon in the URL bar, tap "site settings" and then you can see the permissions granted and change them as you want to.

- Alternatively, you can get to the same "site settings" screen directly from any web push notification in your Android notification panel simply by expanding the notification in the usual way and selecting "settings", which takes you to the "site settings" screen as before.

So if revoking from any page on the site and from any notification pushed by the site isn't straightforward enough then what do you propose instead?

Nor does it support getUserMedia... So no camera access for now. https://bugs.webkit.org/show_bug.cgi?id=185448

Somewhat niche, but https://strummachine.com/app works great as a PWA.

Starbucks has a PWA! You can get to it via app.starbucks.com. I'm not sure why it's not the default experience, but they're definitely already sharing code between starbucks.com and the PWA since the ordering experience is exactly the same.

We tried building one last year. The tools, standards, and documentation are a mess making this unnecessarily hard to test and develop. The experience of triggering the install button is downright inconsistent and surrounded by layers of indirection, validators that have to line up and a complete lack of any meaningful feedback when it doesn't work as you expect. Cross browser support is basically missing. Firefox does nothing productive with PWAs as far as I know and seems to be in no hurry to fix that. I'm not sure about safari/ios since we did not bother testing with that much. In any case, it's indeed extremely rare to encounter PWA buttons in the wild on Android and it seems like mainstream web sites are completely ignoring this feature other than maybe as a gimmick. IMHO major work to address all of the above is needed to change that.

Major work, as in, changing the dialog for installing the home screen icon from "Yes/No" into "Yes/No/Don't Ask Again"?

Major work as in making this a proper cross browser standard that results in people actually being able to use it instead of just talking about maybe using it some day when it stops sucking this much. The sad state of PWA is that if Chrome were to drop support for it tomorrow, very few people would even notice this and very few applications would stop working.

My impression is that devloping and testing this stuff is unnecessarily hard. The UI experience around this is flaky/inconsistent even when it works and the difference between this being broken/misconfigured or a user error is basically very hard to pin down. IMHO this is completely unusable in its current form and that's probably the main reason basically most people that ought to be getting some value out of this are either unaware it exists because they've actually never seen a real world example on a real world website adding any value whatsoever; or have made the conscious decision it's not worth their time (because of all the above). I'm in the latter category. I would use it but in its current form that's not something I can sell to a product manager.

The Starbucks PWA is really good. Also ft.com's WPA.

Outlook, Starbucks, Twitter

Plugging my company's PWA we recently shipped, with decent growth: http://superjumbo.tv. I was skeptical about going the PWA route for some of the reasons listed below (weird iOS restrictions, lack of Firefox support), but for our use-case I'm extremely happy with the results.

Looks like you are using suspense already in production?! How is it serving you?

Can I recommend something? We see much higher acceptance rates for location access when it is explained ahead of time. It's not clear what you need it for. But if you had a banner that explains why you need it in the right UI context, you can provide a button like "Enable sharing location" or whatever, and you'll get a much higher rate of success.

This is good UX

There are lots of apps in India. The ones that I can remember are : https://www.swiggy.com https://www.oyorooms.com https://outlook.live.com

All these are massively successful companies

Uber and Lyft both have really, really well-done PWAs. I used them extensively while I was on an older phone that didn't handle their native apps well.

https://m.uber.com

https://m.lyft.com

I guess we’re just plugging our own apps. Our company has spent a considerable amount of time optimizing our site for PWA compatibility. We have a lot of users so these kind of optimizations are worthwhile financially but also substantially ease the load on our front end and back end servers.

https://tracker.gg/tft

PWA features:

- Installable

- Offline caching

- Push Notifications

- Server side rendering

- Heavy use of edge caching (JS, CSS, images, JSON from our API), HTML caching coming soon

- Auto WebP Images support

- Preload/preconnect

- WebShare, Web Payments (Apple/Android Pay)

- Automatic image optimization using a custom edge-cached image manipulation service

- Self updating: despite being cached it will immediately upgrade itself if a new build is detected

I am working on one, and I am in the process of getting it on the Play Store as a TWA.

https://veggiechallenge.app

It's an MVP and that's something that the PWA has delivered on. We are still testing and working out the product.. after the user research, getting it on the web to know that the product has an audience and that those interested would use it was a very cheap and quick experiment.

It's a shame that iOS does not support notifications, and they do not accept TWAs on the App Store. Still have both of those to work out, and then I will be very happy with the experience.

There was a time on desktop when apps were super light. Chat apps took a few MBs of memory at most and used native controls.

Desktop apps are now bulky thanks to electron and take up collosal amount of memory and consume a ton of battery. I'm just afraid that with the rise of adoption of PWAs mobile apps are soon going to end up the same.

PWAs are generally significantly lighter, size wise, than Electron.

They are also significantly less powerful(i.e you can't even make a http request if the target doesn't whitelist you)

But the overhead of a dynamic language like javascript is always going to be much higher than Swift/Java.

Technically, this isn't always true. But in general the overhead of using JavaScript isn't the actual blocker for making good UI experiences for a platform.

Javascript is only one of the aspects. With native apps you also get Hardware-accelerated GPU rendering on UI controls. Thus making the UI appear a lot smoother.

While mobile browsers accelerate some parts of a webpage using GPUs, most parts of a webpage are not. This is due to the huge amount of complexity in layouts on a typical webpage. Same is true even for most desktop browsers, with the exception of Firefox when you use WebRender on a supported nVidia GPU ( but even that is in beta).

This is the reason why Google built flutter like a game engine, so that it could use the additional GPU horsepower on mobile apps to make UI appear more smoother and natural.

I thought both Flutter and Chrome use Skia for rendering. Does that not result in comparable GPU acceleration?

My Cordova-based app has a download size of 5MB. It is the most lightweight app I have installed. Most native apps come with at least 50 MB, often a lot more for god knows what reasons.

The battery and memory consumption depends a lot on what the app actually does.

Interesting, I thought Cordova was a browser wrapper, is there more that Cordova does? You're making me want to revisit Cordova.

No, it’s just a wrapper around WKWebView and has the capability to expose native APIs in JS. But it’s still very lightweight, because unlike Electron, it doesn’t bundle an entire browser.

I agree, there's too many Electron apps that dont even use most of the things you gain from it. Might as well have a more lightweight browser.

PWAs use the (very efficient) system webview implementation rather than bundling a full browser runtime like Electron apps do.

...no?

PWAs all share the same system webview. Three PWAs are essentially no different to having three tabs open in Safari/Chrome. The load they place on the phone is significantly less than most native apps.

I've noticed when having this debate that people seem to compare the worst possible web experience with the best possible native one. Yes, there are bloated and slow web sites, but don't try to tell me there aren't also native apps bloated to the point of absurdity, with multi-second load times even on a top of class device. And there are plenty of fast, small web sites too!

We can agree on UI, though. The web could do with a lot more native-level UI primitives (UITableView, please lord). As an added bonus this would help remove a lot of the bloat and performance issues as people try to replicate native behaviours in JS.

I recently integrated PWAs at our company. We offer a WYSIWYG-style editor for landing pages and integrated service workers mostly for SEO ratings and caching form submissions while temporarily offline (eg. on the subway). To me the whole thing is yet another clusterfuck of webdevelopment. Patchy support, governed by our "well-meaning" overlords at google and just a lot of non standard javascript magic involved. Just the way that the Install Prompt is handled is a good example. After some quite intransparent heuristic there is a "beforeinstallprompt" event fired. But you have to store that in an object and trigger it via an onClick on a button, otherwise the event gets intercepted.[0] I really hope that the standard will mature because the idea sounds really nice when you think about so-so mobile reception etc. but right now it's a bit of a pain still.

0: https://developers.google.com/web/fundamentals/app-install-b...

Apple just told w3c that beforeinstallprompt is bad and they will not implement it. Firefox won't too. So I really don't know what is going to happen going forward...

PWAs are a just little more than a page saved on desktop...prepare yourself to fi d out that most things you expect from an app are not working(i.e you can make http request only if the target has a CORS wildcard whitelist)

I don't really understand why people consider CORS to be such a blocker. It's trivial to implement and it's a useful security measure.

It's not a big deal if you're in control of the server you want to communicate with, but I wouldn't say it's trivial if you need to run your own server (as opposed to none at all) to use as a proxy to get around a CORS restriction.

You are restricted to consume content only from your server. A video player or just any data parser/interpreter is less useful if it runs only CORS-enables(and public) urls. Imagine cURL working only with CORS urls! Lol! PWAs value the site owner's "restrictions" more than the needs of the user. It's basically a kind of DRM so I believe PWAs are doomed to die unless they put the user in charge.

PWAs are crippled on iOS. This may never change. One of the many handicaps: lack of push notifications.

It's not even in Apple's best interest to allow PWAs to thrive, as the technology will compromise their walled garden.

Note: I do not think iOS supports this yet. In my testing, it only worked with Android.

Can you do this on websites for mobile that are not PWAs?

Reply on news.ycombinator.com