WebKit Goals for 2020
trac.webkit.org
trac.webkit.org
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.
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.
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.
FWIW, Safari generally outperforms competing browsers on benchmarks.
Unless you:re on iOS where Apple bans competing browers
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
Because of that, my recommendation is to just stop using MacOS if you care about browser performance.
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.
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.
There is a place in the world for lowest-common-denominator cross-platform apps, but I wish it wasn't my browser.
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.
"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.
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.
How has allowing competing browser engines on Android helped the web ecosystem? Non-Chromium browsers are a rounding error on Android.
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?
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...
[2] https://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/
Though WebP would still be nice to have..
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.
As far as I am aware HEVC issues is still not fully resolved. And likely unfit for Web usage.
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
So that you actually know what it's used for
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.
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?
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 a user presses a button in order to enable push notifications.
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.
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.
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.
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.
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.
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.
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.
It really is the golden authentication method, it's very thought through and incredibly easy to use (unfortunately not to implement though)
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.
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 :-)
1. You’ll need to find a notary if you lose your AWS MFA device
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.
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.
The situation on iOS is even worse, because every browser is forced to use Webkit under the hood.
Mail is standard, so it's not really a barrier. It kind of lessens the Caps-Lock Warriors of Bugzilla-like systems, though.
Hi! If you're here, you must have found a bug. Send an email to XXX@projectpage.tld 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.
It really is awful.
Data Flow Graph, JavaScriptCore's optimizing JIT.
https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
It's a layer of their JS pipeline.
https://chromium.googlesource.com/chromium/src/+/master/docs...
The problem in this case is effort. It’s not that easy to port a browser effectively.
- 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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.