WebKit Goals for 2020(trac.webkit.org)
trac.webkit.org
WebKit Goals for 2020
https://trac.webkit.org/wiki/WebKitGoalsfor2020
153 comments
>where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS?
PWAs are a Google initiative for Android phones, with Mozilla and Microsoft simply following suit to get their products into Google's platform. Apple doesn't have that problem. They have their own platform with their own goals in mind. Non-native experiences are strictly inferior to native, and they know that. With quality being Apple's primary differentiator in the market, it only makes sense that they would take an extremely measured approach here.
PWAs are a Google initiative for Android phones, with Mozilla and Microsoft simply following suit to get their products into Google's platform. Apple doesn't have that problem. They have their own platform with their own goals in mind. Non-native experiences are strictly inferior to native, and they know that. With quality being Apple's primary differentiator in the market, it only makes sense that they would take an extremely measured approach here.
PWA is not a google-only thing, and if apple has better ideas for the implementation they should propose those, not implement a half-baked, buggy implementation of the standard agreed by all others years ago.
Native vs non-native is a red herring, there are performant webapps and slow native apps. There are accessible webapps and non-accessible native apps. If performance, accessibility or quality was the goal they would have stricter controls on their own store (as in not allowing apps that are basically "webpage-wrapped-in-webview" apps), as it is it seems that the goal is vendor lock-in and the revenue from in-app purchases.
Native vs non-native is a red herring, there are performant webapps and slow native apps. There are accessible webapps and non-accessible native apps. If performance, accessibility or quality was the goal they would have stricter controls on their own store (as in not allowing apps that are basically "webpage-wrapped-in-webview" apps), as it is it seems that the goal is vendor lock-in and the revenue from in-app purchases.
Web apps suck and all the doodads and gewgaws that browsers now have to implement have made the web a surveillance nightmare that is a worse experience for publishing and reading.
There is a place in the world for lowest-common-denominator cross-platform apps, but I wish it wasn't my browser.
There is a place in the world for lowest-common-denominator cross-platform apps, but I wish it wasn't my browser.
sozy777(1)
What is this hope for healthy browser engine competition? On Android and ChromeOS, Chrome and Chromium-based browsers have more than 99% marketshare.
"Apple should allow non-WebKit browsers" is really saying "what's holding back the mobile web is that Google does not completely dominate it." Only one thing prevents that outcome today.
"Apple should allow non-WebKit browsers" is really saying "what's holding back the mobile web is that Google does not completely dominate it." Only one thing prevents that outcome today.
Yes, this is precisely my fear. The moment that iOS is opened up to third party web engines and Blink-based Chrome has been ported, “viewed best in” badges will rise from the dead, and users will be badgered into installing Chrome for iOS, eliminating the last major non-Chrome holdout (Safari currently holds 16% marketshare). This will make Firefox extremely vulnerable with its ~4.3% marketshare.
That's a novel argument against allowing competing browsers. Let's apply a basic check on its validity. Do you think Mozilla agrees with it?
I think you'll find the answer is "no." Not allowing competing browsers does not help the web ecosystem or the users. It helps only Apple.
I think you'll find the answer is "no." Not allowing competing browsers does not help the web ecosystem or the users. It helps only Apple.
Yes I think Mozilla would agree with both the marketshare figures, and that iOS is the only effective check on Google's mobile web dominance.
How has allowing competing browser engines on Android helped the web ecosystem? Non-Chromium browsers are a rounding error on Android.
How has allowing competing browser engines on Android helped the web ecosystem? Non-Chromium browsers are a rounding error on Android.
> How has allowing competing browser engines on Android helped the web ecosystem?
By allowing people to install Firefox. Would you rather that Android be Chrome-only? Neither, I suspect, would Mozilla. The same applies to iOS, with its backwards browser holding back the web. Your argument would justify Microsoft making IE 6 the only allowed browser on Windows. Do you really not see how ridiculous that is?
By allowing people to install Firefox. Would you rather that Android be Chrome-only? Neither, I suspect, would Mozilla. The same applies to iOS, with its backwards browser holding back the web. Your argument would justify Microsoft making IE 6 the only allowed browser on Windows. Do you really not see how ridiculous that is?
> start outperforming your competition instead of merely banning your competition
FWIW, Safari generally outperforms competing browsers on benchmarks.
FWIW, Safari generally outperforms competing browsers on benchmarks.
WAT? I see Safari being substantially slower on pretty much every benchmark I throw at it.
Unless you:re on iOS where Apple bans competing browers
Unless you:re on iOS where Apple bans competing browers
No, I'm talking about macOS. Instead of linking to webkit.org's results, I'll provide a relatively recently run by someone on Hacker News: https://news.ycombinator.com/item?id=17361888
An under-appreciated fact is that JavaScriptCore is really really fast, and often outperforms v8 on benchmarks.
Do you consider efficient use of battery to be a dimension of “performance”? I do.
Safari's impact on battery life is amazing, and the main reason it's also my daily driver. I work a lot off of battery, and while Firefox recently got a lot better, it's still hard to trade a few hours of work time. and yes, even on my five years old air, I can get five hours of work in using safari, only three with Firefox.
By using undocumented MacOS private APIs, which bolsters his point. On OSes that don't have this issue, other browsers perform better on the same hardware.
https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
This has been going on since WebKit launched with no effort from Apple to clean it up, so it certainly seems intentional. http://archive.is/MtntN
https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
This has been going on since WebKit launched with no effort from Apple to clean it up, so it certainly seems intentional. http://archive.is/MtntN
CoreAnimation is not a private API. Everything directly mentioned in that post is public API. Firefox may use private API but it’s not mentioned in the post.
"It’s worth noting that the ability to assign an IOSurface to the CALayer contents property is not properly documented."
Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the public SDK).
The second link has private APIs, and the header file to access those private APIs still exists in WebKit for MacOS. I mentioned both undocumented and private. The first link just shows that if you are Apple, you can correctly call APIs that provide a performance increase on MacOS.
Because of that, my recommendation is to just stop using MacOS if you care about browser performance.
Because of that, my recommendation is to just stop using MacOS if you care about browser performance.
> The second link has private APIs
Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver...) was not available.
> the header file to access those private APIs still exists in WebKit for MacOS
The most these headers can do is maybe help with rendering performance, of which I'm not completely certain that there are still APIs that Safari uses that other browsers don't. I cannot see how benchmark scores from e.g. JavaScriptCore would be affected.
> Because of that, my recommendation is to just stop using MacOS if you care about browser performance.
Your point doesn't logically follow.
Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver...) was not available.
> the header file to access those private APIs still exists in WebKit for MacOS
The most these headers can do is maybe help with rendering performance, of which I'm not completely certain that there are still APIs that Safari uses that other browsers don't. I cannot see how benchmark scores from e.g. JavaScriptCore would be affected.
> Because of that, my recommendation is to just stop using MacOS if you care about browser performance.
Your point doesn't logically follow.
> Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver...) was not available.
And private APIs that still aren't available, as I noted in the second section you responded to.
> The most these headers can do is maybe help with rendering performance
Exactly. Everything I referenced was about rendering performance. I never claimed otherwise, so don't derail the argument by strawmanning JavaScriptCore vs. V8 on MacOS.
> Your point doesn't logically follow.
If you want the most speed, you want to use a platform that gives everyone access to APIs that enable it. QED.
And private APIs that still aren't available, as I noted in the second section you responded to.
> The most these headers can do is maybe help with rendering performance
Exactly. Everything I referenced was about rendering performance. I never claimed otherwise, so don't derail the argument by strawmanning JavaScriptCore vs. V8 on MacOS.
> Your point doesn't logically follow.
If you want the most speed, you want to use a platform that gives everyone access to APIs that enable it. QED.
>Regardless of the name, where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS?
Why should they make "web apps first-class apps on iOS"?
As an iOS user I'd rather they discouraged them.
The whole value proposition of iOS is getting fast, native apps, that directly use the APIs.
Not encouraging lowest common denominator implementations...
Why should they make "web apps first-class apps on iOS"?
As an iOS user I'd rather they discouraged them.
The whole value proposition of iOS is getting fast, native apps, that directly use the APIs.
Not encouraging lowest common denominator implementations...
Most modern web tech is trash and a crutch for lazy developers.
There. I said it.
In a blunt way what so many other comments here have tried to say without offending anyone. Redirect your ire. :)
At best most uses of such tech prey upon users' information, naïveté, and hardware resources. At worst they are outright malicious.
I'm glad there is at least one company with the muscle to put their foot down on this shit. We'd still be stuck with fucking Flash if y'all had your way.
Instead of reinventing a wheel that doesn't travel far to begin with, major companies should be putting a better effort into write-once-run-natively-everywhere technologies.
I don't care if it's SwiftUI, XAML, Qt or whatever. Just stop forcing everyone to spend most of their software time in a half-assed VM when we have had perfectly capable operating systems for millennia.
There. I said it.
In a blunt way what so many other comments here have tried to say without offending anyone. Redirect your ire. :)
At best most uses of such tech prey upon users' information, naïveté, and hardware resources. At worst they are outright malicious.
I'm glad there is at least one company with the muscle to put their foot down on this shit. We'd still be stuck with fucking Flash if y'all had your way.
Instead of reinventing a wheel that doesn't travel far to begin with, major companies should be putting a better effort into write-once-run-natively-everywhere technologies.
I don't care if it's SwiftUI, XAML, Qt or whatever. Just stop forcing everyone to spend most of their software time in a half-assed VM when we have had perfectly capable operating systems for millennia.
We use WebKitGtk[1] (embedded WebKit) in our presentation software Tech Talk PSE[2]. It would be great if SVG rendering, used for diagrams, was of equal quality to Firefox, but unfortunately Firefox seems to render SVG in a far superior way so we usually have to convert to PNG files to make diagrams embed correctly.
[1] https://webkitgtk.org/
[2] https://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/
[1] https://webkitgtk.org/
[2] https://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/
What software do you use for SVG→PNG conversion?
Unfortunately, converting to PNG doesn't work for interactive apps that use SVG as an interactive GUI instead of just a static vector image format. Of course, the user could just install Firefox (or Chrome) to get good-quality SVG support if Apple allowed it, which is why Apple doesn't allow it on iOS. After all, if Apple allowed you to freely choose a fully-working browser, they couldn't force you to use their Apple-only native technologies to get things to work well. It would be much harder to lock you and your customers (sorry, Apple reminds us that they are actually Apple's customers, NOT yours) into Apple's private world.
Please finally implement the date and time input times!
https://caniuse.com/#feat=input-datetime
The fact that <input type="date"> still isn't a thing proves to me that semantic HTML, non-bloated JS bundles, etc. just will never happen.
It is a thing, just not in Safari
I'm glad that battery life is a top priority.
Though WebP would still be nice to have..
Though WebP would still be nice to have..
Apple already has HEIC codec on their systems, which is half the size of WebP.
I'm curious why they're not exposing it to the Web. Is it because the codec is a ball of risky C++ code? Patent issues? Or because it's non-standard, and for once, they don't want to add a non-standard feature?
There's also JPEG XL being standardized now, which gives similar compression while also supporting lossless conversion from the classic JPEG. This offers nicer migration path. With other formats conversion from JPEG is lossy, so you get smaller files partly because you lose quality in the process.
I'm curious why they're not exposing it to the Web. Is it because the codec is a ball of risky C++ code? Patent issues? Or because it's non-standard, and for once, they don't want to add a non-standard feature?
There's also JPEG XL being standardized now, which gives similar compression while also supporting lossless conversion from the classic JPEG. This offers nicer migration path. With other formats conversion from JPEG is lossy, so you get smaller files partly because you lose quality in the process.
> Patent issues?
As far as I am aware HEVC issues is still not fully resolved. And likely unfit for Web usage.
As far as I am aware HEVC issues is still not fully resolved. And likely unfit for Web usage.
HEIF support in Safari would be nice...
Will 2020 be the year when WebKit, and the Safari browsers by extension, will have full and proper support for Service Workers and PWAs on par with other browsers? I recall reading that Safari lags behind on it, and the allegation was that Apple prefers native apps and doesn’t want web apps to be more popular.
I sure hope not. Why do I want web pages to be able to run persistent background tasks? Such an obviously bad idea. The tragedy is that Apple actually is implementing support for this garbage.
Web pages will never run persistent background tasks on iOS unless you install them. And even then, native apps are also both highly restricted and often have background tasks that you wouldn’t approve of if you knew what they were.
Hopefully not. I'd hate to click through "This site wants to push new ads to you. Allow notifications?" modals on my shiny new iPhone (edit: in addition to content being constrained to poststamp-sized areas between GDPR banners).
You should understand the argument before you form an opinion on it. First of all, there are plenty of us who have legitimate use cases for web push. Second, if you care about being bothered by shitty sites prompting you unprovoked, you have a couple options: content blockers or use different sites.
The need for notifications is real and Apple’s choice to exclude their availability in iOS is a business move not a technical move or a users-first move. Making PWAs better on iOS runs counter to Apple’s walled garden business model.
The need for notifications is real and Apple’s choice to exclude their availability in iOS is a business move not a technical move or a users-first move. Making PWAs better on iOS runs counter to Apple’s walled garden business model.
The need for notifications is real, but the need to protect users from unwanted notifications and tracking and fingerprinting is real too, and more pressing.
Every site complains about your content blocker. Every site wants to send you notifications. Every site wants your email address to advertise at you. And with PWAs, every site will want to establish a presence on your computer.
Your motives may be pure, but your chosen platform does not place you in good company.
Every site complains about your content blocker. Every site wants to send you notifications. Every site wants your email address to advertise at you. And with PWAs, every site will want to establish a presence on your computer.
Your motives may be pure, but your chosen platform does not place you in good company.
> There are plenty of us who have legitimate use cases for web push
Such as? The only use case for notifications and PWAs I'm coming across are clickbait news sites creating a sense of urgency with "homepage was updated" modals obscuring content and capturing click events. Web user agents have freedoms in rendering pages to users, and Safari siding with users and power efficiency is a good thing. In line with other comments, I predict browsers will soon provide opt-out for notifications, then eventually deprecate them altogether, like they did with popups/popunders.
Now, more importantly, Safari could work on their odd pick list control rendering like a dial wheel.
Such as? The only use case for notifications and PWAs I'm coming across are clickbait news sites creating a sense of urgency with "homepage was updated" modals obscuring content and capturing click events. Web user agents have freedoms in rendering pages to users, and Safari siding with users and power efficiency is a good thing. In line with other comments, I predict browsers will soon provide opt-out for notifications, then eventually deprecate them altogether, like they did with popups/popunders.
Now, more importantly, Safari could work on their odd pick list control rendering like a dial wheel.
I run a premium retreat in rural India for which I built a web based portal to act as an “app” for the event.
I don’t have the resources to build native and web applications for each platform.
Right now we make announcements for the next schedule item. I’d like to notify attendees via the web app I wrote and have it display schedule information offline.
I don’t have the resources to build native and web applications for each platform.
Right now we make announcements for the next schedule item. I’d like to notify attendees via the web app I wrote and have it display schedule information offline.
> I’d like to notify attendees via the web app I wrote
You can notify them by email, SMS or using any other messenger. There's no need to force another on your customers.
> and have it display schedule information offline.
Your customers already have a calendar application, there's no need to make them visit a web page for that. At least there wouldn't if Google supported Webcal so everyone can use their favorite native applications instead. But that wouldn't push people towards Google's services and garbage web apps.
You can notify them by email, SMS or using any other messenger. There's no need to force another on your customers.
> and have it display schedule information offline.
Your customers already have a calendar application, there's no need to make them visit a web page for that. At least there wouldn't if Google supported Webcal so everyone can use their favorite native applications instead. But that wouldn't push people towards Google's services and garbage web apps.
Here's a site I made with a legitimate use of Web Push. https://james.darpinian.com/satellites/
Ok, but I hope you can agree that the overwhelming majority of uses is a user-hostile dark pattern in news sites where they put crap onto pages so you click on it to go away, with the intent to generate additional page views and ad play-outs.
Of course. Likewise, I hope you can agree that the abuse of Web Push and other new browser features is a problem that can and should be solved without totally giving up on those new features and blocking or removing them entirely.
I see a lot of people advocating that the Web should be essentially frozen at its current feature set or even regressed to something much less capable, and that makes me sad.
I see a lot of people advocating that the Web should be essentially frozen at its current feature set or even regressed to something much less capable, and that makes me sad.
You asked for a legitimate use case and are now shifting the goal posts to be about “majority.”
If the web is to improve we need new features and strategies to mitigate the negative effects of the implementation of these features. Don’t throw the baby out with the bath water.
If the web is to improve we need new features and strategies to mitigate the negative effects of the implementation of these features. Don’t throw the baby out with the bath water.
New features on "the web" are coming straight from Google to push their monopolist agenda (DoH, URL hiding just to name a few from this past week). Seeing as today's web is bordering on becoming useless (save for a couple enthusiast sites) and net-negative even, only helping autocrats, criminals, surveillance and privacy-invading monopolists rather than users and content creators I'd say we've already thrown out the baby with the bath water, and the "save the web" at all costs narrative needs to go away.
In reply to tannheuser: Follow that logic, there's no need for images either (if you're in the late 90s), since the majority of the really useful content on the web is text... I understand your frustration, but I don't think the solution is to remove functionality from the web.
That doesn't follow logically at all since we don't have to choose between the extremes of allowing sites to push ads, or disallow images altogether (your figure of speech is called the fallacy of the excluded middle in classic logic I believe).
The only use case for notifications and PWAs I'm coming across are clickbait news sites...
I write apps for myself, my family, and my friends. I put them on MY server and make them available to OUR devices. We should be able to notify ourselves whenever we want. Our devices should ask whether we want notifications or not to make sure, and we should be able to say yes. If a browser maker simply wants to avoid burdening the user, there should be a way to choose a default with blacklist or whitelist exceptions.
Instead, Apple (for example) says, "If you want to burden users by asking them if they want notifications, that would be very bad unless you first pay us for a dev account and keep paying and commit to using our own proprietary tech instead of using open web tech, because users aren't bothered by requests to allow notifications as long as they know it helps Apple. If you do, we will grant you the privilege of trying to persuade us that your app benefits us and not just yourself and your friends. Our App Store terms require you to show how your app isn't just a website (which we won't allow to send notifications) but serves Apple's needs in some way before we'll let you send notifications to yourself.
If it were really about serving the needs of users, iOS could allow users a choice between the default "browser that says NO" and "sides with users and power efficiency" and alternative browsers that, like App Store apps, show their contempt for users by letting them decide for themselves what they want.
I write apps for myself, my family, and my friends. I put them on MY server and make them available to OUR devices. We should be able to notify ourselves whenever we want. Our devices should ask whether we want notifications or not to make sure, and we should be able to say yes. If a browser maker simply wants to avoid burdening the user, there should be a way to choose a default with blacklist or whitelist exceptions.
Instead, Apple (for example) says, "If you want to burden users by asking them if they want notifications, that would be very bad unless you first pay us for a dev account and keep paying and commit to using our own proprietary tech instead of using open web tech, because users aren't bothered by requests to allow notifications as long as they know it helps Apple. If you do, we will grant you the privilege of trying to persuade us that your app benefits us and not just yourself and your friends. Our App Store terms require you to show how your app isn't just a website (which we won't allow to send notifications) but serves Apple's needs in some way before we'll let you send notifications to yourself.
If it were really about serving the needs of users, iOS could allow users a choice between the default "browser that says NO" and "sides with users and power efficiency" and alternative browsers that, like App Store apps, show their contempt for users by letting them decide for themselves what they want.
> Such as?
Such as a user presses a button in order to enable push notifications.
Such as a user presses a button in order to enable push notifications.
That's an explanation of how users can allow notifications, not why they should.
What is so “real” about the need for notifications? Apart from messenger/email for which we already have dedicated apps both on desktop and on mobile, for what else would we “really” need push notifications? I don’t really want to be interrupted by anything that isn’t urgent, and stuff other than messaging is not urgent at all (I’m talking browser interactions here, I suspect and hope that things like nuclear power plants don’t rely for their “urgent” stuff on browsers’ capabilities and I also hope they don’t have anything to do with easily-hackable browsers at all).
wait is that "the argument" we're supposed to understand? you know, just because I use alert() in my code to debug doesn't mean that it should necessarily actually... work, and stuff... tl;dr - the tragedy of the commons exists; hence, lots of shitty technology that would otherwise be prone to it doesn't exist.
Not if you actually solve the problem.. which is basically just to make the permission only possible if the user interacts with the page in some way that satisfies a heuristic.
> The need for notifications is real
Do you keep metrics on acceptance rates? How many of the notification prompts that you pop up are actually accepted? How much of the time are you just annoying your users?
Do you keep metrics on acceptance rates? How many of the notification prompts that you pop up are actually accepted? How much of the time are you just annoying your users?
Like I said, our use case is legitimate in the strictest sense. Users request to enable notifications themselves. We never automatically prompt for it. So like.. 100%.
Notification support is already a thing, and is separate from PWA support.
As opposed to every native app that says the same thing?
Making the web suck more to match the native experience would be stupid. If people wanted the inconvenience of native apps, they'd use native apps.
They do use native apps, because they offer these features and other conveniences only afforded to native apps within Apple’s control.
Problems with Apple’s app review guidelines should be addressed by pushing for Apple to improve the guideline itself. Pushing for Apple to make their browser more adtech-friendly to the detriment of its users is not a solution.
The core problem with Apple's review guidelines is that Apple should not get to set "review guidelines" for software that runs on a phone they sold to someone else, whether or not they happen to be part of a massive oligopoly wherein their sales and deployed fleet constitute some large percentage of phones being sold with quality parts (using supply chains they have locked up through contracts to prevent small competitors, along with patents on hardware features that they bundle access to only with their locked in software ecosystem). And so like, I in some sense agree? But what this means, and the reason why I agree, is that there should exist an app I can install called Chrome or Firefox that implements a web browser that works the way I might want, in addition to the ability to install whatever app I want (which may, or may not, solve the app review problem).
Browser vendors are finally catching on.
From Firefox 72 permission prompts won’t be shown unless they’re triggered from a user interaction.
From the blog post:
> Notification prompts are very unpopular. On Release, about 99% of notification prompts go unaccepted, with 48% being actively denied by the user.
https://blog.mozilla.org/futurereleases/2019/11/04/restricti...
I’ve heard Chrome is moving in a similar direction
From Firefox 72 permission prompts won’t be shown unless they’re triggered from a user interaction.
From the blog post:
> Notification prompts are very unpopular. On Release, about 99% of notification prompts go unaccepted, with 48% being actively denied by the user.
https://blog.mozilla.org/futurereleases/2019/11/04/restricti...
I’ve heard Chrome is moving in a similar direction
When I soft-launched MVP I built to 50 odd users, I was surprised that one user said they uninstalled the app after a couple of days because they simply didn't like the app throwing nagging notifications (it seemed to me, given the nature of the app, the notifications were essential information, but apparently not). Android does let you turn off the notifications per channel per app, but I guess most users aren't aware, surprisingly, even the ones who are annoyed by notifications.
So instead of getting a permission prompt on load, I will get it when I first click on something. No thanks.
No. It should be done the way like Slack does it:
- You want to get Notifications for Messages? Click here
So that you actually know what it's used for
So that you actually know what it's used for
I'm dealing with a bug currently where Slack doesn't keep track of whether I've enabled notifications, so I always get the banner. I think I'd go mad if every website did that :(
Not if you close
Tab before clicking :)
There's the middle ground where I can freely browse the page without ever being prompted so see notifications. Apple gets this right.
There's been a lot of talk on this thread about the push notifications aspect. Setting that aside, at Wanderlog (https://wanderlog.com), we considered using PWA's and didn't because of another 2 WebKit limitations: storage and fast expiration.
We wanted to store pictures of where the user wants to go and cache map tiles offline. Mobile Safari has a limit of 50 MB. This is not enough for these use-cases.
Even more annoyingly, Apple deletes PWA's on iPhones after a few weeks. Our users often plan their trips months or many weeks in advance, and don't look at them for weeks at a time. By the time they go on the trip, they may be shocked to see that Apple has evicted their data from the local storage, just as they land somewhere where they no longer have access to 3G data!
I think Google's approach of providing virtually unlimited permanent storage is also probably not the best, but something in the middle might be better.
At the moment, it's clear that making PWA's capable is not an Apple-wide priority, even if the WebKit or Safari team may be in favor. We decided to avoid fighting it and build a native (React Native) app instead.
We wanted to store pictures of where the user wants to go and cache map tiles offline. Mobile Safari has a limit of 50 MB. This is not enough for these use-cases.
Even more annoyingly, Apple deletes PWA's on iPhones after a few weeks. Our users often plan their trips months or many weeks in advance, and don't look at them for weeks at a time. By the time they go on the trip, they may be shocked to see that Apple has evicted their data from the local storage, just as they land somewhere where they no longer have access to 3G data!
I think Google's approach of providing virtually unlimited permanent storage is also probably not the best, but something in the middle might be better.
At the moment, it's clear that making PWA's capable is not an Apple-wide priority, even if the WebKit or Safari team may be in favor. We decided to avoid fighting it and build a native (React Native) app instead.
Why not choosing Cordova/IONIC?
Through it's 4000 native Java plugins it can do all the things a PWA can, and even more.
I sure hope not. Apple is the last bastion slowing down widespread use of these horrible technologies that have way more downsides than problems they solve. Privacy and increasing attack surface on your system are the primary concerns for me.
No PWAs, no proper service workers, no native lazyload, no WebP, always lagging behind with more buggy implementation of almost everything. Can't blame people who call it the new IE6/8.
And web share target...
I've been implementing FIDO2 into my serverless application, finally there will be iOS support!
It really is the golden authentication method, it's very thought through and incredibly easy to use (unfortunately not to implement though)
It really is the golden authentication method, it's very thought through and incredibly easy to use (unfortunately not to implement though)
FIDO2 is working, but I wouldn't call it "golden" at all.
Tying authentication to a single device you can lose, especially one controlled by the device vendor not by yourself, sounds highly risk prone to me.
As far as I'm aware, this is not yet a solved problem with WebauthN or FIDO2 standards - they simply recommend that you provide another authentication method or backup device for recovery, and leave it to you to figure out. (If I've got this completely wrong, I'd love to know.)
Although not the same thing, in a similar vein we're already hearing about people locked out of bank accounts that were created in a phone app, and Google doc accounts that they can't log into any more.
I wouldn't make the decision to run a business on the back of serverless services I could only get into with FIDO2 keys that are hidden in a vendor device that might die any day.
For now, I'll stick with backed up SSH keys and very secret passphrases :-)
Tying authentication to a single device you can lose, especially one controlled by the device vendor not by yourself, sounds highly risk prone to me.
As far as I'm aware, this is not yet a solved problem with WebauthN or FIDO2 standards - they simply recommend that you provide another authentication method or backup device for recovery, and leave it to you to figure out. (If I've got this completely wrong, I'd love to know.)
Although not the same thing, in a similar vein we're already hearing about people locked out of bank accounts that were created in a phone app, and Google doc accounts that they can't log into any more.
I wouldn't make the decision to run a business on the back of serverless services I could only get into with FIDO2 keys that are hidden in a vendor device that might die any day.
For now, I'll stick with backed up SSH keys and very secret passphrases :-)
It’s been a solved problem from the time it launched: you should never have one FIDO device since that leaves no room for failure. Every service I use except Amazon implemented this correctly[1] and the significant security improvements over TOTP or SSH keys are worth it, especially since phishing operations commonly bypass the easier schemes now.
1. You’ll need to find a notary if you lose your AWS MFA device
1. You’ll need to find a notary if you lose your AWS MFA device
I wouldn't be comfortable with one backup device kept in secure storage somewhere. If it fails you won't know, and you'll be operating without redundancy without knowing.
So that means keeping two or more devices in regular use. Somehow, without carrying them both around or keeping them in the same places. Tricky.
So that means keeping two or more devices in regular use. Somehow, without carrying them both around or keeping them in the same places. Tricky.
It means testing your backups and knowing what your unlock procedure is like — for example, can another administrator at your company perform that reset for you? This doesn't need to be something you do daily so you can schedule it but this is a classic security tradeoff: if you're not comfortable with the odds of multiple hardware devices simultaneously failing, you can simply decide to accept the greater security risk of using shared SSH keys or whatever you're using to manage passwords.
Can you recommend something to tie FIDO2 to generic web applications that don't support it directly?
Do you mean like a plugin or API?
FIDO2 is not something you can "paste on" it has to be built-in to the login feature, but I guess for things like Wordpress there are hooks you can use.
I know of no plugins or APIs you can use to add it, I guess if they appear they will be listed on Yubicos list [0] or on Github [1]
[0] https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F... [1] https://github.com/search?q=FIDO2
Important: U2F cannot be used as the only authentication method, unlike FIDO2 which fully replace password & 2-factor.
FIDO2 is not something you can "paste on" it has to be built-in to the login feature, but I guess for things like Wordpress there are hooks you can use.
I know of no plugins or APIs you can use to add it, I guess if they appear they will be listed on Yubicos list [0] or on Github [1]
[0] https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F... [1] https://github.com/search?q=FIDO2
Important: U2F cannot be used as the only authentication method, unlike FIDO2 which fully replace password & 2-factor.
I find it incredible that MediaStream Recording is still not out there on WebKit. They have taken so long to ship this. There's an open ticket[1] since 2012, and we still don't really know if they will implement this for sure on 2020, while Opera, Chrome, and Firefox already support this for years.
This is the main reason why we at Standups don't support video recording on Safari[2]. They are on the same level as Microsoft Edge, which also does not support video recording. It's hard for me to understand they did not want to catch up with the main players.
[1] https://bugs.webkit.org/show_bug.cgi?id=85851
[2] https://standups.io/help/not-using-chrome/
This is the main reason why we at Standups don't support video recording on Safari[2]. They are on the same level as Microsoft Edge, which also does not support video recording. It's hard for me to understand they did not want to catch up with the main players.
[1] https://bugs.webkit.org/show_bug.cgi?id=85851
[2] https://standups.io/help/not-using-chrome/
The Web Push API is missing. I was hoping for that one.
Yeah that's a real bummer. Our open source web app [1] supports web push but it doesn't work on Apple's devices because they won't implement it.
The situation on iOS is even worse, because every browser is forced to use Webkit under the hood.
[1]: https://github.com/thelounge/thelounge
The situation on iOS is even worse, because every browser is forced to use Webkit under the hood.
[1]: https://github.com/thelounge/thelounge
A lot of companies build a native version of their web app just for push notifications on iOS. Unfortunately I doubt we’ll see web push any time soon.
I avoid many native apps for the exact same reason. Too often I encounter apps that spam and spy on its users while providing no real benefit over a simple website.
No matter what, any and all improvements to JSC will do wonders to the React Native ecosystem and it's nice to have a list of targets.
Pardon the all-too-typical off topic: woa, Trac! I haven't seen that in a long time. I have fond recollections of its customizability. Is it still being used in anger and improving, or is this just a legacy system we're looking at?
I’ve been using a Trac+Svn combination for my personal projects for 13 years now. I mainly use it for repository browsing, as I don’t do bug/task management for any of my personal projects, but it’s cool seeing repositories 11 or 12 years old. If it ain’t broke why would I fix it?
Trac was/is truly to most awful bug tracking system. I mean a primary function of a bug tracking system should surely be to accept bug reports from users, yet Trac manages to make that the least discoverable and least usable feature. Even things like subscribing to an existing bug report or listing bugs are very hard to find. I would say "impossible" for ordinary people, but will get accused of exaggerating, but go and look at a Trac-based bug tracking system some time to see what I mean. One at random: https://trac.osgeo.org/geos
Accepting bug reports from users isn't necessarily a goal of bug trackers: in some workflows mailing lists are better for unconfirmed bugs, the actual bug tracker is for confirmed bugs (read: not submitted by users). It works better that way a large amount of the time.
You certainly want a good way to sort, classify, combine and remove reported bugs (which Trac also makes awful), but you should never put up barriers to accepting bug reports. My rule of thumb is that every bug that someone reports affects 9 other users who couldn't/didn't report it. (Probably with Trac it's 1:99 because of how difficult it is to use.)
If you tell people to submit bugs to a mailing list, that means that devs will manually confirm bugs before putting them onto the bug tracker: this gives an incentive to get them taken care of faster, because right as it's added, someone who knows the codebase has a general idea of what's wrong.
Mail is standard, so it's not really a barrier. It kind of lessens the Caps-Lock Warriors of Bugzilla-like systems, though.
Mail is standard, so it's not really a barrier. It kind of lessens the Caps-Lock Warriors of Bugzilla-like systems, though.
Then they have to subscribe to the mailing list, which is another set of extra steps. Some people only know the web exists and don't even know mailing lists are a thing.
url: projectpage.tld/bugs
Hi! If you're here, you must have found a bug. Send an email to [email protected] describing the bug, and we'll see to fixing it as fast as we can, and we'll alert you when we've started working on it!
You don't have to have them subscribe, necessarily.
Hi! If you're here, you must have found a bug. Send an email to [email protected] describing the bug, and we'll see to fixing it as fast as we can, and we'll alert you when we've started working on it!
You don't have to have them subscribe, necessarily.
As soon as someone thinks about reporting a bug, they’re already doing you a massive favour. Making them go away and write an email (which many people don’t often do any more) you’re already going to be testing their patience. You should be bending over backward to accept the report.
That is very far from true.
https://bugzilla.mozilla.org/show_bug.cgi?id=380270
https://bugzilla.mozilla.org/show_bug.cgi?id=309596
https://bugzilla.mozilla.org/show_bug.cgi?id=380270
https://bugzilla.mozilla.org/show_bug.cgi?id=309596
Which is basically what I said in https://news.ycombinator.com/item?id=21490182 Never put up barriers to accepting bug reports. Now does Trac help in any of this? No.
Trac is better than the GitHub/Bugzilla model, in any case, in my opinion.
WebKit uses Bugzilla: https://bugs.webkit.org
Bugzilla is also pretty awful (and I say this as someone who uses Red Hat's Bugzilla instance hourly in my job).
Django still uses Trac. https://code.djangoproject.com/query
It really is awful.
It really is awful.
Hard to understand what each of this items mean since there is no tracking issue# mentioned. Some of items cannot even be googled, what's "Turbo DFG"?
These are notes from a live presentation at the WebKit Contributors Meeting. All the items were explained live, there is only so much the notes can convey.
Search "WebKit dfg" = https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
It's a layer of their JS pipeline.
It's a layer of their JS pipeline.
> Some of items cannot even be googled, what's "Turbo DFG"?
Data Flow Graph, JavaScriptCore's optimizing JIT.
https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
Data Flow Graph, JavaScriptCore's optimizing JIT.
https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
One of JavaScriptCore's optimizing JITs.
What is "logged in API"?
They broke most federated auth scenarios with ITP, so there needs to be a way for auth to flow between websites in a way that allows users to consent and control it. The logged in API basically takes your auth state (to a first estimate) out of the 3rd party cookies and into the browser. The browser then understands when to reinject them. Ad networks lose tracking via 3p cookies, but you stay logged in to your accounts.
In response to all those complaining about no competing browsers on IOS. Why doesn't someone compile chromium for ios and then publish it using AltStore?
https://chromium.googlesource.com/chromium/src/+/master/docs...
https://altstore.io/
https://chromium.googlesource.com/chromium/src/+/master/docs...
https://altstore.io/
IOS requires all native code be signed so JIT wouldn't work. It would be a possibility on a jailbroken device, but someone would have to make a port.
Isn’t that the whole point of AltStore? Apple certainly didn’t sign the GameBoy emulator available on AltStore.
The problem in this case is effort. It’s not that easy to port a browser effectively.
The problem in this case is effort. It’s not that easy to port a browser effectively.
as is tradition already, webkit is missing:
- full PWA
- ServiceWorkers
- VP8/9
- webvr
- and many others
this could all be mitigated if aapl would let us install custom non-webkit browsers on ios. unfortunately it seems we will need the courts to force aapl.
- full PWA
- ServiceWorkers
- VP8/9
- webvr
- and many others
this could all be mitigated if aapl would let us install custom non-webkit browsers on ios. unfortunately it seems we will need the courts to force aapl.
Incidentally, is there a way to disable service workers on desktop Safari? Twitter’s went rogue the other day and started eating a whole core, non-stop. I don’t want or need them. Ever. Hopefully mobile safari doesn’t let developers do that to my phone, too.
Who’d benefit if they did? iOS users would benefit from AV1 but the only thing VP8/9 would add for web users is security exposure and lower battery life. Everyone serving video on the web already has equivalent quality H.264/H.265 and the next big change should be moving into the future with AV1 rather than spending millions to implement previous generations of codecs.
Similarly, as a developer I like the idea of Service Workers but as a user I’m forced to note that the only thing they seem to have added to my web experience are sites breaking in a way which requires more than a reload to fix.
Similarly, as a developer I like the idea of Service Workers but as a user I’m forced to note that the only thing they seem to have added to my web experience are sites breaking in a way which requires more than a reload to fix.
I appreciate this declaration
Does webkit support Native messaging like chrome...?
https://developer.chrome.com/apps/nativeMessaging
https://developer.chrome.com/apps/nativeMessaging
No mention of PWA features (specifically manifest/installation/web push) is so lame. Classic Apple politics.
How will they force you into the $99/annum developer program, shaft you a cool 30%, play judge and jury to your ios, macOs app store submissions and reject your work at the first hint of competition, if all the useful PWA features just work on iOS? Lest you dream of software freedom on Apple devices, their sycophants and overzealous employees will gaslight you into believing it's all for user experience and security, and any incidental monopolistic/anti-competitive byproducts are wholly acceptable collateral damage when the betterment of iKind, ahem, mankind is at stake.
You need to understand that many of us like Apple's approach.
We aren't looking for software "freedom" on our phones. We just want apps that are safe, curated, respectful of battery life and do not infringe on our privacy or user experience. Apple's approach gives us that.
So by all means complain about app store submissions but as a developer I don't have sympathy for other developers who play loose and fast with the rules.
We aren't looking for software "freedom" on our phones. We just want apps that are safe, curated, respectful of battery life and do not infringe on our privacy or user experience. Apple's approach gives us that.
So by all means complain about app store submissions but as a developer I don't have sympathy for other developers who play loose and fast with the rules.
I really disagree with this viewpoint. There's no reason Apple can't simultaneously embrace open standards while providing implementations that enforce privacy and battery life and all that. They could even push to improve those standards. What you have instead is the push for an isolated platform to enforce a monopoly and exclusion. Many of us may like it, but count me out.
Even though you’re happy with the way Apple is handling the user rights you’ve abrogated to their control right now, make sure you’re still going to be comfortable with that indefinitely because the tighter you’re locked into their ecosystem the harder it’s going to be to escape if different leadership with different priorities or incentives comes into power and starts making changes you don’t like.
Enlightened despotism is the ideal government in many ways. The fatal flaw is guaranteeing succession of another enlightened despot instead of an ordinary tyrant. This is why preserving choice, however messy, is so important.
Enlightened despotism is the ideal government in many ways. The fatal flaw is guaranteeing succession of another enlightened despot instead of an ordinary tyrant. This is why preserving choice, however messy, is so important.
Yep - opening up W3C PWA standards on iOS may really threaten "safe, curated, respectful of battery life and do not infringe on our privacy or user experience"
That's just science, and not a regurgitation of Apple's excuses, ahem, P.R. on the matter. I mean, just look at the devestation unleashed by chrome (which supports all PWA features) on MacOs.
That's just science, and not a regurgitation of Apple's excuses, ahem, P.R. on the matter. I mean, just look at the devestation unleashed by chrome (which supports all PWA features) on MacOs.
Service Worker is the first step - they need to catch up there first. It’s on the list!
PWA is not one single thing that needs a special mention, bunch of features they have listed will account for a better cross platform web & mobile experience.
None of which particularly contribute to being able to supplant an iOS app with a PWA. Which is intentional on Apple’s part.
No WebP? Safari is about to become out of date, and websites will stop working for it. I'm using WebP on my websites with no fallback to jpeg/png at the end of the year.
Imagine being software developer with a sense of professionalism and dealing with your customers as they are, even if it's annoying a tad bit of extra work, instead of telling them to sod off if they're using a browser you don't like.
While I Personaly wouldn't drop JPEG support yet...
Do non-web software developers support every CPU architecture? Because I'm sure I've heard of apps that not run on macs, or just windows and not Raspberry Pis.
Do non-web software developers support every CPU architecture? Because I'm sure I've heard of apps that not run on macs, or just windows and not Raspberry Pis.
You're trying to draw a comparison between app developers supporting multiple CPU architectures for their applications, and web developers continuing to use JPEG and PNG files for their web sites. I honestly just don't see how this comparison works.
Adding support for a CPU architecture is often a considerable amount of work, and the pay-off is often small, although this of course depends on what kind of software you have. For typical applications for end-users the cost/benefit ratio for supporting anything other than x86 is typically very low. For other types of applications like servers it's higher, so they often do support arm, s390, ppc, etc.
Supporting jpeg however is very low cost, with very high benefit: about 20% of browsers don't support webp. It's a small nuisance, not a substantial amount of continued investment of work like supporting a new architecture.
Supporting jpeg however is very low cost, with very high benefit: about 20% of browsers don't support webp. It's a small nuisance, not a substantial amount of continued investment of work like supporting a new architecture.
If 25-50% of your users used RasberryPis to run you app you’d support it properly.
Itanium failed, in part because it broke compatibility. AMD succeeded with x86_64 precisely because they realized that supporting the programs people actually used was vital.
Personally the problem is not that I don't like it, but that I have no way to test against it. No, I'm not buying their overpriced crap just to see what they've broken for their users.
Even MS has had modern.ie[0] for years. Until then, Safari users are on their own[1].
[0]: https://developer.microsoft.com/en-us/microsoft-edge/tools/v...
[1]: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
Even MS has had modern.ie[0] for years. Until then, Safari users are on their own[1].
[0]: https://developer.microsoft.com/en-us/microsoft-edge/tools/v...
[1]: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
Yeah, I agree with that. But it's one thing to say "sorry, I had no way to test against your browser", but quite another to say "I am going to intentionally break this browser because it's too 'old' by my standards".
You can apply for a free BrowserStack accounts for open source projects btw[1]; it's still a bit of a pain, but better than nothing.
[1]: https://www.browserstack.com/open-source
You can apply for a free BrowserStack accounts for open source projects btw[1]; it's still a bit of a pain, but better than nothing.
[1]: https://www.browserstack.com/open-source
Testing iOS Safari is painful on Browserstack, Appium adds significant latency which makes the tests slow, they use old Appium versions which can be buggy, and there are limitations due to poor WebDriver support from Apple like not being allowed to switch context to iframes from external domains...
> Imagine being software developer with a sense of professionalism and dealing with your customers as they are, even if it's annoying a tad bit of extra work, instead of telling them to sod off if they're using a browser you don't like.
Now imagine a platform where users are allowed to use a better browser which supports more image formats and saves their battery and bandwidth instead of being locked into a single closed piece of software for ever and ever.
And imagine a world where owners of that platform would understand something as historical as importance of free market competition and huge damage of DRM locked plaforms.
Now imagine a platform where users are allowed to use a better browser which supports more image formats and saves their battery and bandwidth instead of being locked into a single closed piece of software for ever and ever.
And imagine a world where owners of that platform would understand something as historical as importance of free market competition and huge damage of DRM locked plaforms.
Okay, you've named one web site that will stop working for it at the end of the year, because of a choice you're explicitly making.
It's fascinating to see how pathetic this roadmap is.
The totality (100%) of their planned features are already available on chromium.
Guess what, even after that the chromium of today (not 2020) still has an order of magnitude more features, optimisations and testing.
In human hours wise, comparing the number of full-time safari developers vs the number of full-time chromium (Google, Microsoft, opera, etc) developers is like comparing a third world country vs the USA GDP.
Or more exactly:
217,369 commits vs 835,383 commits!
Apple should just be rational and make the same synergistic move as Microsoft: migrate to chromium. It would save them R&W (reinventing the wheel) money, and they could allocate it to true R&D, allowing the web to move forward for making the world a better place.
If for whatever reason they wanted to opt out of some chromium features such as PWA they could still do it.
With such absurd politics, I wonder how Apple survived through history. Indeed the lack of rationality from the demand must help and irrational supply to thrive.
Apple should just be rational and make the same synergistic move as Microsoft: migrate to chromium. It would save them R&W (reinventing the wheel) money, and they could allocate it to true R&D, allowing the web to move forward for making the world a better place.
If for whatever reason they wanted to opt out of some chromium features such as PWA they could still do it.
With such absurd politics, I wonder how Apple survived through history. Indeed the lack of rationality from the demand must help and irrational supply to thrive.
> Apple should just be rational and make the same synergistic move as Microsoft: migrate to chromium. It would save them R&W (reinventing the wheel) money, and they could allocate it to true R&D, allowing the web to move forward for making the world a better place.
Chromium is a descendant of WebKit in the first place...
> With such absurd politics, I wonder how Apple survived through history.
Because users agree with them.
Chromium is a descendant of WebKit in the first place...
> With such absurd politics, I wonder how Apple survived through history.
Because users agree with them.
Chromium is a descendant of WebKit in the first place...
And safari is a descendant of KHTML, double standard I guess?
The world change.
Note that the logged in API is not supported in Chrom(e|ium). That WI be a big deal when finished because it will help with user privacy without breaking things.
Interesting to know, but they could develop this feature inside chromium so it is a moot point.
Moreover features only supported by safari will be used by exactly 0% of web developers.
Readers don't feel in accordance with my analysis.
Sadly no thoughts have yet been outputed..
Apple keeps silently "considering" and "accidentally" messing up various aspects of web app support, while strictly prohibiting browsers that work well. By prohibiting high-quality browsers, Apple pushes developers toward Apple-proprietary "native" technologies--those that are both allowed to be the only things that work well on Apple devices and are NOT allowed to work anywhere else.
Two WebKit goals I'd like to see for 2020: (1) Allow non-WebKit browsers on iOS (start outperforming your competition instead of merely banning your competition), and (2) Make iOS the best platform for powerful web apps instead of the worst, the leader instead of the spoiler.