33 ms·

Web Push for Web Apps on iOS and iPadOS

866 points by tech234a 4y ago

gloosx 4y ago
Finally. This is the reason most ugly Flutter-style app-site chimeras existed. Now it's slightly better.
redbar0n 4y 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 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/1597187172783693824?s=20 https://twitter.com/dannymoerkerke/status/159718717278369382...
pfoof 4y 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 4y 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?
osrec 4y ago
I can't believe they've finally added this. Been waiting at least 8 years.
- alexklarjr 4y ago
  [flagged]
- jonny_eh 4y ago
  Some of us have been waiting 15 years.
  - computing 4y ago
    some of us have been waiting for 29 years.
    - dmitriid 4y ago
      The big limousine disappears...
dariosalvi78 4y ago
great, now give me web bluetooth and I'll never develop an app ever again...
- jeroenhd 4y 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.
  - donbrae 4y 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?
    - jeroenhd 4y ago
      I doubt the legislators that are forcing Apple to open up the browser engine market will be very happy with Chrome being refused Bluetooth access for use in practical, real-world features. As far as I can tell, these APIs are part of Blink. Even if they're not, Chrome/ium will be ported to iOS eventually.
- JimDabell 4y 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.
dhalwani 4y ago
Any demos of these capabilities on GitHub ?
- deleted 4y ago
  [deleted]
- bradeeoh 4y 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.
- jakear 4y ago
  If you're comfortable with a little `npm i && node server.js`: https://github.com/JacksonKearl/push-simple 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 https://github.com/mdn/serviceworker-cookbook
- toastal 4y 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.
  - jakear 4y ago
    Strongest plausible interpretation doctrine would have you read this as "any git-accessible self contained minimal samples available"?
    - toastal 4y ago
      But feeding into a proprietary product isn’t good for us. Using Google and Photoshop as verbs isn’t great as is, but Git by its nature as a DVCS it becomes even more important we don’t have our language drift in a way that centralizes. Specifying that it is Git is even of questionable value. “Are there any samples with the source available“ is a better phrasing (minimal and self-contained aren't implied by naming a platform).
heygarrison 4y ago
This is awesome!
least 4y 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.
- tech234a 4y ago
  It requires adding the app your Home Screen first.
- om2 4y 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 4y ago
    they thought of everything huh?
  - least 4y 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.
  - Eduard 4y 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.
banashark 4y ago
This is great for the progress of PWAs
diebeforei485 4y 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?
- Etheryte 4y 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 4y 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.
    - Etheryte 4y ago
      This is not a threat model that's unique to PWAs though, nor in any way enabled by what's seen here. Installing a PWA is practically equivalent to installing an app and a malicious app or an app that had their OneSignal or similar credentials compromised could do the exact same thing.
      - diebeforei485 4y ago
        Apple can disable push notifications from a compromised app. It's unclear if they can do it for a compromised website, which was my question above.
- cuttysnark 4y 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.
LeanderK 4y 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?
- barnabee 4y 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.
- cientifico 4y 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 4y 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?
  - threeseed 4y 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.
    - hn_throwaway_99 4y ago
cronix 4y 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 4y 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_k 4y 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.)
    - geysersam 4y ago
      No need to maintain multiple versions of applications for different platforms.
      - deleted 4y ago
        [deleted]
    - ffritz 4y ago
      Let’s see if they still do want your $100 by requiring it for their Push Notifications API.
afavour 4y 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.
- redbar0n 4y ago
  This is a really good little animation to teach users how to add it to the home screen: https://streakscore.com/help https://streakscore.com/help
- buildbot 4y ago
  Clicking the share icon and then add to home screen is byzantine?
  - boucher 4y ago
    Byzantine is a bit much, but it's not particularly discoverable if you don't already know what you're looking for.
  - lxgr 4y 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.
    - recuter 4y ago
      If you offer a PWA can't you just have a wee css popup with a big arrow floating at the bottom of the screen pointing out exactly how to install it?
      - afavour 4y ago
        The instructions to install vary by device, OS version, etc. etc. It should just be equivalent to native apps. A link to an App Store URL takes the user directly to an install screen. It was clearly seen as enough of an issue that they implemented that, so there's no reason web apps can't be the same.
alberth 4y 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 4y 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 4y 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 4y ago
  This is only for websites you intentionally add to your homescreen, though?
