Web Push for Web Apps on iOS and iPadOS

https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/

by tech234a • 3 years ago

866 378 3 years ago

webkit.org

dhalwani• 3 years ago

Any demos of these capabilities on GitHub ?

bradeeoh• 3 years ago

The goal was to make it so sites that already support standards based Web Push work out of the box.

We'd expect most sites that support standalone mode when added to the Home Screen and support Web Push to Just Work™

3 real world examples are lichess.org for Chess fans, elk.zone for Mastodon fans, and twitter.com for those that still actively use Twitter.

jakear2• 3 years ago

If you're comfortable with a little `npm i && node server.js`: https://github.com/JacksonKearl/push-simple. This is based on Mozilla's example here, with some modifications to make it work standalone (and ask for permissions on-user-interaction, else it gets blocked by the browser): https://github.com/mdn/serviceworker-cookbook

toastal3• 3 years ago

But please no demos from other code forges, blogs, the spec, or the web in general? Code exists everywhere. Git is distributed version control—not centralizing code a feature. You didn't need to specify a specific place.

jakear2• 3 years ago

Strongest plausible interpretation doctrine would have you read this as "any git-accessible self contained minimal samples available"?

heygarrison• 3 years ago

This is awesome!

least3• 3 years ago

I'm already dumbfounded by the number of notifications I see pop up on relative's screens, this can only add to it. My default is to not allow notifications unless the application has a very good reason for needing it, and even then if they abuse that the notifications get turned back off.

It's one of many moves Apple is making in what I'm assuming is to assuage antitrust concerns. I think it's an overall good because having choice is good, but I do suspect I'll start seeing even more spam on people's notifications as a result.

tech234a2• 3 years ago

It requires adding the app your Home Screen first.

om22• 3 years ago

Good news! You'll only get notifications if you save a web app to your homscreen and then explicitly give it permission. And then you can choose to limit it to only badging, as with native iOS apps. Or you can use focus modes to manage which notifications you can get in different situations, as with native iOS apps. We've been careful to minimize the risk of notification overload as much as we can.

fundad• 3 years ago

they thought of everything huh?

least3• 3 years ago

I'm glad that there's controls in place to help minimize the issue, but I also know that companies do a good job of making people think that they need to enable settings on their phones that they don't.

That's of course not in Apple's control, it's just a meaningful downside to opening up push notifications to web apps on iOS. The utility for the few apps that can really benefit from this probably outweighs the downsides, but I've seen other people's phones and know it will also, and possibly mostly, only contribute to more spam.

Eduard2• 3 years ago

But it's bad news!

I can think of so many valid and proven use cases for notifications.

Requiring to first save a web app locally in order to actually benefit from its full feature set is bad UX. Apple.

lxgr6• 3 years ago

I completely agree about notification spam being an issue, but why should native apps get a head start over PWAs here?

There are many native apps on my phone that abuse notifications for spamming (often by not having an option that disables marketing while keeping e.g. delivery notifications active, which means blocking everything is sometimes not an option), but at the same time, there are some websites where I'd really like getting notifications (and notifications are in fact the only reason I have their app installed!).

thewebcount• 3 years ago

The difference is that Apple has rules about what can going into App notifications, and if developers don't follow the rules they can kick the app out of the App Store. (Not saying they couldn't be better about this, but it's at least an option even if it's not perfect.) But they'll have no control over what notifications from web pages you've put on your home screen show. It will make notifications a worse experience for users all around.

least3• 3 years ago

I completely agree about notification spam being an issue, but why should native apps get a head start over PWAs here?

They shouldn't, which is why I think this is an overall positive change. It's mostly that when you add ways people can receive notifications, it can only increase the amount of notifications you can get, not reduce it, and notifications for most applications have at best dubious utility for the end user.

Web apps are also not beholden to the app store rules, so I think they at least have slightly higher chance of being abused, not that the app store prevents companies like Uber from spamming you with advertisements and bundling them with delivery notifications, like you mentioned.

rahoulb2• 3 years ago

However with a native app, you've chosen to install it, so you're at least partially interested in its notifications. With a website, you may just have browsed to it and have no intention of ever returning again. So the point of having to "install" the PWA to your home-screen mimics that first stage of intention.

The key issue (as many others have noted) is that the "installation" step is still somewhat arcane.

neither_color• 3 years ago

I'm like you I disable almost all notifications by default. For some pesky apps that try to be cheeky about it, like Uber Eats requiring notifications but then not letting you opt out of promotional ones, I turn them on only for the duration of my order.

osrec• 3 years ago

I can't believe they've finally added this. Been waiting at least 8 years.

jonny_eh3• 3 years ago

Some of us have been waiting 15 years.

computing• 3 years ago

some of us have been waiting for 29 years.

banashark• 3 years ago

This is great for the progress of PWAs

diebeforei4852• 3 years ago

What are the anti-abuse features built into this? Can Apple disable push notifications if the website gets hacked and is actively stealing people's info?

Etheryte2• 3 years ago

On iOS you get asked the first time an app tries to show you notifications and it's very easy to disable them after the fact too. Since PWAs are just apps you add to your homescreen nothing will change in this regard.

As an aside, how would a notification steal your info?

arepublicadoceu• 3 years ago

As an aside, how would a notification steal your info?

How about:

“Hey dear user you won {amount} of money please click here and fill this totally safe form”

This was me thinking for a solid 3 seconds, imagine if someone put some effort into the message.

cuttysnark• 3 years ago

Can Apple disable push notifications if the website [] and is actively []

No, and previously you could add a hacked website to your homescreen and Apple couldn't stop you from doing so. Not speaking for the other features, but the webpush api provides no mechanism to steal info as much as it provides a way to alert a user who previously installed the app and allowed notifications that the app is sending them a notification.

Now, if after the user installing and allowing, the site gets "hacked", the hacked site operator could send push notifications that invite the user to interact with the compromised web site/app. Apple has no recourse; the pressure would have to be applied to the hosting service to shut down the site. That's a tall order for your average web user.

LeanderK4• 3 years ago

I have been waiting for this for years! Now the only thing that's really missing is an install prompt. I wonder how long we have to wait, the install prompt is crucial, but I view Apples reluctance to implement the install prompt as politically driven. They want to favour their AppStore and make installing Web Apps unnecessarily hard.

Edit: It's been three years since I have last dabbled with PWAs. What has been the recent experience?

cientifico• 3 years ago

My experience is similar.

While Apple don't invest in PWA, PWA is doomed from a commercial point of view.

It is a really sad situation because the user experience of PWA is match better than installing apps from the store (with higher install rate than native).

Twitter is (or was) one of those examples. It took months until I realize that I was using a PWA than a native app.

kelthuzad• 3 years ago

Why do you think PWAs are doomed? Is it because you suspect that Apple will continue to sabotage them regardless of likely fines by regulators?

threeseed6• 3 years ago

Twitter is (or was) one of those examples. It took months until I realize that I was using a PWA than a native app.

Something is very wrong if you can't tell the difference. The difference is night and day on iOS.

PWA app has significantly lower responsiveness, constant mis-touches on buttons, loading screens for every click etc.

yamtaddle16• 3 years ago

the user experience of PWA is match better than installing apps from the store (with higher install rate than native).

