Correct me if I'm wrong (I'd actually love to be wrong), but browsers don't let you do silent pushes, and background data fetches are pretty limited, which makes it hard to do something where the phone gets updated frequently with non-urgent data, so that when you open the app/page, you have current data regardless of connectivity when you open the app, assuming you've got at least intermittent connectivity.

Weather, headline news, sports scores, non-urgent messaging could really use silent push to get data synced whenever you want to use it, but clearly not with Safari on an iPhone, and I don't think you can do it on Android without an app either.

Push is supported by all competent browsers, which of course excludes Internet Explorer, Android WebView (the shitty built-in one) and Safari (iOS and desktop) [0]. Firefox (on every platform but iOS) even supports a limited amount of silent pushes. I personally wouldn't want silent background pushes to an installed web app anyway, I don't see what data is important enough to sync but not important enough to notify about. Such a mechanism would absolutely ruin the device's battery life.

Google, being Google, have developed a Background Sync API [1] that can achieve background sync without notifying the user. This also extends to Edge and Opera and such because they share an engine.

I can see the use in a system where you sync data to a device that has intermittent connectivity, but I've honestly never seen such a system work for native apps when I've had intermittent connectivity myself. Even Google's automatic weather notifications don't show the right weather until I tap then and a web search loads.

Your background sync requirement is a nice to have and it'd certainly be a reason to use the app instead of the web version of a service for users with limited connectivity, but they're not really strict requirements for most applications. The applications we use today mostly consist of scrolling and connected browsing, with some data management and sync in between. For example, I browse twitter through the web app and outside the "fleets", whatever they are, that Twitter simply decided not to port, I'm not missing anything. I get notifications, I can browse, I can compose, there's really nothing more I need.

In the end, Apple's (intentional, probably) nerfing of Safari is what primarily stands in the way of proper mobile app support on the web. Notifications are a feature that I'd say most apps would require these days and Apple simply refuses to allow them. There's plenty of other WebKit gripes that developers have to overcome to program for iOS, but the complete lack of certain features is absolutely the worst.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Push_API [1]: https://developers.google.com/web/updates/2015/12/background...

Nitpick: background processing doesn't generally kill battery life because the platform API's provide guardrails around how long/frequent you can run, and batches as many wakeups together as possible. You essentially have a runtime budget you deplete as you run.

That said, you're right that most apps dont truly take advantage of background processing. What you have to understand is that the lack of background processing is what keeps notifications unsupported on iOS. Not only can you not support push messaging natively, but you can't _replicate_ a push messaging system either because there's no way to run code when your webpage/PWA isn't in the foreground.

Why the heck do you need to be constantly pushed headlines, sport scores, and non-urgent messages? Just make them load fast, so when you only use resources on the device when the app is actually in use.

It's exactly this kind of wasteful resource usage and the accompanying notification spam that drives me to avoid native apps in the first place.

Because I want to use these things when I have no connectivity. And I don't always plan ahead for no connectivity.

Given where I live, my big one is ferries. When I get on the ferry, it's a nice time to see what's going on in the world, and what the weather will be like, and maybe check work email (before I retired), but I can't do any of those in an online only world because cell coverage is very spotty. For the small handful of apps that manage a data store on the device, I can use those and catch up on things and queue outgoing messages. I'd like to make some more things for me, but native Android development is beyond my patience, and PWA doesn't have the capabilities, and some horrible blend of the two is what's wrong with today's world :p

"Proper" app development treats the network as optional. Its surprising how spotty connectivity is in the real world, and so its a huge UX boost to load data predicatively when possible (not to mention that running offline-first is a magical experience for the user).

Web notifications don’t work on iOS and I’m assuming Android as well? Serviceworkers aren’t woken up in response to a background push if your phone is lock and not on that webpage.

From a user standpoint, Web Notifications work quite well on Android. When using Chrome for Android (Chromium), each site is assigned a separate Notification Channel so users can change notification priority or block notifications. Firefox for Android (Gecko) works similarly but without Notification Channels.

Web notifications work fine on Android. Has Apple still not fixed notifications then? I was under the impression that they claimed to have massively improve Safari during last year's conference?

AFAIK web notifications do not exist on iOS.

OK, well iOS doesn't adhere to the standard, which means most of the US mobile device market does not support it.

Yeah, not supported on iOS.

Well, there was technically that iOS wallet/pass trick - dunno if it's been plugged tho.

Otherwise, yeah.

not on mobile safari

Right, and for those who aren't aware, that means not on any iOS browser since they all (are required to) use safari under the covers