- smashed 4y 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.
tech234a 4y 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 4y 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.
lxgr 4y 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 4y 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.
  - SllX 4y 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”.
    - MBCook 4y ago
      Yeah but 3rd party engines would be a huge deal. Apple would never let that slip in a WebKit update post. It would get a ‘real’ announcement somewhere. Keynote slide, iOS features page, App Store rules update, flat out press release, etc.
metayrnc 4y 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 4y 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/ScreenOrientation/lock https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrien...
jacobp100 4y 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.
- MBCook 4y 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 4y 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 4y 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 4y 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.
- threeseed 4y 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.
  - 4y ago
tompetry 4y 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 4y ago
Dreams do come true (https://news.ycombinator.com/item?id=22687913 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.
- Alifatisk 4y ago
  That is incredible. I guess PWA is getting closer to success.
msoad 4y 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
- arendtio 4y 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.
- duxup 4y 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_ 4y 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.
    - yamtaddle 4y ago
      Check in with the average user of desktop browsers. You may find a lot of them have accidentally accepted web pushes and have no idea how to make them go away. I'd be shocked if the vast majority of "use" of the "feature" weren't exactly that kind of spammy, unwanted messaging.
      - KyeRussell 4y ago
        It’s certainly the majority of times I’ve been prompted to enable it for a website.
gdeglin 4y 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 4y 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.
- deleted 4y ago
  [deleted]
- pvg 4y ago
  It’s almost certainly not time for that: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%20don%E2%80%99t%20copy%20paste%20comments&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
djbusby 4y 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-py 4y 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
- jeroenhd 4y 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-py 4y 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
    - jeroenhd 4y ago
      I think something funky is going on on your device. Maybe Chrome or one of its tabs are running into some kind of memory leak? Maybe the OS is failing to kill enough other running applications and is letting Chrome hit some kind of memory limit? Maybe there's a bug in Chrome on certain devices? I'm still on a heavily modified Android 11 and my phone is receiving browser notifications fine, reboot or not. I know many of Google's pixels contain relatively weak CPUs to keep cost and battery consumption down, but that shouldn't be a reason for Chrome to keep crashing in the background. You can try going to chrome://serviceworker-internals/ and checking for any weird background service workers that may interfere with your browser. That page can also be used to troubleshoot serviceworkers (which can/are used for sending notifications).
stevenkkim 4y 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?
- MBCook 4y 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 4y 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 4y ago
Great addition.. I hope they soon add the install prompt and remove the stupid border dragging/pulling from safari.
slugiscool99 4y ago
Kudos to Apple for doing this. It's honestly very cool of them
CBarkleyU 4y 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?
- aeharding 4y ago
  Browserstack. Free for FOSS
- Sammi 4y ago
  https://www.browserstack.com/ https://www.browserstack.com/ Not afiliated.
- jeroenhd 4y 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 4y ago
  Linux builds of WebKit provided from https://WebKit.org/downloads https://WebKit.org/downloads.
aeharding 4y 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 https://news.ycombinator.com/item?id=33816700
Alifatisk 4y ago
This is shocking
supermatt 4y 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.
- deleted 4y ago
  [deleted]
fleddr 4y 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.
- deleted 4y ago
  [deleted]
gempir 4y ago
Will they ever allow chrome or other browsers to add PWA Apps to your Homescreen? That's what's missing for me.
- tomasf 4y ago
  [dead]
- teichmann 4y ago
  It’s mentioned in the article, see “Third-party browser support for Add to Home Screen”.
hajile 4y 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 4y 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!
  - deleted 4y ago
    [deleted]
  - MBCook 4y 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 4y 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
hollowturtle 4y 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
danShumway 4y 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.
- twism 4y ago
  Google Firestore?
  - danShumway 4y ago
somethoughts 4y ago
Great - just what I need for my productivity in 2023 - a Hackernews PWA icon on my iPhone's home screen with notifications!
Maxburn 4y ago
Going to be great for web based podcast apps that do live broadcasts like Curiocaster; https://curiocaster.com https://curiocaster.com
abxytg 4y ago
there is no good reason to have notifications on the web. its just for ads.
mvac 4y 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.
- postalrat 4y 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.
- LeanderK 4y 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 4y 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.
MBCook 4y 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 4y 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.
  - MBCook 4y 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.
  - JimDabell 4y 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.
s-xyz 4y ago
Any good documentation on how to implement this? Eg a react site with Python backend?
exoque 4y 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 4y 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 4y 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 4y 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/ https://fluidapp.com/
1-6 4y ago
Can't wait... Literally, I can't wait. 16.4 can't come quickly enough. I just installed 16.3.1 yesterday.
IceHegel 4y ago
This starts very defensively, pretty clearly hitting back at the idea that iOS has been intentionally holding back the web.
wackget 4y 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 4y 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 4y 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 4y ago
Is there a complete example app that demonstrates all of this?
1-6 4y ago
Finally, my short llll.com domains and site can compete with Apps on the App Store again!
CodeIsTheEnd 4y 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 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 4y 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
- coder543 4y 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/ https://web.dev/learn/pwa/caching/ [1]: https://web.dev/learn/pwa/caching/#what-to-cache https://web.dev/learn/pwa/caching/#what-to-cache
astlouis44 4y ago
Amazing, about time!
mertens 4y 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 4y 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 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!

866 points by tech234a 4y ago

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

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 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/1597187172783693824?s=20 https://twitter.com/dannymoerkerke/status/159718717278369382...

pfoof 4y 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 4y 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?

osrec 4y ago

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

alexklarjr 4y ago
[flagged]
jonny_eh 4y ago
Some of us have been waiting 15 years.
- computing 4y ago
  some of us have been waiting for 29 years.
  - dmitriid 4y ago
    The big limousine disappears...

dariosalvi78 4y ago

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

jeroenhd 4y 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.
- donbrae 4y 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?
  - jeroenhd 4y ago
    I doubt the legislators that are forcing Apple to open up the browser engine market will be very happy with Chrome being refused Bluetooth access for use in practical, real-world features. As far as I can tell, these APIs are part of Blink. Even if they're not, Chrome/ium will be ported to iOS eventually.
JimDabell 4y 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.

dhalwani 4y ago

Any demos of these capabilities on GitHub ?

deleted 4y ago
[deleted]
bradeeoh 4y 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.
jakear 4y ago
If you're comfortable with a little `npm i && node server.js`: https://github.com/JacksonKearl/push-simple 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 https://github.com/mdn/serviceworker-cookbook
toastal 4y 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.
- jakear 4y ago
  Strongest plausible interpretation doctrine would have you read this as "any git-accessible self contained minimal samples available"?
  - toastal 4y ago
    But feeding into a proprietary product isn’t good for us. Using Google and Photoshop as verbs isn’t great as is, but Git by its nature as a DVCS it becomes even more important we don’t have our language drift in a way that centralizes. Specifying that it is Git is even of questionable value. “Are there any samples with the source available“ is a better phrasing (minimal and self-contained aren't implied by naming a platform).

heygarrison 4y ago

This is awesome!

least 4y 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.

tech234a 4y ago
It requires adding the app your Home Screen first.
om2 4y 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 4y ago
  they thought of everything huh?
- least 4y 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.
- Eduard 4y 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.

banashark 4y ago

This is great for the progress of PWAs

diebeforei485 4y 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?

Etheryte 4y 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 4y 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.
  - Etheryte 4y ago
    This is not a threat model that's unique to PWAs though, nor in any way enabled by what's seen here. Installing a PWA is practically equivalent to installing an app and a malicious app or an app that had their OneSignal or similar credentials compromised could do the exact same thing.
    - diebeforei485 4y ago
      Apple can disable push notifications from a compromised app. It's unclear if they can do it for a compromised website, which was my question above.
cuttysnark 4y 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.

LeanderK 4y 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?

barnabee 4y 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.
cientifico 4y 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 4y 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?
- threeseed 4y 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.
  - hn_throwaway_99 4y ago

cronix 4y 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 4y 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_k 4y 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.)
  - geysersam 4y ago
    No need to maintain multiple versions of applications for different platforms.
    - deleted 4y ago
      [deleted]
  - ffritz 4y ago
    Let’s see if they still do want your $100 by requiring it for their Push Notifications API.

afavour 4y 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.

redbar0n 4y ago
This is a really good little animation to teach users how to add it to the home screen: https://streakscore.com/help https://streakscore.com/help
buildbot 4y ago
Clicking the share icon and then add to home screen is byzantine?
- boucher 4y ago
  Byzantine is a bit much, but it's not particularly discoverable if you don't already know what you're looking for.
- lxgr 4y 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.
  - recuter 4y ago
    If you offer a PWA can't you just have a wee css popup with a big arrow floating at the bottom of the screen pointing out exactly how to install it?
    - afavour 4y ago
      The instructions to install vary by device, OS version, etc. etc. It should just be equivalent to native apps. A link to an App Store URL takes the user directly to an install screen. It was clearly seen as enough of an issue that they implemented that, so there's no reason web apps can't be the same.

alberth 4y 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 4y 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 4y 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 4y ago
This is only for websites you intentionally add to your homescreen, though?
smashed 4y 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.

tech234a 4y 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 4y 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.

lxgr 4y 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 4y 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.
- SllX 4y 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”.
  - MBCook 4y ago
    Yeah but 3rd party engines would be a huge deal. Apple would never let that slip in a WebKit update post. It would get a ‘real’ announcement somewhere. Keynote slide, iOS features page, App Store rules update, flat out press release, etc.

metayrnc 4y 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 4y 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/ScreenOrientation/lock https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrien...

jacobp100 4y 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.

MBCook 4y 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 4y 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 4y 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 4y 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.
threeseed 4y 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.
- 4y ago

tompetry 4y 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 4y ago

Dreams do come true (https://news.ycombinator.com/item?id=22687913 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.

Alifatisk 4y ago
That is incredible. I guess PWA is getting closer to success.

msoad 4y 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

arendtio 4y 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.
duxup 4y 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_ 4y 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.
  - yamtaddle 4y ago
    Check in with the average user of desktop browsers. You may find a lot of them have accidentally accepted web pushes and have no idea how to make them go away. I'd be shocked if the vast majority of "use" of the "feature" weren't exactly that kind of spammy, unwanted messaging.
    - KyeRussell 4y ago
      It’s certainly the majority of times I’ve been prompted to enable it for a website.

gdeglin 4y 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 4y 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.

deleted 4y ago
[deleted]
pvg 4y ago
It’s almost certainly not time for that: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%20don%E2%80%99t%20copy%20paste%20comments&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

djbusby 4y 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-py 4y 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

jeroenhd 4y 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-py 4y 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
  - jeroenhd 4y ago
    I think something funky is going on on your device. Maybe Chrome or one of its tabs are running into some kind of memory leak? Maybe the OS is failing to kill enough other running applications and is letting Chrome hit some kind of memory limit? Maybe there's a bug in Chrome on certain devices? I'm still on a heavily modified Android 11 and my phone is receiving browser notifications fine, reboot or not. I know many of Google's pixels contain relatively weak CPUs to keep cost and battery consumption down, but that shouldn't be a reason for Chrome to keep crashing in the background. You can try going to chrome://serviceworker-internals/ and checking for any weird background service workers that may interfere with your browser. That page can also be used to troubleshoot serviceworkers (which can/are used for sending notifications).

stevenkkim 4y 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?

MBCook 4y 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 4y 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 4y ago

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

slugiscool99 4y ago

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

CBarkleyU 4y 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?

aeharding 4y ago
Browserstack. Free for FOSS
Sammi 4y ago
https://www.browserstack.com/ https://www.browserstack.com/ Not afiliated.
jeroenhd 4y 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 4y ago
Linux builds of WebKit provided from https://WebKit.org/downloads https://WebKit.org/downloads.

aeharding 4y 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 https://news.ycombinator.com/item?id=33816700

Alifatisk 4y ago

This is shocking

supermatt 4y 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.

deleted 4y ago
[deleted]

fleddr 4y 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.

deleted 4y ago
[deleted]

gempir 4y ago

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

tomasf 4y ago
[dead]
teichmann 4y ago
It’s mentioned in the article, see “Third-party browser support for Add to Home Screen”.

hajile 4y 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 4y 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!
- deleted 4y ago
  [deleted]
- MBCook 4y 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 4y 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

hollowturtle 4y 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

danShumway 4y 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.

twism 4y ago
Google Firestore?
- danShumway 4y ago

somethoughts 4y ago

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

Maxburn 4y ago

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

abxytg 4y ago

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

mvac 4y 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.

postalrat 4y 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.
LeanderK 4y 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 4y 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.

MBCook 4y 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 4y 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.
- MBCook 4y 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.
- JimDabell 4y 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.

s-xyz 4y ago

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

exoque 4y 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 4y 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 4y 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 4y 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/ https://fluidapp.com/

1-6 4y ago

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

IceHegel 4y ago

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

wackget 4y 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 4y 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 4y 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 4y ago

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

1-6 4y ago

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

CodeIsTheEnd 4y 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 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 4y 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
coder543 4y 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/ https://web.dev/learn/pwa/caching/ [1]: https://web.dev/learn/pwa/caching/#what-to-cache https://web.dev/learn/pwa/caching/#what-to-cache

astlouis44 4y ago

Amazing, about time!

mertens 4y 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 4y 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 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!