Apple's ban of all browsers but Safari turned out to be the main barrier preventing progressive web apps from being viable, deepening the duopoly power of themselves and Google, because Apple refuses to implement basic browser standards that are necessary for PWAs.
And then when they do implement similar browser standards, they don't follow any web standards, they instead make their own proprietary bespoke web standard for Safari[1].
And they also did other fun things like wait until nearly 2021 to support WebP and let Safari be the the #1 source of one-click exploits on iOS.
It's weird to see Safari trotted out in defense of web standards of all things.
For years Google been stamping "standards" one after another even though other browser vendors were against many of them and they end up being Chrome-only.
No matter what Apple itself does Safari being major non-Chromium browser helps Firefox a lot just by existing and having huge marketshare.
How does Apple dragging their feet on implementing the Web Push notification standard, that is necessary for PWAs, in anyway help in that situation? Literally every browser except Safari implemented the the standard, and not out of some noble anti-Google crusade. PWAs threaten the App Store monopoly's moneyhose.
How does Apple releasing proprietary web standards just for Safari, like Safari Push Notifications, help in anyway with the purported problem of companies stamping out web standards without consensus? It seems like it's only a problem when Google does it, but when Apple does it, it's Safari "helping Firefox just exist".
And so I will be looking forward to the magical era of PWAs replacing all mobile applications because clearly push notifications was what was holding them back all these years.
Even though a tiny fraction of mobile apps use them but I guess we will ignore that.
Every single airline app on my phone is there only because of push notifications (which work more reliably than texts when traveling internationally with different SIMs). The same goes for most food delivery apps.
Food delivery apps seem to immediately abuse any form of push notifications in order to send spam. Lyft uses the same push stream for both driver ETA and 10% off coupons. They are indeed more reliable than SMS, yet I turn them off almost as fast as apps start to use them.
> Food delivery apps seem to immediately abuse any form of push notifications in order to send spam.
Oh, definitely. But if they do (and don't at least give me a way to immediately opt out of that) the app is gone from my phone – and they have no other way of reaching me. Beats the absolute nightmare that is SMS notifications and spam, in my view.
Android provides hooks to filter notifications from apps, while iOS does not, making the notification experience far worse. Allowing web push lets you filter notifications in a browser extension instead.
How do you mean? I can silence or block notifications completely from apps on iOS, and they cannot even send notifications before I approve them to do so.
Are you saying that Android has third party filters that surveil all your notifications in the name of blocking ones you might not want to see?
Yes, Android has a notifications API that lets you process all notifications. (This is in addition to the channels mentioned in the sibling comment.) This is not possible on iOS, except maybe for web notifications with a browser extension. I find that situation untenable for any power user of productivity apps, akin to using email without filter rules.
I'm an android only user, and I think what GP is referring to is that apps can categorise their notifications. In your food example, an app might have categories for "delivery updates" versus "special offers", and you can go into the notification settings for any app and turn on or off categories.
Actually the iphone was planned to use PWAs in the start, but Steve Jobs switched to native apps after realizing that performance and usability was going to be poor.
He was right and still is. Not that it's impossible to implement a good PWA, all you have to do is manage your state and interface in a way that no interaction takes longer than 50ms to compute. But most developers are not able to deliver than, most don't even think about UIs in this sort of way.
And V8 GC behaviour is still terrible and an unbelievable battery hog.
> No matter what Apple itself does Safari being major non-Chromium browser helps Firefox a lot just by existing and having huge marketshare.
That is incorrect because Apple has prevented and still prevents Firefox from properly implementing Gecko on iOS. Apple also restricts Firefox and browsers other than Safari from implementing full WebExtensions. Even though Firefox and browsers other than Safari are required to use WebKit on iOS, they are not allowed to access many of WebKit's iOS-integrated features including content blockers and Safari extensions.
All of these Apple-imposed handicaps make Firefox a much less competitive browser on iOS than it could be, and in no way helps Firefox because users generally prefer to use the same browser across their devices. The EU's upcoming browser choice legislation will prohibit Apple's anticompetitive restrictions to put Firefox on a more level playing field with Safari on iOS.
It's a three player world now, and Google wants a better web, Apple doesn't want a better web, and Mozilla is somewhere in-between, but increasingly playing the "privacy above all else" card too.
In June 2020, Apple declared a bunch of APIs they will not implement (https://www.zdnet.com/article/apple-declined-to-implement-16...), in a big press blitz trying to make it look like they were some noble hero. Web MIDI (incredible fun), Web USB (very useful for Arduino using folk for example, who have excellent web-based tools), Magnetometer/Ambient Light/Battery/Proximity sensors, WebHID, Device Memory, and that's just the half. A week latter Mozilla put out a similar PR using the exact same Fear Uncertainty and Doubt (FUD) to try to make themselves look good, to declare themselves virtuous non-implementors.
Sure, I agree, not every site should have access to these sensors/capabilities. There are privacy risks of turning them on. But they're also excellent capabilities, that really help users do interesting things. Making users use less-secure less-sandboxed native apps is a downgrade. There should be some security regimes where these web techs can be permitted.
For a while Mozilla wasn't even reviewing a sizable chunk of web standards (tracked via the excellent https://mozilla.github.io/standards-positions/), just declaring them unsafe & leaving the convo. They've at least started going back to old Request for Positions & reviewing a good number of them, even if they don't intend to implement. And there's a good number of standards they have about-faced on, have accepted as real asks. In general, I'm encouraged in seeing a much more interested & engaged & progressive Mozilla emerge quite recently, within the past year or so.
I don't know what to do about web standards. Google takes a lot of flak, but who is there to work with? Edge, a Chromium fork, has some pro-web attitude, and indeed drives some new features for Chromium & participates. But there's largely no one but Google+Edge to deal with left in the web standards implementer world. The other browser vendors are broadly against a lot of features, for reasons of malicious-self-interest. Meanwhile Chrome continues to have one of the most open, progressive, interactive, review-seeking, concensus-desiring, most mature & responsible feature-lifecycle processes the world has ever seen. There is nothing else on the planet that gets shipped with such a high bar, such a socially pro-active, such a well planned & democratic process for how the feature gets developed. It's the gold standard of standards.https://www.chromium.org/blink/launching-features/#launch-pr...
What I see is a lot of very sincere dedicated engineers coming up with helpful & rich ideas. Web Engineers seem to have enormous power to suggest & follow & drive forward ideas they seem to think are interesting. I see very few hallmarks signs of top down control. I see far more individual folks promoting & driving ideas, with blink-dev as a great testament to that bottom-up engineering spirit/mentality.
There's been an unmitigated use of Fear Uncertainty & Doubt, played with great effectiveness, against the top player. People keep ascribing to Google the role of platform-controller, like literally everyone else in history has done: IBM, Apple, Microsoft, all of which have used OSes to maintain control & dominance. Google is a search engine; they benefit from a rich healthy powerful competitive web. If Google did have "control" over the web, what would they do? What's the evil mastermind plan here?
Everything Google does goes through the Technical Architecture Group (TAG) and Security review. It's all open process. The checks are very real; even if no one can prevent them from implementing it would look very bad to disregard feedback, and thusfar they have not. Thusfar there seem to be extremely few examples of actual real scary things done. Web MIDI shipping without permissions was the most "egg on face" thing Google's done, and I have a hard time interpreting that as malicious. It has the hallmark of naively hopeful to me, and was easy enough to address.
The desire to see the browser teams as the enemy, as a foe, is a greatly harmful & reductive and alas popular outlook in my view. I don't think it's warranted, I don't think there's real evidence for it, and I stress again, Google has so far set the gold-standard for web standards accountability. They wouldn't have done that, they wouldn't continue that process, if they wanted to take control. The case here for taking-over seems absurd, has no clear outcome & only risk. Taking control is an existential risk, would jeopardize the web's success, could easily kill the Golden Goose that has made Google so wealthy & wise. People's fear here does not make business sense.
> Might be they'll replace actual websites with Google own version to keep people in Google controlled ecosystem?
This just shows that you don't understand AMP. Apple News replaces websites with only Apple News. AMP allows anybody to host the article.
> Or change APIs in their own nearly-monopolistic browser to make ad-blockers less efficient.
Only one browser has done this so far. It's Safari.
Google might not be a good actor, but trading it for a worse actor who won't let you use any other web clients is just cutting off your nose to spite your face.
Make money? That's what companies do. When they get too big and too powerful (at the point where governments don't really have serious leverage over them), a third-party should probably split them.
> Taking control is an existential risk
Why do you think big companies open source code? To help humanity? If Android (AOSP) was not open source, OEMs would probably not take the risk of depending on it. But the Play Services are there for the lock-in. Protobuf being open source is better for Google than having to integrate with other systems out there. Why is Chromium open source? Well most "alternative" browsers are based on it, and Google controls it. And so on. Open sourcing code is a strategic decision. And the strategic decisions in a company are there to make more money, not to help the world. It's all about control.
> What I see is a lot of very sincere dedicated engineers coming up with helpful & rich ideas.
Sure. Because you work for Evil Corp does not mean you are not sincere and dedicated. Many good people work for Philip Morris, for many reason (maybe they have an interesting job, maybe good conditions, whatever the reason). The difference with Google is that most Philip Morris employees probably realize that their company is not a non-profit aiming at making the world a better place.
Things like local hardware access require things like entitlements, ongoing consent, external accountability, and at least rudimentary protections from supply chain attacks - all things the web is historically bad at managing.
Web Extensions for an example have all been pushed into stores for auditing purposes, because otherwise their functionality can and has changed via automatic updates, going from useful functionality to horrible privacy trainwrecks.
> Sure, I agree, not every site should have access to these sensors/capabilities. There are privacy risks of turning them on. But they're also excellent capabilities, that really help users do interesting things.
Sure, but they are still harmful. For instance, there is no body that says which websites are allowed to manage USB because they are Arduino Maker sites dispatching firmwares, and which ones are not allowed to because they'll attempt to zero day some mobile phone OS while it charges. And there is no technical protection against the former site suddenly becoming the latter via acquisition or exploit.
This is why the native app security and privacy models are fundamentally different from the web models - a store can require entry into a private contract by a real-world entity who is accountable (potentially criminally), of software under audit control.
Websites can be by random people outside any legal accountability.
On iOS, one of the major differences is that there is no expectation that people will doing ongoing management of granted permissions to a website. For this reason, things like geolocation access have to be re-granted periodically. This is also a reason why push notifications (as a more durable permission) require the PWA to be "promoted" to an app on the Home Screen on iOS.
I don't have words to describe what a shockingly bad idea this is.
> A week latter Mozilla put out a similar PR using the exact same Fear Uncertainty and Doubt (FUD) to try to make themselves look good, to declare themselves virtuous non-implementors.
Maybe because it's a really fucking stupid idea, and the criticism of those APIs is not FUD.
No. They didn't get back to me in 2006 after I submitted a pretty cool coding challenge project to them as a part of interviewing, & we've had no contact to my knowledge since.
They did support me in Google Summer of Code before that (2005). I believe they gave me $5000 for the summer. I am still working to ship open source software pursuant to those ends, on my own personal time, to this day.
Someone's dislike of PWAs is irrelevant to whether or not someone else should be able to use them if they want to. It's also irrelevant when it comes to users who want to benefit from competition in the app distribution market. If you don't like PWAs, you're free to not use them, and you're even free to benefit from the improvements their competition brings to the whole mobile software ecosystem.
It's also ironic to bring up Apple's hindering of web standards as evidence of anti-monopolization of standards, considering the fact that the lack of PWA support forces users to use the proprietary App Store monopoly to install apps instead.
> If you don't like PWAs, you're free to not use them, and you're even free to benefit from the improvements their competition brings to the whole mobile software ecosystem.
IMHO, that's very naive. Look at ElectronJS apps. I hate ElectronJS, still the most used apps on my Desktop computer are ElectronJS. Why? Because I don't have a choice, because it's cheaper for the developers.
Before ElectronJS, I actually had real desktop apps. So yeah, I see the case against PWAs.
PWAs would be cheaper to develop overall than building 2-3 separate code bases. Which would mean more software available generally, particularly from bootstrapped companies.
I don't think anyone is suggesting that native go away.
> PWAs would be cheaper to develop overall than building 2-3 separate code bases.
But that's my point: that's exactly the promise of every single cross-platform system out there. But in my experience, that's generally not true for non-trivial apps (ever heard "write once, debug everywhere"?). And second, it usually makes for worse UX on all platforms.
I feel like many people consider PWAs as a totally new thing, but at the end of the day, it's a cross-platform system. There are tons of those; just look around, cross-platform is not a silver bullet.
> But that's my point: that's exactly the promise of every single cross-platform system out there.
Every non web cross platform system doesn't have nearly the investment as browsers do for quality and compatibility. It's not even close. Like, orders of magnitude. I don't like the cross platform toolkits either.
Let's not pretend the web as a platform is the same m'kay? People use it every day from all of these devices, like billions of people. This isn't some unknown, where this speculation is reasonable either. There are issues, but it's not equivalent.
My rule of thumb is that for any application that relies on an internet connection for most of its functionality, I'd rather just use a real web browser.
I am aware of that and I hate those apps, because those are worst of both worlds - it works as bad as any overcomplicated web app but they also have access to native apis and information that would be inaccessible through web browser (or at least be blockable)
I hate PWAs not because I like shitty native apps (it seems like it's not obvious, somehow).
I hate PWAs because I like good native apps, and PWAs give an opportunity for developers to replace their native app with a cross-platform web app. And in my experience, cross-platform generally comes at the cost of app quality on a single platform. Instead of hiring developers who know iOS, you now hire web developers who debug their web app on many platforms they don't really know well.
You’re so dead set on “winning” that you’ve completely talked past the point that was being made.
The commenter was not even saying that their point justifies Safari being the only browser engine available on iOS. They were making a specific point. If you don’t want to talk to that point, maybe try another thread.
Depends on your priorities. For people into standards and commoditization, PWAs are awesome because they reduce the ability of HW makers to differentiate.
For people who just want the best possible app/phone experiences, PWAs are awful.
For lots of use cases, you'd be unlikely to notice a difference in quality. For example, I tune my guitar using a PWA, and I doubt anybody would notice the difference.
The real differentiator with native vs pwa is their ability to track the user.
I didn't say they were perfect for every use case. I'm not a gamer, so I'll have to take your word for it. But look at your own phone. You really telling me most of your apps couldn't just be PWA?
Heavens no. I do not want to be forced to install an app for every single little thing - it's wasteful, detrimental to my security and privacy. Small examples from a recent trip: in Andalusia, there's a bunch of cities with very interesting old buildings (cathedrals, castles remaining from the Muslim era converted by the Spanish monarchs later on, etc.). Each and every one has a different app for their audio guide, map, etc. to help you navigate and understand them. It's just stupid, it's a one time thing and it could easily be served by a website; instead you have to download a 30-40 MB app for each one, and then remember to delete it afterwards.
> Apple's ban of all browsers but Safari turned out to be the main barrier preventing progressive web apps from being viable, deepening the duopoly power of themselves and Google, because Apple refuses to implement basic browser standards that are necessary for PWAs.
I don't know if this is substantially true. When I hear of PWA features that people complain about, they are almost always things that Google Chrome as its own app with its own web engine can't add to the underlying OS, such as:
- robust background processing
- background push notifications
- new video codecs (on a power-constrained device)
- system-wide protocol handlers
- web bluetooth/webUSB/webNFC
- adding their own new synthetic "app" representing the PWA to the Home Screen.
Many of the things people talk about with PWAs are not anything close to a web "standard" or even a recommendation - Google implemented them, because they were pressured internally to make a web-based programming environment for Chromebooks.
Is Apple a significant player in proposing new standards and working with say Mozilla to get consensus as a genuine alternative to Google or are they simply not implementing much? The latter is certainly my impression.
That may well be true, but in my view, upholding a native app monopoly for the sake of preventing a web browser one isn't a sustainable strategy (and never has been a conscious choice by anyone).
I think this has turned out to be the current barrier in preventing Google from completing taking over the web standards space.