News from WWDC23: WebKit Features in Safari 17 Beta(webkit.org)
webkit.org
News from WWDC23: WebKit Features in Safari 17 Beta
https://webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/
24 comments
That’s on Mac. PWAs on Mac aren’t a new capability since Chrome et al have had it for a long time. I’d be more interested if they improved iOS PWA capabilities
Any running list of what's still missing?
Does anyone have more details on this point: "Support for Ed25519 cryptography." ? I imagine it's part of SubtleCrypto, is it based on https://wicg.github.io/webcrypto-secure-curves/ ?
Yes.
> When a user adds a website to their Dock, Safari will copy the website’s cookies to the web app. That way, if someone is logged into their account in Safari, they will remain logged in within the web app. This will only work if the authentication state is stored within cookies. Safari does not copy over any other kind of local storage. After a user adds a web app to the Dock, no other website data is shared, which is great for privacy.
This seems like a strange decision.
1. Auth with local storage can be quite nice if you don't need to send the cookies to the server on every request.
2. This will lead to different login states in the browser and in the "app" which is not what I would expect and can be inconvenient if you open links to that website.
This seems like a strange decision.
1. Auth with local storage can be quite nice if you don't need to send the cookies to the server on every request.
2. This will lead to different login states in the browser and in the "app" which is not what I would expect and can be inconvenient if you open links to that website.
> Auth with local storage can be quite nice
With the `SameSite=strict` option on modern browsers and the `HttpOnly` (plus `Secure` to only run in SSL secured context), Cookies are more secure and the way to go instead of storing credentials anywhere accessible from within JavaScript. Before SameSite=strict, cookies were a security nightmare and often resultet in XSRF attacks, and required XSRF mitigations (like xsrf tokens), but this is no longer the case as all modern browsers support it.
With the `SameSite=strict` option on modern browsers and the `HttpOnly` (plus `Secure` to only run in SSL secured context), Cookies are more secure and the way to go instead of storing credentials anywhere accessible from within JavaScript. Before SameSite=strict, cookies were a security nightmare and often resultet in XSRF attacks, and required XSRF mitigations (like xsrf tokens), but this is no longer the case as all modern browsers support it.
Wish they would do this on iOS (and allow a custom install button). They recently removed shared Caches between serviceworkers in Safari and the PWA on iOS, requiring to relogin after every PWA "install" :(
As for your (2) point, I think cookies is the only thing that should be copied. LocalStorage or IndexedDB could result in inconsistwncies and breakage (PWA and Website code can version missmatch).
As for your (2) point, I think cookies is the only thing that should be copied. LocalStorage or IndexedDB could result in inconsistwncies and breakage (PWA and Website code can version missmatch).
I think links to the website installed as an app would open the app, no?
> Web apps on Mac support web push, badging, and all the usual web standards implemented by WebKit, just like web apps on iOS and iPadOS.
Not a lie, but they leave out an important part: To have webpush or badges on iOS you need to "install" the web app - but since iOS PWAs block custom install buttons, the user had to know thst he has to push "Share" and "Add to home screen". To my experience, almost noone knows this or does this.
Not a lie, but they leave out an important part: To have webpush or badges on iOS you need to "install" the web app - but since iOS PWAs block custom install buttons, the user had to know thst he has to push "Share" and "Add to home screen". To my experience, almost noone knows this or does this.
This is a good thing. Most websites that want to send you post notifications just want to spam you. It should be very intentional.
I have never, not once, in the years since websites could ask me if they can send me notifications said “yes, please notify me”. The notification prompt usually is just a reminder I need to go turn off the setting that lets websites ask me this silly question.
Who is consenting to these? What is their deal? It makes no sense to me.
Who is consenting to these? What is their deal? It makes no sense to me.
It’s the indy developer on HN who thinks that if only mean old Apple would enable this they could make millions by having a cross platform poorly performing web app without having to deal with the “App Store tax”.
Yes, unfortunately there are a lot of bad players. But you say it yourself: "websites" have asked you. Its mostly news sites that think they need to push you. There are proper web apps, that will have the "Enable notifications" button in their settings/preferences and are not spamy in any way.
A web app built with notifications as a core feature? Like conversation reminders.
> the user had to know thst he has to push "Share" and "Add to home screen".
So there has to be a tasteful user notification informing them that the site has enabled that feature in the manifest?
So there has to be a tasteful user notification informing them that the site has enabled that feature in the manifest?
Look at how android does it: By some heuristic (i.e. visiting the site regularly and interacting with it), Chrome will suggest you install the App (using Chromes UI). Additionally, you can have a custom UI button on your website, that triggers the install (user interaction is required to avoid install spam).
Neither works for Safari/iOS. The only way to help the user, is to show a step-by-step tutorial how he has to navigate his iOS Safari to install. And on top of that, nothing is shared between the installed PWA and the Safari instance - always requiring the user to re-login after install. It is just poor UX.
Neither works for Safari/iOS. The only way to help the user, is to show a step-by-step tutorial how he has to navigate his iOS Safari to install. And on top of that, nothing is shared between the installed PWA and the Safari instance - always requiring the user to re-login after install. It is just poor UX.
Nice now fix 3D transforms, SVG animations and clip-path or give me 200 hours of my life back. Safari rendering engine is a bug infested nightmare.
If I remember correctly, Safari addressed many transform-related bugs two years ago, which resulted in me noticing fewer bugs (quite drastically). Around that time, Safari became my primary development browser, which may have also contributed to this observation.
Based on Web Platform Test [0], it looks like Chromium browsers are not performing any better in this area.
[0] https://wpt.fyi/results/css?label=master&label=experimental&...
But I feel the pain of having to carefully test 2D/3D transform and animation on all browsers across platforms (even Safari on iOS and macOS can have different behaviors).
Based on Web Platform Test [0], it looks like Chromium browsers are not performing any better in this area.
[0] https://wpt.fyi/results/css?label=master&label=experimental&...
But I feel the pain of having to carefully test 2D/3D transform and animation on all browsers across platforms (even Safari on iOS and macOS can have different behaviors).
You're getting downvoted but to be honest, it's true -- Safari's layout engine and JS execution is just so glitchy and unpredictable. I'm guessing it's because they're prioritizing speed/efficiency over accuracy, but as a web dev it's...frustrating.
Yay, safari 17 will support profiles!
Seems like Apple got a bit more web friendly recently (esp. seeing web browsing demoed in Vision Pro)
Most likely being noticed because https://webkit.org/blog/13706/interop-2023/
Lots of nice improvements.
Interesting to see Safari adding JPEG XL support just as Chrome dropped it:
https://news.ycombinator.com/item?id=35589179
https://news.ycombinator.com/item?id=33399940