Apple apparently hates the name "progressive web apps", so how about: "offline web apps" or "installable web apps" or just "unrestricted web apps"? I'd like those names more, too. 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?
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.
>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.
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.
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.
>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...
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.
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.
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.
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.
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.
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 :-)
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.
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
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.
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?
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.
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.
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.
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.
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.
Chromium is a descendant of WebKit in the first place...
> With such absurd politics, I wonder how Apple survived through history.
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.
[+] [-] SiVal|6 years ago|reply
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.
[+] [-] aphextron|6 years ago|reply
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.
[+] [-] jxdxbx|6 years ago|reply
There is a place in the world for lowest-common-denominator cross-platform apps, but I wish it wasn't my browser.
[+] [-] millstone|6 years ago|reply
"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.
[+] [-] saagarjha|6 years ago|reply
FWIW, Safari generally outperforms competing browsers on benchmarks.
[+] [-] coldtea|6 years ago|reply
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...
[+] [-] Razengan|6 years ago|reply
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.
[+] [-] rwmj|6 years ago|reply
[1] https://webkitgtk.org/
[2] https://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/
[+] [-] jwilk|6 years ago|reply
[+] [-] SiVal|6 years ago|reply
[+] [-] mkurz|6 years ago|reply
[+] [-] cordite|6 years ago|reply
Though WebP would still be nice to have..
[+] [-] pornel|6 years ago|reply
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.
[+] [-] berkut|6 years ago|reply
[+] [-] newscracker|6 years ago|reply
[+] [-] tmikaeld|6 years ago|reply
It really is the golden authentication method, it's very thought through and incredibly easy to use (unfortunately not to implement though)
[+] [-] jlokier|6 years ago|reply
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 :-)
[+] [-] noja|6 years ago|reply
[+] [-] jpincheira|6 years ago|reply
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/
[+] [-] modeless|6 years ago|reply
[+] [-] xPaw|6 years ago|reply
The situation on iOS is even worse, because every browser is forced to use Webkit under the hood.
[1]: https://github.com/thelounge/thelounge
[+] [-] alexcroox|6 years ago|reply
[+] [-] cdbattags|6 years ago|reply
[+] [-] skrebbel|6 years ago|reply
[+] [-] paganel|6 years ago|reply
[+] [-] rwmj|6 years ago|reply
[+] [-] altmind|6 years ago|reply
[+] [-] om2|6 years ago|reply
[+] [-] 214896|6 years ago|reply
It's a layer of their JS pipeline.
[+] [-] sirn|6 years ago|reply
Data Flow Graph, JavaScriptCore's optimizing JIT.
https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
[+] [-] scottdeto|6 years ago|reply
[+] [-] greatjack613|6 years ago|reply
https://chromium.googlesource.com/chromium/src/+/master/docs...
https://altstore.io/
[+] [-] kmlx|6 years ago|reply
- 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.
[+] [-] shantly|6 years ago|reply
[+] [-] acdha|6 years ago|reply
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.
[+] [-] riazrizvi|6 years ago|reply
[+] [-] bumblebritches5|6 years ago|reply
[deleted]
[+] [-] rptr_87|6 years ago|reply
https://developer.chrome.com/apps/nativeMessaging
[+] [-] lwansbrough|6 years ago|reply
[+] [-] throwGuardian|6 years ago|reply
[+] [-] jitl|6 years ago|reply
[+] [-] suyash|6 years ago|reply
[+] [-] asciident|6 years ago|reply
[+] [-] Carpetsmoker|6 years ago|reply
[+] [-] chipotle_coyote|6 years ago|reply
[+] [-] mtgx|6 years ago|reply
[deleted]
[+] [-] The_rationalist|6 years ago|reply
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.
[+] [-] Razengan|6 years ago|reply
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.
[+] [-] hirsin|6 years ago|reply
[+] [-] The_rationalist|6 years ago|reply