People have A/B tested "click this app store link to install" and "click this to install this webpage as a web-app" and found the latter gets more installs?

dmitriid3• 3 years ago

Twitter is (or was) one of those examples. It took months until I realize that I was using a PWA than a native app.

I can't believe people keep saying this with a straight face. It's as if they've never seen an proper native app before (any of the third-party clients to Twitter come to mind before they were axed). Or haven't seen actual good fast implementations like the one Twitter actually bought and surprisingly still kinda maintains (see on desktop, https://tweetdeck.twitter.com/)

SllX5• 3 years ago

One other thing is necessary too, but this is iOS specific: I need a way to dump these to my App Library off my Home Screen. I searched out a few PWAs to see what the current experience is like, and even if I wanted to keep any of these around, I don’t want them on my Home Screen per se.

jaywalk2• 3 years ago

You can put them on a hidden home screen. It's a pain, but it's the only way to keep the app but not have it on your home screen.

lxgr6• 3 years ago

I just have all PWAs (that I don't need shortcuts for) in a folder towards the end of my last home screen page.

I's long overdue to have them treated as first-class apps, though (i.e. allowing having them only in the app library and treating the home screen as an optional short cut only)!

hn_throwaway_993• 3 years ago

What do you mean by the "install prompt"? (Sorry if this obvious, not an iOS user).

I thought it was fairly straightforward to add an "add to home screen" overlay to a webpage with javascript.

coder5439• 3 years ago

I thought it was fairly straightforward to add an "add to home screen" overlay to a webpage with javascript.

On Android, yes. On iOS, users have to click “share” and “add to Home Screen”, which practically nobody knows how to do, and it presents the user with a rather confusing prompt for them to choose the name of the PWA they’re about to install. The website could tell you to do that, of course, but then it only works in safari at the moment, and it is very clunky.

iOS allows websites to show a banner that will help them install the equivalent app from the App Store, but there is no similar functionality for PWAs.

Some people speculate that Apple relies on the PWA install process being confusing to help push developers into the App Store.

yamtaddle16• 3 years ago

Ugh, no. It's bad enough they can pop "THIS SITE IS BETTER IN THE APP" shit. The last thing we need are more ways for a site to shove things in front of me to make my day worse.

Keep it user-driven.

lxgr6• 3 years ago

I mean, given that we already have "GO GET OUR APP NOW OR ELSE" prompts, would PWA prompts make things any worse?

And very often I'd actually prefer a PWA, e.g. if I know that I'll be using a given site/service exactly once. Common example: A flight or train ride with a carrier I know I won't be using again anytime soon, but still would like to get notifications relevant to my trip.

saurik• 3 years ago

OK, then the mechanism that let's websites prompts to install apps should be removed so apps are on the same level as web apps. Otherwise, the situation is part of the anti-competitive lock-in. If that won't be removed--and we know it won't be--then this feature needs to be added and will not make the situation worse: it will just mean that there is a hope that some of these websites prompt you to install a website instead of an app. If you want to stop getting prompted to install anything at all, then you need to either remove support for push notifications from apps--which obviously will never happen--or add support for push notifications to random "uninstalled" websites. (And if you don't like being prompted to activate push notifications for things, there should be a global switch to disable that feature... as they say: this isn't rocket science.)

encryptluks2• 3 years ago

The install option on Chrome isn't in your face nor interrupting. It is a small icon and text on the URL bar.

presentation• 3 years ago

How about a system preference of “don’t show me these”?

dbbk• 3 years ago

It should probably be surfaced when you go to bookmark a site.

Turing_Machine2• 3 years ago

I view Apples reluctance to implement the install prompt as politically driven

I agree. See also: the way you can't directly open an HTML document from Files (you essentially get a blank screen, even if all the JS and CSS is located in the HTML file).

WorldMaker3• 3 years ago

Rather than a separate PWA "Add to Home" prompt, it would be nice if they added simple PWA support to the App Store directly. Microsoft's app store supports developers just dropping a URL to their web app manifest as pretty much the only thing needed to add a listing to the Store. (It also supports providing previous package IDs to migrate older apps to PWAs. Microsoft's Bing crawler will also sometimes pick up web app manifests and add basic listings in the app store when the manifest has enough information to do so.) Android app stores are in various stages of supporting similar things.

It would great if Apple similarly supported PWAs as first-class citizens in the App Store. It would also make a lot of sense: it would still favor the App Store as the "primary" or "best" way to install apps, and users would keep a lot of familiar experiences in choosing to "install" apps (much more familiar than Share > Add to Home, as other comments around here point out). Apple can even still try to curate the listings to keep them looking nice and staying informative (and whatever quality insurance checks they like to run). The users don't need to know or care that an "app" in the App Store is a PWA or not. Same with all the normal "Install Our App" and "Find this App in the App Store" links and prompts and modals (and "paywalls") those can/should all be the same experience whether the app itself is powered by Swift (or anything else) or powered by a PWA. Users that install PWAs via an App Store think they are still sommewhat locked into that app store's moat because they still think of that app as originating from that App Store. It's something of a win-win for Apple, I feel.

Not as a replacement for a general option like Share > Add to Home, because there will always be PWAs with no interest in submitting things to App Stores (and users will always want nice home screen bookmarks even for non-PWAs), but as a way to unify the install experiences for PWAs that do care about install metrics and app-like branding the best thing Apple could do (both for users and themselves) would likely be to allow developers to just submit their web app manifest URLs as the only "application code" in an App Store listing.

xfalcox2• 3 years ago

It's been great. Web Share, Web Share Target, Notification Inline replies, Contacts API, are useful in the app I work on.

nevernude• 3 years ago

Unfortunately a number of those APIs are still not available on iOS and have seen little to no traction[1]

1. https://bugs.webkit.org/show_bug.cgi?id=194593

tuxone2• 3 years ago

I wonder when you people will stop thinking with your marketing/growhacking/SEO/spam brain and start being on the user side. If you want low value visitors just go and buy ad clicks, thanks!

izelnakri• 3 years ago

I strongly disagree that what he is asking is user hostile, just like asking microphone or camera permissions aren't user hostile. You also didn't need to lecture anyone like that on hacker news, thanks!

LeanderK4• 3 years ago

lol, this was a project I did for a friendly event free of charge. I choose PWA because it's only useful for three days and nobody is going to install an app for this, you want it working right away. I was getting good results but the experience was just way smoother on android. A good prompt/banner/whatever that the app is installable felt essential when viewing the users behaviour because it's "drive-by" usage.

holoduke• 3 years ago

Actually not bad. We are converting all our native apps to either webapps (still available in the store) and as a PWA. Performance was always an issue, but nowadays we are convenient that performance is good enough. Developping in web is soo much easier, cheaper and much much faster.

barnabee2• 3 years ago

There should absolutely never be a prompt to install PWAs.

If the site wants to tell me I can install the PWA by adding it to my home screen and remind me how to do so, it's welcome to, but no unwanted popups/prompts.

latexr3• 3 years ago

I view Apples reluctance to implement the install prompt as politically driven. They want to favour their AppStore and make installing Web Apps unnecessarily hard.

I keep seeing this touted as fact, yet no one has ever provided any evidence. I have the feeling everyone who says it is just mad at the feature not being there and they ascribe to Apple the most damming justification they can come up with.

Apple is greedy, especially under Tim Cook, but that doesn’t mean every decision is primarily motivated by it. Sometimes the people at Apple truly believe something is the right choice for the majority of users. Maybe you’ve been lucky to have never seen a relative’s device full of spammy web push notifications they don’t know how to turn off, but that is not rare. You can find reports of it among the other comments.

cronix• 3 years ago

I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it. For years they've really been holding up progress with PWA. I think a majority of the apps we see are really just glorified wrappers around websites anyway, or not needing more resources/tech than a website would, except bloated up to 100megs for each app because we can't just use the web browser already installed and all of the time and money wasted getting it into the app store when it should be just freely accessible via the web.

sublinear• 3 years ago

should be just freely accessible via the web

Yes this is a significant hammer blow against native apps on iOS, but I don't think this would reduce cost for the consumer. I might be misunderstanding what you mean by "freely accessible" though. Definitely is more convenient for the same web app to be available everywhere.

nine_k2• 3 years ago

Freely accessible as in not vetted by Apple. No approval process, no need to pay $100/year, no need to buy a Mac. (Also, gone would be the 30% Apple tax on "in-app" payments.)

dmitriid3• 3 years ago

Yes this is a significant hammer blow against native apps on iOS

Funny how this significant blow never happened on the world's most dominant OS where all the restrictions that HN loves to whine about don't exist.

cma• 3 years ago

Meta's PWA announcement was pretty shocking: they are going to take a 30% cut from PWAs and require they go through their Quest store.

WastingMyTime892• 3 years ago

I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it.

The EU is forcing them to allow side loading so they are racing against the clock to try to bring WebKit to a point where everyone is not just going to switch to Chrome overnight when that happens.

fabrice_d• 3 years ago

In general yes, but web push is kind of the exception there because this API needs OS level support to wake up apps. Switching to a blink based browser would not help with that.

robertoandred2• 3 years ago

99.9% of people would not switch to Chrome overnight. They don’t know or care what a rendering engine is.

Eduard2• 3 years ago

Are you talking about Apples walled garden app store or are you talking about the Aplpe-enforced webkit browser monopoly in iOS?

Or are they Effectively dependant on each other?

jonny_eh3• 3 years ago

because we can't just use the web browser already installed

True on Mac, not on iOS. Apple doesn't let you ship custom web renderers. You need to use the system's built-in one. This applies to browsers such as Chrome and Firefox too!

throw03172019• 3 years ago

I believe they are goi g to allow custom engines going forward.

Source: https://www.macrumors.com/2023/02/07/mozilla-developing-non-...

afavour7• 3 years ago

There’s a huge caveat here: it only works for webapps you’ve installed to your Home Screen, which is a Byzantine process few work out organically.

It’s progress, I’m happy to see it, but Apple are still behind the curve here. It should be much, much simpler to install an app to the Home Screen when huge features like this are locked behind the gate.

buildbot• 3 years ago

Clicking the share icon and then add to home screen is byzantine?

boucher• 3 years ago

Byzantine is a bit much, but it's not particularly discoverable if you don't already know what you're looking for.

lxgr6• 3 years ago

It's completely non-discoverable!

The only way to even find out if a website actually offers a PWA (assuming you know what that is, which is probably not true for >90% of users at this point) is to add it to your homescreen and then see if you get essentially just a bookmark, or an actual PWA.

afavour7• 3 years ago

Ask any average user how they’d go about installing a web site to their Home Screen and they’ll just stare at you blankly.

I guess Byzantine is the wrong word. It’s not discoverable because no one knows what they’re even looking for.

sedatk3• 3 years ago

You lost the user at "Clicking the share icon".

happytoexplain• 3 years ago

Absolutely, yes - and this is a great example of how out of touch most software-experienced people are with how stupendously confusing/non-discoverable most UI is for most users.

pacomerh• 3 years ago

It's not intuitive and most users won't find it. I honestly didn't think Apple wanted the web to succeed, so I was surprised when Jen Simmons joined but it seems like she's moving the needle!.

olliej• 3 years ago

You mean random websites can't spam you with notification requests unless you've taken a step to indicate that it's a special app?

I'm also curious how badging would work for non-home screen apps?

redbar0n5• 3 years ago

This is a really good little animation to teach users how to add it to the home screen: https://streakscore.com/help

alberth• 3 years ago

"A web app that has been added to the Home Screen can request..."

Home Screen dependent.

Just for clarity, sounds like this functionality only exists for web apps added to your Home Screen.

(Which I think is fair, but just pointing this out since I don't know how common it is for people to add web apps to their Home Screen)

bnt• 3 years ago

I strongly dislike this. My grandparents are on Android and they are driven mad by every site pushing them notifications, 24/7. We're talking about non-tech people, 70+ years old. I ended up turning off notifications for them altogether because I couldn't find a fix. On iOS this is easy, Safari won't have access to notifications on my phone.

lelandfe• 3 years ago

This is just for "Home Screen web apps", aka PWAs. No data for this one, but I'm comfortable saying grandparents largely do not install PWAs.

jefftk• 3 years ago

This is only for websites you intentionally add to your homescreen, though?

smashed• 3 years ago

You have to add the web app to the home screen, then the app needs to ask permission on a click event, the user needs to grant the permission and then focus mode, etc can still filter them out.

In many cases, you have a perfectly functional web app and the only feature you would gain from publishing a native mobile app would be push notifications. Apple used to gate this feature behind its app store/developer program. Now you have an alternative, and I think it was long overdue.

tech234a2• 3 years ago

It's great to see additional capabilities being added to Safari on iOS; the bottom of the article also mentions additions of the Screen Lock, Screen Orientation, User Activation and Web Codecs APIs.

The idea of limiting some APIs to apps added to the Home Screen makes sense; I hope in the future web apps can use other features such as the Vibration, Bluetooth, Screen Capture, NFC, and Share Target APIs.

sccxy• 3 years ago

Web Push is meh for me, but Screen Wake Lock and Screen Orientation APIs are super!

I work with custom web map apps, so it is great that iOS is moving little bit closer to Android.

PWA install prompt would be great like in Android. Share - Add to HomeScreen is too difficult for many users.

lxgr6• 3 years ago

This is much appreciated, but it also comes at an interesting time, given that true alternative browsers on iOS are probably only a few months away at this point.

That said, I wonder if alternative browsers will actually get access to the "add to homescreen" API?

dimal• 3 years ago

In iOS and iPadOS 16.4 beta 1, third-party browsers can now offer their users the ability to add websites and web apps to the Home Screen from the Share menu.

If it's available for webkit-based third-party browsers now, it seems like it would probably be available for non-webkit browsers as well. Maybe not, but at least the door is open for it. It would be hard to justify the limitation.

SllX5• 3 years ago

At this moment of time, there aren’t any non-WebKit browsers available in the App Store, so “third-party browsers” in this context means “WebKit browsers”.

metayrnc• 3 years ago

I think this is a good step. However, there is still many things that Apple can implement easily to show that they care about Web Apps. One simple example is that you cannot lock the rotation of a Web App like a regular app. There is plenty of stuff like this that would make Web Apps feel native. I hope they improve upon these things.

Sheepsteak• 3 years ago

I think they've added this too. At the bottom it says they're adding the ScreenOrientation API and it seems to be able to do this.

https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrien...

jacobp100• 3 years ago

It's good to see this happen. It'll improve the perception of Safari for developers.

It always was always treated pretty unfairly. It's easier to parrot 'Safari is the new IE' rather than consider cross compatibility when you're writing websites.

MBCook8• 3 years ago

Sadly I don’t think it will change anything. It’s different from Chrome so it lacks the feature of the week and needs “special fixes” because it has a different rendering engine.

It seems to be doomed to persona-non-grata for a lot of developers. At least until the Chrome worship dies.

cal85• 3 years ago

Unless I’ve misunderstood, this a quite a big event in the history of the web platform. Apple’s quiet refusal to support this part of the PWA standard has for years been quietly maintaining a significant situation: that if you wanted to make a viable digital product that involved notifications, you basically had no choice but to make a dedicated iOS app, along with either a PWA or an Android app. If iOS Safari fully supports PWA notifications, with no funny business, that is no longer the case. Suddenly it is viable to make a single version of your app for every phone.

This also has big implications for the hegemony of the App Store and Apple’s control over the web platform. I don’t fully understand why they are finally giving up this power they have held onto for about 8 years, but I’m glad they are.

wsc981• 3 years ago

Isn’t there a push by some legislators in some countries for Apple to allow alternative app stores on iOS devices in the near future? That might have something to do with this perhaps ...

freedomben• 3 years ago

Exactly, I think that's what this is about. either no need to allow sideloading cause PWAs, or it's an olive branch to iterate closer to prevent the big hammer from dropping. Also of course possible that Apple just supports it, but given then long history of evidence against that I don't consider it likely.

threeseed6• 3 years ago

This also has big implications for the hegemony of the App Store and Apple’s control over the web platform

No it doesn't. It will make zero difference.

Because developers have been building web based mobile apps for nearly 15 years now. And they never took off not because it lacks push notifications or some other minor feature. It's because the end user experience is terrible.

And I've yet to see anything that addresses the difference is latency, responsiveness, feeling etc that you get between native and web apps.

joenathanone2• 3 years ago

I build a PWA currently in use by around 130 people, no one can tell its not native.

jstummbillig3• 3 years ago

And they never took off not because it lacks push notifications or some other minor feature.

Actually, that is precisely why they didn't take off: Without push notifications a lot of mobile applications are simply not feasible. If something is not feasible, most people will have no reason to invest in ux. It's self-fulfilling.

However, with push api, cache api, being installable (and maybe some additional apis that elude me right now), I don't see any specific thing that would not allow carefully crated web apps to have great ux on mobile.

trevcanhuman• 3 years ago

No it doesn't. It will make zero difference

I'm pretty sure it does, at least with purchases. PWAs won't need to pay for apple's app store 30% cut.

phreack• 3 years ago

I once made a chat app that had significant traction on Android, and many users wanted to try it on iPhone but there was no way to do so without web push, and it was fundamentally banned by the app store guidelines and without side load there were no alternatives. This is a game changer for those kinds of apps!

kristiandupont• 3 years ago

I don't know what the percentage of "native" apps that are really web views and/or javascript underneath, but am certain that it's a lot. In fact, I wouldn't be surprised if it's more than 50%.

elforce002• 3 years ago

This 100%. Amazon web app is awful. Same goes for any ecommerce pwa I've used on my phone.

redbar0n5• 3 years ago

Things have changed a lot in the last few years. This is a React Native vs. Ionic React+Capacitor responsiveness demo: https://twitter.com/magnemg/status/1404073426193690634?s=20

You can achieve 60 fps with webapps now: https://ionic.io/blog/ionic-vs-react-native-performance-comp...

With the Shared Element Transitions API you even get smooth page transitions (even for MPA's with full page reload): https://www.youtube.com/watch?v=6mv0_jsWhoE

scarface742• 3 years ago

It came out in the Epic Trial that 80% of all app store revenue comes from games and in app purchases.

The difference that web push notifications will make is infinitesimal.

tompetry• 3 years ago

With the (controversial) incentive for Apple to move away from PWA's and toward native apps, this has to be welcome news and useful for developers and consumers alike. Their fine balance between being anti-competitive and providing just enough tools to keep users from switching to Android continues.

Their previously leaked internal debates about openness and iMessage for Android in particular is fascinating. Would love to see it on this topic.

seanabrahams• 3 years ago

Dreams do come true (https://news.ycombinator.com/item?id=22687913). Even more:

You do not need to be a member of the Apple Developer Program to use it.

Wow.

Alifatisk2• 3 years ago

That is incredible. I guess PWA is getting closer to success.

msoad• 3 years ago

An important detail that you might miss without reading the article is that these capabilities are not available to any website a user visits. The user must add the website to the their Home Screen before the website can ask for notifications permissions.

As an iOS user I actually like this restriction. Can't imagine what the browsing experience would've looked like if any website could take their chance on sending me notifications

duxup2• 3 years ago

Yeah absolutely this has to be a limitation.

I do not want to have to go chasing “where did this annoying notification come from” game… ever.

wartijn_3• 3 years ago

Desktop browsers don't have this limitation and I never have to play that game. It's just a stetting where you can choose to allow websites to ask for notification permission, or block it from every website.

yamtaddle16• 3 years ago

Oh thank god. I was worried it'd let sites ask without the user first taking some action to permit it. Sites being able to pop "allow notifications?" without the user first indicating they might want that, on desktop, is a menace.

nvrspyx3• 3 years ago

Now if only they'd create a separate folder for web apps in the App Library to put them in instead of requiring that they be on the Home Screen.

alwillis• 3 years ago

Now if only they'd create a separate folder for web apps in the App Library to put them in instead of requiring that they be on the Home Screen.

Could be a feature of iOS 17, which will be available to developers at WWDC in June.

Someone3• 3 years ago

You can get close: put them in a folder on your Home Screen.

Disadvantages:

- cannot hide that folder in the App Library

- limited number of shortcuts per folder

thekingshorses• 3 years ago

And reinstall it like native apps on factory reset or transfer like native apps to a new device.

hbn• 3 years ago

Good. Web push is such a mess. The amount of people with Android phones like my grandma that accepted push notifications on some spam site, either by accident or because users are so conditioned to just click "ok" to make popups go away, it's absurd.

maicro3• 3 years ago

FYI, you can disable the ability for Chromium-based browsers to even ask the user if they want to allow notifications - on my Android phone in Chrome, it's under Settings, Site settings. There you can set "Notifications" to "Blocked" (and if you're paranoid like me, turn most others off as well).

solarkraft2• 3 years ago

The request mechanism is so broken. There shouldn't be a pop-up at all. The website should declare a notification source and you should be able to subscribe to it if you feel like it. Somewhere in the overflow menu. The website shouldn't even get the option to natively bother you about it.

makeitdouble3• 3 years ago

Can’t she revoke it from the notification screen when she sees a spammy one ?

Sure it’s still better to never subscribe to unwanted notifications, but removing them isn’t much of a hassle in the current system IMO

postalrat2• 3 years ago

Are all the notifications from native apps fine? Or just the web notifications that are bad?

spandrew• 3 years ago

Ya. It's safe to assume if someone is opting to add a website to their homescreen they are interested in it; notifications may make sense. Random websites asking me to enable desktop notifications are annoying. This prevents that for mobile.

mrtksn• 3 years ago

Very sensible limitation, otherwise we would just have another dialog to deny or accept on every website.

taude2• 3 years ago

I'd have expected no less, since Chrome already protects the notification noise by default, too. You have to opt in to notifications. Sounds like a slightly different implementation for iOS, which is interesting in that they're assuming any app you add to Home Screen means your opting in to the notifications, or is there another opt-in? I see myself putting a few apps on my home screen that I want to click on often, but maybe not wanting the notifications to go with it?

mbreese• 3 years ago

Chrome already protects the notification noise by default

Does it though? I still get asked to opt-in for notifications on websites regularly, including those I've already said no to. A simple opt-in question still makes me answer the question routinely (with the default "Sites can ask to send notifications" setting).

This puts a much higher bar on the notification opt-in game.

barkerja• 3 years ago

A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction -- such as tapping on a ‘subscribe’ button provided by the web app. iOS or iPadOS will prompt the user to give the web app permission to send notifications. The user can then manage those permissions per web app in Notifications Settings -- just like any other app on iPhone and iPad.

bakje• 3 years ago

I believe adding a site to your home screen isn't opting in to notifications, but opting in to allowing the site to request notifications, which would then require another opt-in.

pier25• 3 years ago

It's a good restriction although I wish Apple helped a bit with the installation of web apps to the home screen.

Not install prompt banners like in Android* but right now you have to use the Share screen. It almost feels like Apple is hiding that functionality so that users don't find it. Installing and sharing are two very different actions.

* I'm an android user and I agree these are bad.

throwanem• 3 years ago

"Share sheet" is a bit historical in my opinion, and has been for some time. In practice it serves as more of an OS-level context menu that happens to put the "send to frequent contacts" and "open in another app" options first.

In theory Safari's tab context menu would be a better fit, but given it iconifies as a "change text size" tool, I don't know if that would really address your concern at all.

Gigachad2• 3 years ago

For people who haven't used iOS, the Share screen is the ios junk draw where every option they couldn't find a better place to put something goes. Things like Find on page are located there too.

donbrae3• 3 years ago

I’ve long been hoping for something like the Smart App Banners[0] that native app developers can use to link to their app in the App Store.

It’s relatively unobtrusive and easy for users to dismiss.

[0] https://developer.apple.com/documentation/webkit/promoting_a...

cyanydeez• 3 years ago

The web has a standard we push API.

babypuncher2• 3 years ago

I agree. None of this stuff should even be requested before the user makes it clear they are actually interested.

I like that I didn't have to permanently disable push notifications in Safari to stop those awful popups asking if I wanted them. Apple knows that people will say "no" 99.9% of the time. It makes more sense to make the user jump through hoops the one time they actually want it than to incessantly nag them every single time they make the mistake of visiting a new web page.

camhart• 3 years ago

This seems very unintuitive though. Why not just add a button somewhere that says "enable notifications"? Apple loves these super unintuitive approaches. Blows my mind that anyone actually believes the marketing that they're "easier to use" than any other platform.

fiddlerwoaroof3• 3 years ago

I think that’s this is because the “add to Home Screen” workflow is how you install PWAs on iOS and they want to restrict these APIs to PWAs.

PossiblyKyle• 3 years ago

My mother has an Android phone, and she’s not really tech savvy. Her notifications are absolutely bombarded with garbage from various websites, and her lock screen displays ads. I’m moving her to iOS, as I’m quite sick of constantly being the IT guy.

philliphaydon• 3 years ago

Oh I can relate to this. Bought my mum an android phone when my daughter was born so I could share photos and do video calls.

It was such a hassle doing support over the phone (She lives in NZ and I was in Singapore, and now Taiwan)

Bought her an iPhone 12. Apple support helped her set it up over the phone. 2 years and I haven’t played IT guy once!

achairapart• 3 years ago

I guess websites will start asking users to add them "to the home screen", so they can later start asking permissions for push notifications...

But this is a different kind of problem and no reason to slow down the Push API standard.

I'm very happy that they also finally implemented things like Screen Wake Lock API so developers will no longer be forced to do silly things like play a fake video loop in the background to keep the app in focus.

Looks like Apple is finally going to give PWAs some love and it's a good thing overall.

bioemerl• 3 years ago

It's actually pretty difficult to do something like that since an install is done through the OS and the app can't set off the process. I think it's too clumsy for most sites to try it.

Chrome does let you do it though.

arendtio• 3 years ago

Does this affect Firefox on iOS too? Just yesterday I tried to add a website to my home screen but couldn't find the button.

gdeglin• 3 years ago

This is a tremendous announcement. Web Push is such a superior channel to SMS and Email for many websites" There's a standard opt-in and opt-out process, it's real-time, and it's free. Yet the adoption has been severely reduced by the lack of iOS support.

The homescreen requirement is a small hurdle in the grand scheme of things. Now websites can finally implement Web Push once, and know that it will work for all of their users.

This is especially useful for media sites and others that have historically struggled to get people to go through the whole app store to app install process. It will level the playing field and create much better user experiences.

EMIRELADERO• 3 years ago

Time to repost my comment from a past thread:

I don't know anything about WebKit development processes or community management, so please forgive me if I say something wrong. Isn't it interesting how the engine has been implementing new features and generally running on a lot of steam coincidentally since the EU's Digital Markets Act (which will force other web engines on iOS) went into effect?

Or maybe the dev process and community interactions has always been like this, in which case disregard what I just said and feel free to correct me.

pvg• 3 years ago

It’s almost certainly not time for that:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

djbusby• 3 years ago

Are these WebKit improvement driven by the EU regs? Isn't that why iOS will soon allow an alternate rendering engine? So, now WebKit finally has to keep up?

awinter-py3• 3 years ago

I recently imp'd web push for an internal admin tool, tested on android

AFAICT it only works if chrome has been started recently, and you have to turn off background throttling for chrome maybe. (guessing this is highly vendor, version, and device specific though). But it was fine for something I check daily anyway

Python library support for sending this is present but shaky -- guessing apple's endorsement will improve the ecosystem for this

Not sure about consumer space, but for communicating with technical users who know you well, this is so much of an easier rollout process than an app -- literally 'hours vs months' comparison

jeroenhd5• 3 years ago

AFAIK notifications should come in as long as Chrome's daemon is running. This should run on boot, unless Chrome has been manually force killed, or if Chrome has crashed.

It's possible extremely aggressive battery savers or extreme power saving modes will kill these services as well and require Chrome to start, but you shouldn't need to launch Chrome manually in most cases (or Firefox, or any other browser).

There's simply no way to fix this restriction, not on the web nor on native apps.

awinter-py3• 3 years ago

hmmmmm

I'm on up to date droid OS with an older pixel device

I wonder if 'aggressive throttling' is the norm on older devices? Also, I remember reading about a non-google android handset vendor who shipped custom throttling logic (but don't quote me on this)

it's been a while since I tested, and because I don't know how to inspect the daemon state directly, I'm not sure of any of this, but iirc:

1. I had to switch chrome to 'unrestricted' from default 'optimized' in the OS settings 'app battery usage' screen, or else notifications would fail starting a few hours after the last time chrome was foregrounded

2. chrome had to be started once after boot (less sure of this)

it's certainly possible something else in my stack is causing problems, or I have misconfigured retry on the send-side

dariosalvi78• 3 years ago

great, now give me web bluetooth and I'll never develop an app ever again...

jeroenhd5• 3 years ago

Native Chrome is coming to iOS. Soon enough you'll be able to show users screens like "your browser is not supported, upgrade to iOS 16 and download Chrome" if you want to use Chrome exclusive features like those.

donbrae3• 3 years ago

Even if/when we get the Blink rendering engine in iOS Chrome, I think Apple will still prohibit access to certain features like Bluetooth if they consider it a security or privacy threat. Are Web Bluetooth, Web USB etc. even considered part of Blink, or are they part of Chromium?

JimDabell3• 3 years ago

Web Bluetooth is not a web standard. It’s something Google implemented by themselves that no other rendering engine wants to adopt. Both Firefox and Apple have explicitly rejected it.

stevenkkim• 3 years ago

Wow, I've been waiting for this for years and honestly thought it would never happen.

Does anyone have any sense of how long it might take for this get out of beta and widely supported by iOS/iPadOS devices?

MBCook8• 3 years ago

Compared to other OSes people update iPhones really fast. Apple really encourages updates (new emojis!), including automatically updating things unless you stop it.

Given this is public beta one we may see the release near end of March (total guess on my part). Point releases don’t tend to have too many betas. And Apple ID itching yo get the HomeKit new architecture bug fixed soon and that’s in 16.4.

zxcvbn4038• 3 years ago

I think this is a good development. I'd rather my "app" be chunk of wasm running in a browser window then have to deal with all the drama that comes with dealing with the various app stores. Its not a universal solution but it would work for a lot of apps. Most of the non-game apps seem to be just a web widget anyway.

fayazara• 3 years ago

Great addition.. I hope they soon add the install prompt and remove the stupid border dragging/pulling from safari.

slugiscool99• 3 years ago

Kudos to Apple for doing this. It's honestly very cool of them

CBarkleyU• 3 years ago

A bit off topic, but worth a shot: I'm working on a rather simple web-based game and I'm struggling with how to test it for iOS/Safari/Webkit without having to go out and buy an Apple device?

aeharding2• 3 years ago

Browserstack. Free for FOSS

Sammi• 3 years ago

https://www.browserstack.com/

Not afiliated.

jeroenhd5• 3 years ago

You can rent virtual/remote iOS devices. Those are the only realistic alternative I know of and you'll probably need to expose your dev server to the internet somehow for it to work.

There are also open source webkit builds like GNOME Web (though they're quite different from Safari in many ways).

MatthiasPortzel• 3 years ago

Linux builds of WebKit provided from https://WebKit.org/downloads.

aeharding2• 3 years ago

Wow, it's actually happening! Providing the notifications API behind "add to home screen" is exactly what I've been hoping for.

https://news.ycombinator.com/item?id=33816700

Alifatisk2• 3 years ago

This is shocking

supermatt• 3 years ago

Since the first iPhone, users could add any website to their Home Screen

And ever since Apple have actively tried to destroy the advancement of local web apps.

Now the writing is on the wall with regulation of their App Store they are finally pretending to embrace PWAs.

fleddr• 3 years ago

No work webkit does on PWA-like features matter for as long as the install journey is as intentionally user-hostile and non-discoverable as it currently is.

For the record, on Android it's also shitty, but not this shitty.

gempir• 3 years ago

Will they ever allow chrome or other browsers to add PWA Apps to your Homescreen? That's what's missing for me.

teichmann• 3 years ago

It’s mentioned in the article, see “Third-party browser support for Add to Home Screen”.

hajile2• 3 years ago

Added support for WASM SIMD.

This is huge for the progress of WASM

Added support for growable SharedArrayBuffer.

Not a headliner feature, but a pretty important one for JS/WASM interactions.

Added support for AVIF on macOS Monterey and macOS Big Sur.
Added support for the AV1 codec in the MediaCapabilities API.
Added WebRTC support for hardware AV1 decoding on supported device configurations.

Could this be the first indication of Apple warming to AV1?

Added support for the Notification API in dedicated workers.
Added support for Service Workers and Shared Workers to the Permissions API.
Added support for the termination of nested workers.

Nice to see web workers finally getting some love

Added support for CSS Typed OM.

A great feature and should help with performance from not having to do constant number->string->number

BluSyn• 3 years ago

Added WebRTC support for hardware AV1 decoding on supported device configurations.

Currently no Apple device has hardware AV1 decoding, so why support it in Safari iOS Beta? Perhaps next CPUs (A17 and M3) will have dedicated AV1-decoding hardware? Either way I think this is a hint it may be supported soon.

Great news!

MBCook8• 3 years ago

They may still be able to offer optimized decoding with hardware support on older devices. Not a full hardware path but a very well optimized CPU + hardware combo.

brrrrrm• 3 years ago

huge for the progress of WASM

HUGE! 4x speedup for anything parallelizable. This should bring around ~45GFlops out of the box in the iPhone browser, which isn't much but easily enough for basic neural networks (think object tracking, background segmentation, face feature tracking). For comparison, WebGPU would get that to ~1000GFlops

hajile2• 3 years ago

This is huge for CPU workloads that need intermittent parallel processing.

A great example would be JSON parsing in WASM apps where SIMD algorithms result in massive speedups.

Another example would be a WASM software decoder could allow AV1 playback content on iOS browsers.

latexr3• 3 years ago

Could this be the first indication of Apple warming to AV1?

That was half a decade ago, when they joined the Alliance for Open Media: https://9to5mac.com/2018/01/04/apple-alliance-for-open-media...

hollowturtle• 3 years ago

Finally! Can’t be more excited if not that it’s super hard for the common user to add web apps to their homescreen. I’m against an install prompt api, the web is already a shit show of banners, like other commenters pointed out. But something like a little badge on the address bar that once tapped tells you the web app is installable would be great imo

danShumway15• 3 years ago

Oh hey, bullying companies with threats of antitrust works. We should do that more often.

----

This is a really big deal, but it's also a little bittersweet, because Push Notifications very heavily motivate developers to introduce serverside components to apps that don't need them. Web Push is a standard where I can really see Google's influence, and I think it influenced the standard for the worse. It's a standard built around the way that Google and large companies build products, it's not built around indie development or hobby projects.

You can send a notification to whatever server is registered and it gets delivered to the phone, great. In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.

And yes, sometimes you do need a serverside connection for things like message notifications, but there are a lot of uses for notifications where you know upfront what the notification needs to say and when it needs to be shown -- and that's not supported. In my opinion because Google doesn't really think about that kind of architecture and the idea that you wouldn't contact a server alongside every user action is foreign to them.

There was effort for a while to get offline alarms, scheduled notifications, even scheduled actions working through web workers, but as far as I know that stuff has all died off. It stinks, because I regularly run into scenarios where I could probably flat-out replace an app on my phone with a website, and I can't even on Android, because I'm unwilling to set up an account system and start tracking a bunch of data. I'm happy we have something, but I'm still remembering the parallel world we lost, where it would have been possible to have a much broader push towards completely offline PWAs that never transmitted user data anywhere. The idea of being able to replace native apps with a static Netlify page is very appealing to me.

And maybe that'll change? But I'm not holding my breath; it seems like a lot of companies have decided that push notifications are good enough and that they were going to require user accounts anyway.

miohtama• 3 years ago

I was curious about this and looks like you can do notifications with Web Workers, based on this Mozilla post

https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

danShumway15• 3 years ago

Unfortunately, not schedulable as far as I know, the notification needs to be sent while the web worker is running. Again, I'd very much love be wrong about that, but I don't think there is any way for, just as an example, a habit tracking PWA to say "ask the user at 10:00AM every day if they've gone for a morning bike ride."

But you can get that behavior... if you set a web server and force the user to make an account and then log all of their habits in your server and then send out the notification yourself. Because... it's unfair for me to blame Google in this instance, I don't know it's their fault, but I do blame Google and I suspect it's their fault. I could be wrong though.

xfalcox2• 3 years ago

In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE* tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.

Looks like this effort died because of Android: https://bugs.chromium.org/p/chromium/issues/detail?id=891339

danShumway15• 3 years ago

Yeah, that was my impression as well. Every once and a while I check back to see if it's been picked up.

I really think Google made the Web Push standard worse, in multiple ways.

twism• 3 years ago

Google Firestore?

danShumway15• 3 years ago

Am I missing something? Firestore is an online database that requires setting up a Google account. It's sort of like responding to "I wish I didn't need to include a serverside component" with "Linode".

Maxburn• 3 years ago

Going to be great for web based podcast apps that do live broadcasts like Curiocaster; https://curiocaster.com

abxytg• 3 years ago

there is no good reason to have notifications on the web. its just for ads.

mvac• 3 years ago

Web Push is probably the worst feature ever introduced to the web. I see way too many spammy notififications on PC's of my non-technical friends and parents. Glad that Apple has decided to only allow Web Push for websites added to the home screen.

postalrat2• 3 years ago

Web push or the notifications API? They both do about the same thing but web push can happen even if your browsers are closed and the phone is locked.

LeanderK4• 3 years ago

I don't get why apple does not take a similiar path on mac. Some websites are really apps for me (stuff like overleaf). I would gladly add them as apps and use this to unlock all those advanced functionality. But so far, at least on safari for mac, all those web-push websites are mostly spam. I only have a few where it is useful but I use them, again, like normal apps, and would be fine of adding them to my library.

Nobody uses the mac app-store anyway, so why bother? Why not do it?

smoldesu• 3 years ago

Sounds like this is the motivation Apple needs to bring their notification-handling into the next century. I'd love for Apple to give me a way to disable "Try the New Safari!" notifications without opening my terminal.

somethoughts• 3 years ago

Great - just what I need for my productivity in 2023 - a Hackernews PWA icon on my iPhone's home screen with notifications!

MBCook8• 3 years ago

Web push, badging, saving to the home screen from other browsers, and lots more.

I can’t wait to hear 6 months from now how the goalposts have moved again and some other feature no one ever complained about is now what Apple is using to destroy PWAs that would be ultra-popular if Apple would just add support.

It happens every time.

quitit• 3 years ago

Something which developers have widely refused to embrace despite being pushed by Steve Jobs himself during the iPhone keynote. Yet somehow it's always Apple holding it back with their magical minority market share.

MBCook8• 3 years ago

There have certainly been functions that were necessary for some kinds of apps, but there are possibilities for kinds of PWAs that would have worked for years on iOS (and Android/desktop) but they barely exist if at all.

Unless some (unknown to me and possibly everyone) change happens and PWAs explode in popularity… there’s going to have to be a reckoning that end users just don’t seem to care/want them.

They can still be useful but the dream of abandoning the app stores (due to PWAs) just doesn’t feel realistic to me.

JimDabell3• 3 years ago

People have forgotten what a big deal that keynote was and what it meant for the mobile web. Go back and pay attention to the “desktop class web browser” stuff. Apple almost singlehandedly changed the mobile web from something almost nobody wanted, into something actually useful and mainstream. And Steve Jobs was there right from the start telling everybody if they wanted to build applications for the iPhone, they should be mobile web applications. It was everybody else demanding that iPhone applications be native, not web-based.

Before the iPhone was released, a typical mobile web experience was a separate site that barely worked and didn’t use any normal browser technologies. Along come Apple, who do a tonne of work to make their open-source WebKit work well on mobile, and virtually overnight all smartphones adopted WebKit to catch up with them.

Anybody who doesn’t think Apple has done more to advance the mobile web than practically any other organisation should be forced to build WAP/WML mobile sites until they repent.

They didn’t do it alone of course – WebKit was originally based upon KHTML, and I believe Nokia also had a WebKit-based mobile browser. But Apple put a tremendous amount of work into it and the dramatic shift from “the mobile web is shitty and worthless” to “the mobile web is actually useful” happened almost straight away as a direct result. Nobody wanted mobile websites / mobile web applications before the iPhone came out, then all of a sudden it was a normal requirement for a site to work well on mobile.

BeFlatXIII• 3 years ago

magical minority market share

This phrase is far more prescient than most people think. Yes, it's a numeric minority. However, they have a near-monopoly on _profitable_ users. 13% of the global market and >50% of the profits.

s-xyz• 3 years ago

Any good documentation on how to implement this? Eg a react site with Python backend?

exoque• 3 years ago

I recently switched to an iphone, the state of PWAs on iOS is just pathetic. While I don‘t care about web push, I‘m really glad they‘re trying to make some progress in this area.

varenc• 3 years ago

Digression: The language in this post seems to straddle the line between an official Apple Press release and an open source project update. While it mentions new features added to WebKit, it also references new iOS APIs. Additionally, the term "third-party browsers" is used, even though on iOS all those browsers are simply using WebKit. From the perspective of the WebKit project, I don't view these browsers as "third-party" as they too are utilizing WebKit. Not really complaining, just something I noticed.

laurencerowe• 3 years ago

It's a shame Safari on Mac still does not support web apps at all. I'd really like to have Gmail and a Twitter web apps that I can separately command-tab to.

spectre3d• 3 years ago

Does Fluid[1] work as a solution for you?

I’m on an older OS with an older version but I love it for creating single-site apps.

[1] https://fluidapp.com/

1-62• 3 years ago

Can't wait... Literally, I can't wait. 16.4 can't come quickly enough. I just installed 16.3.1 yesterday.

IceHegel• 3 years ago

This starts very defensively, pretty clearly hitting back at the idea that iOS has been intentionally holding back the web.

wackget• 3 years ago

Sorry but this is basically worthless until there's a MUCH easier and more visible way to add websites to your home screen.

In a perfect world you could submit your PWA-based site to the App Store where it would appear alongside native apps and be discoverable in search results etc.

But that'll never happen because Apple has way too much to lose from allowing developers to create genuinely cross-platform solutions. They need developers to be absolutely married to their ecosystem so that the users will be too.

leadingthenet• 3 years ago

Ah, I was waiting for the first goalpost shifting comment. I had to scroll uncharacteristically far for an Apple thread to find one, and you’re the lucky first!

chrismorgan• 3 years ago

Just be sure to allow URLs from *.push.apple.com if you are in control of your server push endpoints.

Wait, why would anyone be doing any sort of whitelisting? That seems a disastrously bad idea that utterly ruins interoperability. I could understand checking that the IP address the URL resolves to isn’t private, but what they’ve written suggests something much broader.

Am I missing something, or have they gone off the deep end, or are they reacting to implementers that have gone off the deep end?

JustSomeNobody• 3 years ago

Is there a complete example app that demonstrates all of this?

1-62• 3 years ago

Finally, my short llll.com domains and site can compete with Apps on the App Store again!

CodeIsTheEnd• 3 years ago

A personal gripe with progressive web apps: they cache the website!!

A lot of people have requested that I make a progressive web app for https://plaintextsports.com. I've looked into it, but it fundamentally doesn't work, because it caches the home page. My website doesn't load any data via JavaScript; it just relies on the HTML page updating every 30 seconds, so when the home page is cached, the website just stops working.

I don't want this service worker nonsense. In most cases offline access isn't useful; people want the live scores. (It'd be moderately useful for viewing schedules offline, but I think most people use it for live scores.) I just want the website to show up as its own app in the app switcher, and basically nothing else to change: I still want the swipe-to-go-back gesture to still work. I still want the address bar with the manual refresh button. But I can't do that.

It's frustrating that they've provided a way to make a certain style of websites into first-class apps, but it doesn't work for the most basic websites!!

Side note: this is partially a the-best-way-to-get-a-question-answered-on-the-internet-is-to-say-something-wrong post. If there's a way to make it a PWA and not have all the pages heavily cached, please let me know! I would love to be wrong on this. (Unfortunately my noprocast just triggered though, so I won't be able to edit this post or respond for the next three hours.)

m5r• 3 years ago

Your service worker dictates what the browser should cache. You could cache static assets only and let the browser hit the server for document requests. As for the refresh button, mobile users are now used to pull to refresh so you might not need an actual refresh button.

As an aside, I dig the design! It reminds of teletext haha

coder5439• 3 years ago

It has been awhile since I've personally tried creating a PWA, but I don't think iOS does any form of extra caching for PWAs. I think it is more likely that you copy/pasted an example service worker that was caching things you didn't expect it to cache. Some info about PWA caching here[0].

That page also talks about "What to Cache" here[1], and it specifically suggests that most apps will want to cache the main page's HTML.

Now that iOS will supports push notifications in PWAs, I definitely plan to try out the developer experience again soon.

I still want the address bar with the manual refresh button. But I can't do that.

Yeah, I mean... you're meant to provide an app-like experience if you're doing a PWA. You could certainly build your own stylized, floating bar that only shows up in PWA mode, or think about new ways to let users control the way the page updates. Alternatively, you could just automatically refresh the page with a setTimeout?

I'm not sure how much you want to invest in experimenting with the technical foundations of your app, but I wrote out a few ideas that occur to me:

- Your Cache-Control header is kind of weird. `max-age=15`. I would expect to at least see a `public` or `private` directive in there to specify how this data is supposed to be handled by intermediate proxies. Something like your website is a prime candidate for caching in a CDN layer, and I think you generally want to specify `public` for CDNs to do anything useful. Maybe they default to `public`? I've honestly never felt the need to try. Beyond the `public` / `private` discussion, `stale-if-error` could be useful so the CDN could serve the most recent info even if your application is having a brief outage. If you're not using a CDN... probably something worth checking into.

- As cool as just serving self-contained HTML document is, your page is still transferring 6 kilobytes each time it refreshes. If the goal is to lower that as much as possible, I would start by pointing out that you don't need to send your JavaScript snippet every single time the page loads. It looks to be several thousand bytes uncompressed, although I'm not sure exactly how much it is affecting your compressed payload size. You could separate that into an aggressively cached JavaScript file that is served separately from the HTML. (As usual, best practice is to have a file hash in the name of the javascript file, that way the cache time can be infinite. If the javascript needs to be updated, the hash would change, so the browser wouldn't have that cached, and would fetch the new file immediately, as soon as the refreshed HTML file requests it.)

- But then after that... the next logical step is to render the actual score interface client-side, since the score data is significantly smaller than the HTML needed to render the score data. This would also allow you to handle refreshing more elegantly from the client by just fetching the data route that returns a JSON blob, and re-rendering the HTML. At this point, the HTML representing the empty app shell could be cached too, but it would probably be best to limit the cache duration depending on your preferences. The right value for HTML caching would likely be somewhere between a few minutes and a few days. Now, opening the app would load the locally cached HTML and JavaScript, and then the JavaScript would just fetch the tiny blob containing only the scores and nothing else. Of course, you could cache this information locally so that when the PWA is opened, the user can always see the last information (and when it was fetched) even if they don't have an internet connection, while the PWA can continue trying to fetch the updated scores.

- Taking this to the extreme, the maximally efficient design for something like this would probably involve an SSE (server sent events) endpoint that the client would subscribe to. Whenever the scores actually do change, the server could push that straight down to the client. This would reduce the latency from your current 30 second target, and it would also use even less data since people aren't refreshing and receiving the same stale data multiple times. (I will note that a good implementation of this would still send a tiny ping from server to client every minute or two just to ensure the connection doesn't get silently dropped by any weirdly configured firewalls along the way.)

- If you were really going all-in on features, well... this whole HN discussion is highly focused on push notifications, so you could always let people subscribe to specific teams, and send them a push notification when scores change for those teams.

[0] https://web.dev/learn/pwa/caching/

[1] https://web.dev/learn/pwa/caching/#what-to-cache

gloosx• 3 years ago

Finally. This is the reason most ugly Flutter-style app-site chimeras existed. Now it's slightly better.

astlouis44• 3 years ago

Amazing, about time!

mertens• 3 years ago

Good to see Apple finally making some effort to support PWAs, but as a user it's still very cumbersome to actually add a Web App to the homescreen (compared to Android).

ursuscamp• 3 years ago

This is really great news for the Lightning network, if that is your thing. There is a Lightning wallet, called Mutiny Wallet (https://mutinywallet.com) which is an entirely web-based Lightning wallet/node (using WebAssembly, etc) under development. A Lightning wallet PWA is a great boost to censorship resistance because no one can be cut off from their money because of oppressive government or App Store policy.

One of the challenges of Lightning usability on mobile wallets is sending payments when there is no guarantee that the user's mobile wallet is getting the CPU time necessary to receive the payment without having the app directly open. Allowing push notification for PWA is a potential way to make sure that a user's wallet gets some CPU time for incoming payments!

redbar0n5• 3 years ago

For a lot of apps this would enable foregoing React Native entirely, since Push Notifications was the only must-have native feature for a lot of apps that could just as well be webapps.

Particularly excited to make a PWA with Qwik City: https://twitter.com/vendure_io/status/1600412989642878977

That now can also have push notifications. And pretty sweet Shared Element Transitions (could even be used in MPA's):

https://twitter.com/dannymoerkerke/status/159718717278369382...

pfoof• 3 years ago

By looking at App Store and Google Play policies, reviews* and putting the big companies at the storefront, PWA should become the default. It can also minimize planned obsolescence (as long as CA certs are valid).

*Not to be confused with users' ratings and reviews

srhyne• 3 years ago

Does anyone know if this release includes universal link support?

The flexibility of multiple instances separated by manifest ID is great! But it makes universal links challenging. Would need to include the ID in the URL path?

Web Push for Web Apps on iOS and iPadOS

Related Stories