> For support, the Progressive Web Apps will still need to be built on WebKit, with all that entails.
I wonder if there was some sort of back channeling with the EU to determine that “actually this is fine, we don’t care about rendering engine competition for PWAs, WebKit-only is better than removing them.”
The law ultimately only requires changes to features the EU cares about.
The notion that Apple was purposefully trying to kill PWAs never made sense in light of their significant investment in supporting PWAs over the last four years, down to recruiting industry rockstars such as Jen Simmons.
Nobody who was screaming bloody murder ever tried to reconcile that incongruence, much less succeeded.
What’s more likely is that Apple’s lawyers went with the most careful interpretation of the DMA, concluded that they’d have to facilitate Home Screen install for other browsers as well, figured it wasn’t worth the engineering effort, especially on short notice, and instead just deactivated it for Safari as well.
Then, after all the bloody murder that was being screamed about, the EU started to inquire[0] both with Apple as well as developers about the consequences for PWAs. Apple was told that their interpretation was too strict (or that they will be given more time to implement it for other browsers, but less likely because such decisions are typically made public) and that they’re fine (for now) with PWAs running in WebKit.
> in light of their significant investment in supporting PWAs over the last four years
Investing in PWAs for four years is only going to get you so far when you’re eight years behind the competition.
Obviously I’m making numbers up here but to my perspective Apple’s recent investments (bringing them to a level still behind competitors) has a lot more to do with staving off legal threats to their 30% cut on native apps (e.g. the Epic lawsuit) than any benevolence towards the web platform.
The cynical view would be that apple was only doing that to try staving off anti-trust litigation. The fact that PWAs are seriously crippled on iOS vs Android still seems certainly makes it appear Apple has ulterior motives. If you make PWAs not able to do everything a native app can do then you're incentivizing native apps.
Apple wants everything to go through their store. (1) so they can ban anything they don't like. (2) they can get their 30% (can't get 30% of websites)
I'd say this is not a cynical view at all, rather a quite realistic one.
They only added support for push notifications to iOS in 2023 (7 years after Firefox and 8 years after Chrome on Android), right after the UK regulator started its investigation in mobile ecosystems.
Yeah I’m not sure how that seemed to get lost in some of the revisionist history in the comments here but it at a minimum sure was a hell of a coincidence that they managed to not make any meaningful investments in supporting the web as a viable app platform right up until the moment that regulators started looking into it.
This is an important server, not some small anonymous fringe forum. The idea that various political games are not played and manipulated also here is dangerously naive.
Could be just die hard fans or current employees/investors, but... I've seen and read enough to know how these games are played by all relevant players. Again, this is too important and trivial to infiltrate place to ignore by many many players. Sure mods can remove outright lies but the key is in subtle ways crowds can be manipulated via ie direct attack on negative emotions, or mildly revisioning history one step at a time.
Given the number of comments trying to find the craziest justifications for a giant corporation just attempting to break a law, silently kill thousands of apps used by millions of users, destroy businesses and kill the only open and free app distribution platform competing with their closed and taxed one, there is indeed very little doubt that a lot of people here have a vested interest in Apple.
Of course, Apple $1B legal department thought they had to kill web apps to conform with the DMA whose purpose is to open iOS to competition. Sure ;)
>I think it was saying that if Apple wanted to kill PWA it would have made more sense to just not make those investments over the past four years.
wrong, Apple only started implementing the bare minimum because they felt the heat from devs & feared the legal consequences for their anti-competitive behavior.
Apple still has the unquenchable desire to kill PWAs, they will just keep sabotaging them more subtly. Apple will keep up their shenanigans until the bitter end, but I hope that the EU will have none of it.
Yes… and what I was saying in my response is that even if Apple did want to kill PWA there is good legal reason to have made the investments they have in the past few years. In court they can argue that app makers are free to make a PWA if they don’t want to pay the 30% cut. If they removed PWA support they’d not be able to make that argument.
I'm pretty sure that no single person can code a modern web browser by themselves in 4 years. Even just rendering and layout alone is insanely complex with modern CSS. And then you need a decently fast JS interpreter (which means JIT these days - and web apps do assume that kind of perf), and Wasm, and canvas, and ...
> Investing in PWAs for four years is only going to get you so far when you’re eight years behind the competition.
I don’t think this speaks to intention, the investments that have been made and are still being made bring with them a cost, both in a monetary sense and in other ways. Regardless of the separate question with regards to them having been able to catch up with the competition.
A generous interpretation, with the presupposed premise that they haven’t been able to catch up, could say that it warrants a more favorable interpretation of their intentions if they were willing to invest after having lagged behind for so long, because the required investment would be greater and the pay off less clear.
> (bringing them to a level still behind competitors)
Let’s be honest here. When people say something like this, they’re mainly thinking of Chrome/Chromium-based browsers.
Google is known to have no qualms supporting certain things that both Mozilla and Apple are uncomfortable with, while at the same time implementing a bunch of stuff that isn’t standardized.
On the whole, Safari/WebKit has roughly met Mozilla’s level of support for frameworks and APIs and even surpassed Mozilla on certain things (especially desktop). Of course if the benchmark is just Chromium, then none of it will ever be enough, then again, Mozilla doesn’t seem to catch a lot of flack for drawing a line in the sand in terms of support.
Other than that, Safari seems to be doing great on test suites/benchmarks that focus on progress such as the annual Interop. Consistently[0] keeping up[1] over the years[2], and sometimes coming out on top[3].
> has a lot more to do with staving off legal threats to their 30% cut on native apps (e.g. the Epic lawsuit) than any benevolence towards the web platform.
I tend to stay clear with attributing maleficence or less than generous intentions without something substantial to back it up. Especially when behavior seems to contradict such attributions.
For example, if that where the main motivator then I’d expect a bare minimum approach and Apple dragging their feet, like we see with DMA implementations (e.g., only allowing what must be allowed in the EU instead of globally), instead we not only see improvement of PWA support, in part beyond what Mozilla supports, but also direct contributions of standards that PWAs rely on in the form of improvements..
On the flip side, I think past actions are a better indicator of intent than assuming good intent.
Having a closed ecosystem has been baked into Apple's DNA since day 1. Not just software, but even the hardware was sealed to prevent modifications to the hardware in an age when upgrading and modding PCs was the norm.
Over the past few decades there have been a lot of changes at Apple, but preventing user customization has been intertwined with their design-first philosophy. It seems naive to think they are doing anything but the minimal required action to maintain their hermetically sealed ecosystem.
> What are some examples of standards-track features that they implement that Apple doesn't?
Lack of any obvious method to actually install a PWA is probably the biggest blocker to PWA adoption today. They aren’t yet a web standard but citing standards always feels like a very convenient argument: there are a great many web features implemented by most browsers before they become standards. Multiple implementations are often part of the standardisation process.
When iOS finally implemented Web Push they gated it to only apply to Home Screen installed apps and those who defend Apple lauded the decision. Yet there’s absolutely no mention of that behaviour in web standards. Apple, like every browser creator, takes web standards as advisory and implements the parts they want, in the way they want.
This makes absolutely no sense. It came out in the Eoic trial that 90% of App Store revenue comes from games and in app purchases.
Those apps are no more going to leave the App Store and go to the web than they are going to leave the Google Pay Store. In app purchases monetize too well and people aren’t going to put their credit cards on every third party website.
That’s not even to mention all of the ways that you can pay via in app purchases that you can’t pay via the web and all of the kids with phones without credit cards attached.
If it’s only Apple, then why aren’t Android developers creating great PWAs to escape the same 30%?
I don't really understand the rest of your argument. "Of course developers aren't going to use the web instead of apps, it's a way worse experience!" is precisely the point in criticizing Apple letting the web platform languish. They have a vested interest in making sure the in-app experience remains superior to web experience because of their 30% cut.
If it’s just Apple, then why aren’t developers leaving Google Play Services in droves to avoid the same 30% cut?
And Microsoft did that not because they didn’t want to be in the store, but because at the time Apple wouldn’t allow them. Yes I disagree with this.
If PWAs could be made one to one with apps - and today games like Candy Crush could be web apps - game developers who make up 90% of App Store revenue still wouldn’t give up the direct access to users wallets they get from in app purchases.
If PWAs were on par with native feature-wise, why couldn't they have single-click in-app purchases? All you'd need is some large trusted platform to provide a single sign-on experience and process payments.
“No one wants to use the web because it lacks the centralized payment processing”
“If PWAs were fully featured a third party could offer that”
“Why do you think people sell on Amazon?”
The last statement has little to do with the two preceding it. We all understand the strength of a centralized payment system. Amazon themselves already offer Amazon Payments. That could absolutely be an alternative to in-app purchases. Except Apple wouldn’t get their cut, so they don’t want that.
The correct answer here is to let the market decide. If I’m willing to trade 15%/30% of my revenue for an easier purchasing flow I can do that. But if I’m willing to tolerate more friction for a lower cut I should be allowed to do that too. But App Store rules expressly forbid that. The web could be an alternative but Apple has a vested interest in under developing it.
Where hard to understand? You don’t have to sell on Amazon and deal with their commissions but people do.
A news website doesn’t have to allow Google to crawl them since they complain that Google takes their ad revenues - yet they do.
And Apple would get no cut if Candy Crush were on the web and even the cut they would get from using Apple Pay (not in app payments) are standard credit card payments.
But kids who probably don’t have access to credit cards still can use in app payments along with people who don’t have credit cards at all who can use Apple gift cards. I gave up a reliable reference from a well known analyst about Aggregation Theory.
Outside of the App Store, parents aren’t going to give their kids unfettered access to their credit cards compared to parental controls that are available within the App Store.
If so many developers are in such a hurry to leave the OS providers App Store, then why don’t the same developers leave the Google Play store where it is allowed?
How did that work for Epic with Android?
The fact is that game developers - who make up 90% of App Store revenue according to data that came out during the Epic trial - complain about the 30% cut. But they want access not only to Apple’s customers but also to in app purchases so they can use every psychological trick to take advantage of the whales.
Neither Google nor Apple care about the Indy developer and the little revenue they make.
Are you fighting for the independent developer or the slimy pay to win game developers?
I think my previous comment was very clear: developers should get to choose. If they want to pay a high commission for easy payments they should be able to. If they want to introduce greater friction for a lower cut they should be allowed to do that too.
Apple expressly forbids this in native apps. If the PWA platform were more viable it would offer this choice but it isn’t, an Apple has a vested interest in things staying that way. At the very same time they defend their restrictions upon native apps in court citing the web as an alternative platform. It’s very convenient.
Okay, developers can choose on Android. Yet to a first approximation, all of them still use the Google Play Store, why is that?
If it’s only mean old Apple stopping developers from using PWAs, then why do Android developers still use Google Play services instead of PWAs, alternate app stores or direct downloads? All of which are available?
Candy Crush - still one of the most profitable games in the App Store is not graphic intensive and could be done on the web today and use Apple Pay (normal credit card charges), why don’t they?
Because Candy Crush relies upon being an impulse purchase. If people had to go through five steps to buy it a ton of people would abandon it.
That isn’t the same for every app. There are plenty of apps folks would be happy to go out of their way to purchase because they provide a ton of value. But the developers are not allowed to.
Again: my argument here is choice. Let developers decide. Your counter is “but one of them is better”. You’re entitled to your opinion but that isn’t a counter argument to letting developers choose what type of payment system they want to use. Apple does not let developers do that and they should. There’s really not much more to the debate than that. If, as you argue, Apple’s ecosystem is better in all aspects then it will win out in a free market. What’s not to like?
Not to mention that "the app store is a better ecosystem because it's easier for kids to impulse-buy in-app purchases from scammy games" is a heck of a take.
If mobile games are sticking to the app store purely because the purchase model on the web discourages impulse buys, that is a strong argument for investing more time and resources into the web as a platform and pushing more apps in that direction.
"It's easier to monetize children" is not an argument in the app store's favor, it's an indictment on Apple's payment UX and parental controls. Presumably in this theoretical world, the only thing keeping Candy Crush off of the web is that he web isn't exploitative enough. Which... again, just a weird argument for anyone to make if they're arguing that the app store is the best solution for everyone. Everyone except users apparently.
I’m saying that it isn’t logically that Apple is keeping PWAs from becoming more popular because today most of the revenue wouldn’t leave the App Store because it comes from pay to win games.
On the other hand I’m saying today Android developers could move from Google Play and not have to pay the “Google tax”. But they don’t. Why not?
Also if it is only Apple holding PWAs back, then why aren’t PWAs a popular way to escape the “Google tax”?
It must be that Android developers think 30% is worth it.
Because PWAs lack substantial capabilities that make them impossible to use for most app development. Which is what everyone has been saying.
Note that developers do move out of the Android store, there are a host of applications available on F-Droid that are not available through the Android app store even though discoverability on F-Droid is nonexistent. But those developers don't build PWAs, because PWAs are not a viable platform for building modern apps.
It has nothing to do with the 30% being worth it or not and everything to do with the fact that moving away from the app store on both Android and iOS is really only theoretically possible -- and PWAs in every practical sense can't actually be used to avoid the tax.
You bring up Candy Crush above as an example of an app that could be a PWA. It couldn't. PWAs lack reliable storage mechanisms, unless Candy Crush starts requiring online accounts it's not going to ship as a PWA. Meanwhile, the last "big" app that tried to go down the PWA route was Wordle, which was both difficult for users to install and was immediately swamped with fraudulent clones in the app store claiming to be the official apps, which neither Google nor Apple did anything to stop.
Once the NYT purchased Wordle, one of the first things they did was add an online account system -- in part to mitigate the common data losses that were present in the PWA. Wordle is the best possible candidate for a PWA, and the NYT is still struggling with it. I would not be surprised if at some point they don't turn it into a native app.
It's not that the payments are worth 30%. It's that going outside the app store (even when you're not collecting any payments at all) isn't viable. Which is what everyone has been saying all this time.
Exactly what is stopping King from having an online account or just having “login with $x” where $x is Google/Apple/Facebook? You act as if creating an online account is a big barrier to entry.
I can set up a scalable online account in literally a couple of hours that allows login with third parties like the above with Cognito, Lambda and DynamoDB. It’s not a heavy lift. Yes I’ve done that at scale.
> Exactly what is stopping King from having an online account or just having “login with $x” where $x is Google/Apple/Facebook?
Privacy, security, convenience and the fact that it's a #$%&ing terrible user experience. Nobody wants to log in with Facebook every time they play a video game. I mean, heck, you're on here arguing about user privacy, and your solution to that is that more user data should be stored in the cloud? Come on.
King does appear to have online accounts for at least the people who want them[0]. I would argue a lot of people probably don't want them.
----
[0]: Or at least did at one point, a "quick Google search" shows that King did at one point make its games available online and was forced to abandon that platform in 2020 due to (in their words), "changing web-based technology on major browsers". Seems like that suggests something about PWAs as a viable alternative to the app store, but whatever, I'm sure it's just a coincidence and we definitely shouldn't conclude anything from it other than that King loves forking over that 30% /s
> Privacy, security, convenience and the fact that it's a #$%&ing terrible user experience. Nobody wants to log in with Facebook every time they play a video game. I mean, heck, you're on here arguing about user privacy, and your solution to that is that more user data should be stored in the cloud? Come on.
You mean like no one wants to log in with Steam, or their console? You realize that everyone on mobile is already logged in to an account where there game data can be saved an automatically synced right?
> King does appear to have online accounts for at least the people who want them[0]. I would argue a lot of people probably don't want them.
Since most people play on mobile, King didn’t need a separate online account, between saving in Game Center and just saving locally and letting iCloud taking care of the backups and online sync they didn’t have to.
> You mean like no one wants to log in with Steam, or their console? You realize that everyone on mobile is already logged in to an account where there game data can be saved an automatically synced right?
Do you not realize that people use consoles offline? Or that every single platform that you're talking about has options to disable online saves? Or that there are multiple platforms like the Switch which straight-up don't sync every game's data and keep a number of games purely clientside?
Yes, people care about offline storage. They just do, I guess congratulations if you're one of the people who magically don't have to care about that, but lots of people do.
Syncing is nice, but it does not get rid of the need for reliable offline storage. Every single platform -- literally every single one, including iOS, understands this and has mechanisms to allow users to keep data local. Literally every single one. Did you know that consoles like the base PS5 don't even require an Internet connection at all in order to play games? Not only do you not have to sync your saves, you don't have to use the Internet at all.
Because some (not all, but enough) users care about this, and every single major games platform from iOS to Android to Steam to GoG to Itch to Windows to Mac all understand this and have all put resources into making sure that their platforms and distribution services work without requiring background sync or cloud storage.
I will of course note that we have entirely moved away from the privacy argument. Your earlier claims about web privacy sound extra-nonsensical when viewed through the light that your solution to storage is to upload literally all of everyone's data to the cloud. But whatever.
> Since most people play on mobile, King didn’t need a separate online account, between saving in Game Center and just saving locally and letting iCloud taking care of the backups and online sync they didn’t have to.
Which is not available to PWAs.
If you keep saying the same things over and over again, I'm going to keep giving you the same replies. PWAs can not save in Game Center, Game Center is irrelevant to any conversation about what King can and can't store in a PWA.
If you want to store data in PWA, that does require a separate online account. And as I've said elsewhere, even that is not really a solution and you're still going to need to worry about data loss.
Local storage is not the answer. It’s the expectation in 2024 that you should be able to use an app across devices and keep your state. And you act as if setting up accounts on a server is hard. It’s literally a CloudFormation template with Cognito, Lambda, IAM and DynamoDB.
Yes, I’ve done it at scale and yes it’s that easy.
> It’s the expectation in 2024 that you should be able to use an app across devices and keep your state.
Device sync is a solved problem on quite literally every single major platform, including iOS. There's no reason Apple couldn't sync PWA storage using the same mechanisms.
> And you act as if setting up accounts on a server is hard.
It objectively increases attack surface, decreases privacy, adds user friction, and is unnecessary for the majority of apps. Most users (myself included) don't want online accounts. I don't need an online account for an alarm. I don't need to log in with Facebook or Github or whatever just to do basic things on my phone.
This is just unbelievably silly at this point. Of course reliable offline storage matters for app development, are you seriously going to try and argue that it doesn't? If Apple got rid of reliable offline storage for native applications, nobody would say that didn't matter or that it wasn't a big deal. Some of us actually like that we can do things like type into a text editor and know the text document will still be there when we come back to our computers, and that it doesn't have to get synced to somebody else's servers to guarantee that.
The solution to app storage is not to completely abandon privacy, require an Internet connection for every app, and then put all of our information on somebody else's server.
Every single app on the App Store gets device sync for free via iCloud.
I can drop my iPhone in the ocean, buy a new iPhone and and my new iPhone will have all of the data that my old iPhone had within the last 24 hours.
How exactly do you do “device sync” without an account somewhere?
> It objectively increases attack surface and is unnecessary for the majority of apps, and most users (myself included) don't want one.
Because for the majority of users - they don’t need a separate account because all of their state can either be saved by the app just saving locally and letting iCloud take care of it. By logging the state in Game Center or some apps like Overcast use the users app specific iCloud token (each app gets a unique token per user not shared across apps) and stores state server side.
I can guarantee you that most users expect to have everything backed up automatically and expect to be able to move between devices.
> Some of us actually like that we can do things like type into a text editor and know the text document will still be there when we come back to our computers, and that it doesn't have to get synced to somebody else's servers to guarantee that.
That must be why no one uses Google apps so their data is accessible across devices, Office 365 and why Chromebooks are so unpopular because people don’t like cloud backup….
> Every single app on the App Store gets device sync for free via iCloud. I can drop my iPhone in the ocean, buy a new iPhone and and my new iPhone will have all of the data that my old iPhone had within the last 24 hours.
Do PWAs?
Like holy crud, it's like you're not reading anything I'm saying. This is what everyone is telling you, PWAs lack critical capabilities. And you keep saying, "no, it's fine, why don't they just [insert capability that isn't available to them]."
> Because for the majority of users - they don’t need a separate account because all of their state can either be saved by the app just saving locally and letting iCloud take care of it. By logging the state in Game Center or some apps like Overcast use the users app specific iCloud token (each app gets a unique token per user not shared across apps) and stores state server side.
Which isn't available to PWAs.
> I can guarantee you that most users expect to have everything backed up automatically and expect to be able to move between devices.
Which isn't available to PWAs.
It's not even available to PWAs that do use an online account. iOS has unreliable background sync for PWAs, so if you use a PWA without an Internet connection, you can't rely on that data getting synced in the background once you do get an Internet connection. You have to remember to re-open the app to make sure that the sync happened.
> That must be why no one uses Google apps so their data is accessible across devices, Office 365 and why Chromebooks are so unpopular because people don’t like cloud backup….
I'm sorry, are you seriously going to try and argue that users don't care about the ability to have offline storage? This is unbelievably out of touch.
This must be why nobody complained about Windows requiring a Microsoft account to install, why nobody uses Sublime or Notepad because they don't have online accounts, why nobody ever downloads DRM free games, and why nobody uses a computer offline /s
It's just absurd. Of course users like having the option of reliable offline storage. The inability to integrate with iOS backup and the inability to store data reliably without an internet connection and a separately managed user account or online storage service is very, very obviously a barrier to using PWAs for serious work.
If Apple turned iOS into a Chromebook-style service tomorrow, everyone would be up in arms about it. Most Apple users don't want that. And in fact, even Apple devices do not require an Apple account to use because Apple recognizes that having that be optional is important to users.
> Do PWAs?
Like holy crud, it's like you're not reading anything I'm saying. This is what everyone is telling you, PWAs lack critical capabilities. And you keep saying, "no, it's fine, why don't they just [insert capability that isn't available to them]."
No “everyone” is saying that mean old Apple is keeping PWAs back because they don’t support some web spec. Which web spec is there that Apple should be supporting where cross device sync of local storage is possible?
> Which isn't available to PWAs.
Which spec is Apple not supporting that would make that possible?
> I'm sorry, are you seriously going to try and argue that users don't care about the ability to have offline storage? This is unbelievably out of touch.
No you were saying that users don’t care about device sync and would be happy with only local storage.
> This must be why nobody complained about Windows requiring a Microsoft account to install, why nobody uses Sublime or Notepad because they don't have online accounts, why nobody ever downloads DRM free games, and why nobody uses a computer offline /s
And since we are talking about mobile devices that get left in cars, dropped in the ocean, stolen etc. cross device sync and automatic backup that’s been available since 2010 is kind of the norm.
You really think more people are using Sublime text than Office365, Google docs, and even notes on Macs?
You have heard of services like Dropbox, OneDrive, Offive365 etc haven’t you?
And BTW, the notes app on Mac also automatically syncs between my Mac, iPad and iPhone - yours doesn’t?
> It's not even available to PWAs that do use an online account. iOS has unreliable background sync for PWAs
Apple restricts background processes for all third party apps to save battery life. It’s been this way since 2010.
> And in fact, even Apple devices do not require an Apple account to use because Apple recognizes that having that be optional is important to users.
You really think iOS users don’t have iCloud accounts? Have you actually ever tried to use an iOS device without an account?
You realize that Apple’s equivalent of Google Docs - the iWorks suite has synced across devices since 2010 don’t you?
> Because Candy Crush relies upon being an impulse purchase. If people had to go through five steps to buy it a ton of people would abandon it.
But this does apply to apps that make up 90% of the revenue on the App Store. These aren’t numbers I’m making up - it came out in the Epic trial.
But even if that’s not the case for the other 10%, the same would apply for the App Store that applies for Amazon in the real world. Smaller merchants still choose Amazon for the conversion and that’s where the customers are when literally anyone can sell from a Squarespace website.
> Again: my argument here is choice. Let developers decide. Your counter is “but one of them is better”. You’re entitled to your opinion but that isn’t a counter argument to letting developers choose what type of payment system
And that’s the issue - everyone wants to use Apple’s App Store and have their own payment system not avoid the exposure they get from the App Store.
Once again, on Android where you can in fact tell users to go outside of the Google ay Store - hardly anyone does.
Every Indy developer thinks their little app will be special and they would be okay outside of the App Store. If they can’t even gain traction within the App Store what chances do they have of gaining traction outside of it? It’s not the 15% cut that’s keeping them from succeeding - small developers aren’t paying 30%
> And that’s the issue - everyone wants to use Apple’s App Store and have their own payment system not avoid the exposure they get from the App Store.
But why would it be an issue to be in the App Store and provide your own payment option? Why not just let developers do that and let the market decide? I’ve asked that about four times now and you still haven’t actually explained why.
So you want to use Apple’s marketplace and still not pay Apple? Can you put your goods in any other marketplace and not pay the market place owner in the real world or digital?
If you want the “market to decide” force Apple to allow other app stores and you can let other app stores compete on price like the DMA demands.
Can you distribute on Steam and not pay Steam? Can you do that in any physical store?
Your argument is now a completely different one than it was when the thread started.
If the argument is “you should have to pay to be in the App Store”, sure, I don’t have any problem with that. But “fee to exist on the App Store” being 15-30% of every transaction is absolutely egregious and completely out of line with any real world cost. And in any case Apple already charges a $100/year fee to be able to put apps in the App Store.
But, yet again, Apple charging that amount would be more acceptable if they fully supported the web as an alternative platform for those who do not care for the App Store exposure. But they do not, because it is in their interest to funnel everyone through the App Store and take a cut.
And looking at Android - those people who are willing to forego the mobile providers App Store are just as unwilling to do it as merchants are unwilling to do it.
That $100 is absolutely nothing. Can you get on any console, Steam, or any physical marketplace just by paying $100 a year?
Can I put my music on Spotify by just paying a one time $100 fee?
Can you name one other platform that charges less than 15/30%? Once again if it is egregious, why do the same app developers voluntarily put their apps on the Google Play store when they do have a choice?
Why do artists allow their music to be on Spotify where Spotify gets 30% of the revenue?
As a reminder, both Android and Amazon are being investigated for antitrust, and part of that complaint for Amazon is that they utilized an algorithm called Project Nessie to raise prices across the web for consumer goods even on 3rd-party storefronts: https://fortune.com/2023/11/02/amazon-algorithm-raise-prices...
These are maybe not the shining corporate examples you want to compare Apple to.
Google is being sued because they sold the idea of “freeduhm” and then changed the terms. There is plenty of precedence for this. This is why they loss thr Epic case and Apple won a similar lawsuit.
But how is what Amazon doing any different than what the corner store does when it raises and lowers gas prices based on competition?
And before you accuse me of being an Amazon apologist, I’ve mentioned plenty of times that I got Amazoned last year. I have no love loss for the company.
In particular, the FTC is interested in Amazon's pricing requirements which prohibit sellers from offering products at lower prices through other storefronts, its bundling of services like Prime which require sellers to buy unwanted fulfillment services in order to obtain unrelated placements in the Amazon store (and force Prime users to essentially pay twice for shipping if they order products outside of Amazon), and its privileging of discoverability for Amazon's own products and for paid advertisements over products that the FTC alleges Amazon knew were higher quality and better rated than the results it surfaced to customers.
The FTC's complaint describes this as a self-reinforcing feedback loop:
> Because Amazon suppresses meaningful competition on price and product
selection, shoppers lack viable alternatives, further forcing sellers to submit to Amazon’s
exclusionary tactics to reach those customers, and further allowing Amazon to accelerate and
expand its dominance. Together, Amazon’s conduct blocks off competition, shopper traffic, and
seller business in the interrelated relevant markets.
In other words, the more that sellers become dependent on Amazon, the more that shoppers become dependent on Amazon since goods and services are not available on other storefronts. This in turn makes sellers more reliant on Amazon since buyers become even harder to find off-site. Which in turn makes sellers more reliant on Amazon, and on and on.
This has the effect of killing off 3rd-party storefronts since they are faced with a chicken-and-egg problem of trying to attract both sellers and buyers at the same time, and neither group can move off of Amazon individually without suffering financial penalties or losing product placement.
That kind of argues against everything you are saying. Sellers do have a choice today of selling on their own websites. But they get benefits of selling on Amazon. Just like low graphics games like Candy Crush could make web apps today yet they find enough value to be in the App Store despite the 30% cut.
A quick Google search shows that Amazon only has 40% of e-commerce.
> A quick Google search shows that Amazon only has 40% of e-commerce.
Tell it to the FTC. Their position is that sellers do not have a choice of whether or not to abandon Amazon, at least not without suffering severe consequences stemming from Amazon's anti-competitive behavior.
Go ahead and write them a letter explaining that Amazon has 40% market share if you think they're somehow not aware of that fact. I'm not in charge of who the government sues.
---
Look, I'm not here to debate the entirety of antitrust as a concept. You can disagree with the FTC, Amazon obviously does. I'm just telling you that if you compare Apple to other companies that are also being investigated for antitrust, a lot of people are going to say, "yeah, you know what, Apple is like Amazon, which is also an anticompetitive company that uses bundling and abusive seller terms to squash competition while mimicking seller products in-house using seller data and then downranking competing products in search results to steal customers. You're right, Apple is acting like Amazon."
You can disagree with antitrust decisions, but you're not arguing from a place of strength when you say that Apple isn't anticompetitive because they're just mimicking [insert anticompetitive company] :)
----
> Just like low graphics games like Candy Crush could make web apps today yet they find enough value to be in the App Store despite the 30% cut.
If this was true, free and Open Source applications or applications that monetized through advertisements exclusively would more often launch as PWAs and avoid the app store. But they don't, because it's not true. There are plenty of applications that don't rely on scammy impulse buys for in-app purchases in order to monetize. They're still on the app store.
It's not that the App Store provides value, it's that PWAs are not a viable alternative.
> Well, if you haven’t been paying attention, the FTC hasn’t exactly been batting 1000 when it came to their lawsuits against BigTech…
Meh, they've been doing decent. The current admin is pushing antitrust in a way that we haven't seen since the early days of the Internet, and I'm excited to see where it goes. The last time the US pushed antitrust this hard we ended up with one of the biggest booms of innovation in the history of the Internet.
> So the App Store doesn’t provide value except for having features that app developers need that provide value?
By this definition, literally every single monopoly "provides value". Seriously, what's going on here? You're bouncing all over the place. You go from, "Apps can launch PWAs and they just don't because they need easy monetization, and the fact that the App Store provides easy access to predatory monetization schemes is somehow something to be lauded", to "okay, apps can't launch PWAs and that's even more proof that the app store provides value, because restricting APIs to a specific storefront is a value proposition somehow". This is nonsensical.
At least now it sounds like we're both finally agreeing that in-app purchases through an Apple ID are not the only reason why PWAs aren't more popular, and there are actually limitations at play here?
But also, no, Google and Apple both holding back the web as an app platform is not the same thing as providing value to developers. This is getting silly. If I construct a dam in front of the local river, drain the aquifers, and then starve everyone of water and start selling bottled water for $10 a pop, that doesn't make me an innovator, it makes me a parasite. Which is, again, what everyone has been saying about the companies involved (both Apple and Google, I need to apparently specify that since you have trouble believing that 2 companies can be bad at the same time). When Google and Apple hold back capabilities from the web in order to force developers into unwanted contracts, that is predatory behavior.
You started this out by asking why devs don't launch PWAs and positing it was because the app store provided an easy monetization model that was worth 30%. In actuality, the reason is because PWAs can't be used for serious app development regardless of how they monetize. Apple could port the App Store's IAP system fully to the web, and these developers still wouldn't be able to use PWAs. Apple has claimed that they can; Apple has repeatedly made the claim that PWAs are a viable alternative to the app store. But they're lying. Factually, observably lying. PWAs lack critical capabilities that are available to native applications, which makes them a non-serious alternative to the app store.
Coincidentally, these are capabilities that Apple and Google are able to hold back because of their collective dominance over the browser space and their use of (in Google's case) default browser placement and anticompetitive promotion which makes Chrome the defacto standard of what is and isn't supported, as well as direct interference with web standards (see Notifications), and in Apple's case by outright blocking capabilities from the iPhone that would neither harm security or privacy (app badges, reliable offline storage, etc...).
Which is what everyone has said a dozen times already, and you keep dancing around the point even though you've so far come up with zero arguments against it except to confidently assert over and over that it's all fine.
This is a difficult point to get across because you don't seem to have a really concrete idea of what anticompetitive behavior is. Apparently forced bundling, price fixing, vertical integration, etc... don't count in your eyes as anticompetitive behavior. Thankfully, both the FTC and Europe disagree, the current administration has been historically good about antitrust (although there's obviously still a long way to go). And hopefully, the courts will agree as well. Certainly Europe does not appear to be buying the arguments that Apple pushed in American courts, and even in American courts, the renewed interest in going after Google might lead to followup scrutiny of Apple's very similar positions that were dismissed before.
----
But none of this changes anything about your claims:
> But they want access not only to Apple’s customers but also to in app purchases so they can use every psychological trick to take advantage of the whales.
No, the situation is more complex. It's not only Apple's payment methods that keep people in the store.
> Okay, developers can choose on Android.
No, they can't. Android has many of the same PWA limitations that iOS does, and Google has gone out of its way to make it hard to access alternative stores and to punish distributors who load alternative stores. This is part of the lawsuit against them. "But what about Google" is not a convincing argument in favor of Apple's behavior.
> Local storage is not the answer.
Yes, it is part of the answer, consumers expect reliable offline storage in addition to cloud syncing, neither of which are available in a reliable way for PWAs. It's kind of my mistake for allowing you to focus in on local storage so much as well, since the reality is that both local storage and synchronization are borked for PWAs on iOS.
So you're wrong that local storage doesn't matter, but also PWA storage would still be broken anyway even if we were only talking about online storage.
> Because for the majority of users - they don’t need a separate account because all of their state can either be saved by the app just saving locally and letting iCloud take care of it.
No, they can't, not with PWAs.
You keep repeating the same things over and over again, and they're just not true. And you can keep looping through them and coming up with new ways to push the same ideas (apparently now Apple and Google holding back the web is evidence for the App Store as a competitive platform? Sure, whatever, that's very convincing /s), but it doesn't change anything about the provably incorrect things you've said to get to this point.
That's a good question: Apple has argued in court that PWAs are a serviceable alternative to the app store.
So why aren't developers using them? Is Apple wrong? Are they not a serviceable alternative to the app store?
Android has better support than iOS, and Android's userbase spends less money on apps and is more often monetized through ads. So it's not the payment platform that causes developers to avoid PWAs, otherwise they'd be used all over the place on Android.
Android also has a semi-thriving community of Open Source applications through F-Droid that are privacy preserving and completely non-monetized. But installing apps through F-Droid is complicated. And F-Droid has zero user reviews. So it's clearly not the ease of delivery or advertisement that's causing those developers to ship native apps that need to be sideloaded through a complicated process that involves going into your phone settings and turning on sideloading instead of just shipping web apps.
So what's left? Well, invasive apps like Facebook/Twitter could ship as PWAs (with the caveat that their notification support would be worse). But they'd be giving up tracking ability by doing so. Web browsers are better secured than phones are. Facebook on iOS has an easier time tracking your behavior than Facebook in Safari does. Facebook on iOS could even at one point (and might still be able to, I can't find a source that this is patched) push custom code into web views of other articles through its iOS native app. So yeah, they're obviously interested in shipping an iOS app because (frankly) the Safari team is better at security than Apple's iOS developers are.
The only reason left that explains that behavior is the fact that PWAs on both Android and iOS are severely lacking in APIs that would enable anything other than shallow internet-connected services. They are not alternatives to the app store in their current state, no matter how much Apple pretends otherwise. Notification support on Android for PWAs is a joke, it's basically only usable for advertisements. And it's even worse on iOS. If you want to make an alarm app as a PWA, it is literally impossible to do that reliably. Want to make an RSS reader? I have no clue how that would be done as a PWA, I don't think it can be done without a web server handling the article fetching.
----
And I'm sure you would say at this point that there are tons of apps that don't need this stuff and that really it's not about capabilities it's about payments and about what the users want and where they look for apps...
And I would just repeat your question back to you -- there are a ton of apps that are not monetizing through app store payments that aren't shipping PWAs. There are a ton of apps that are not looking for mass-market appeal that are not shipping PWAs. And Apple is arguing in court that they could. But they're not. They're not using PWAs on iOS or on Android. They're not shipping PWAs when they rely on advertising. They're not shipping PWAs when they would benefit tremendously from not needing to pay so many commissions to Apple. Even when they're Open Source and don't monetize at all, they're not shipping PWAs.
Why not? What do those developers know that Apple either doesn't know or is pretending not to know? There's no NewPipe for iOS shipping through Safari. Why is that?
I do want to encourage people to use Facebook/Twitter via their mobile browsers instead of through the native apps. I worry a little bit re-reading this that it sounds like I'm saying they're unusable, and no, they're not, and you should use them on the web.
Yes, you'll miss out on features like reliable message notifications, but it's mostly fine. Do not install Facebook on your phone.
In that case, if PWAs were good enough on Android and they could avoid the 30% cut, why bother making native Android apps at all?
All of the HN commenters blame mean old Apple for holding the web back. But the fact is that every mobile platform at one point announced that “you can make good apps using web technology” - Apple, Google, Microsoft, Palm, and RIM. They’ve all sucked
Even before then, Sun promised that you could make great cross platform GUI apps and they sucked.
Today Electron apps are, battery draining, memory hogging monstrosities.
And the tracking thing is a non starter. You have much better ways to track on the we then through native apps - at least on iOS with a much better permission model.
To the first approximation - no one cares about PWAs - not users, not companies.
> In that case, if PWAs were good enough on Android and they could avoid the 30% cut, why bother making native Android apps at all?
I don't want to skirt too close to HN guidelines here, but I'm genuinely curious if you actually read my comment or not.
This is exactly what I asked you. If PWAs are (as Apple claims) good enough alternatives to the app store, why isn't anyone using them?
You can complain about Electron, but developers build Electron apps. They don't build PWAs. Because Electron apps are actually a feasible alternative to more native GUIs, and PWAs are not. The question you and I are asking (why isn't anyone using PWAs) reveals exactly how bullcrap Apple's legal arguments about PWAs are. They are not reasonable alternatives to the app store.
> All of the HN commenters blame mean old Apple for holding the web back
I don't blame Apple exclusively for holding the web back. They're a part of it, but so is Google. I don't think I've ever had much good to say about Google on here, and as the US and EU are actively proving right now, it is possible to pursue regulation for multiple companies at the same time.
> You have much better ways to track on the we[b] then through native apps - at least on iOS with a much better permission model.
This is not true by any metric. Native apps have more access to fingerprinting vectors than web apps do, are capable of requesting deeper levels of user information like contacts. Native Facebook on iOS got called out for injecting custom code into the in-app web view when users clicked on links within Facebook for 3rd-party sites. That's something that's not possible to do in any modern web browser.
Native apps are indisputably easier to use to fingerprint and track users on both iOS and Android.
Even if you're unfamiliar with the technical side of this, you can still think of it this way: if apps like Facebook had an easier time tracking you on the web than on mobile devices, they wouldn't try to get you to install mobile apps. They would force you to use the website. The reason why Facebook ships an iOS app is because it is easier to track you via iOS than through the Facebook website.
I’m very familiar both - exactly how can apps track you - without your permission that the web can’t?
And your example of how Facebook can track you by knowing what links you clicked on off the site from the app, of course Facebook could do that from the web.
There are at least a dozen ways to do fingerprinting o the web
> The Safari version is exposed and the Safari version is tied to the OS version for iOS.
User agents can be changed by users in Safari. I wouldn't recommend doing so, but it is possible to tell Safari to stop reporting the version number to websites. I'm unaware of any way to do the same for native apps.
> There is also a battery level API that is not supported by Safari.
Note that native iOS apps do have access to battery level, which is another fingerprinting vector that can be avoided by using websites through Safari or Firefox.
Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
And which way are you arguing that Apple should add more OS level APIs for web apps or should have less for native apps?
You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
> Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
Mechanisms to protect ourselves are not less valuable just because they're not universal. In any case, you shouldn't mess with your user agent primarily because a fake user agent on Safari is likely a bigger tracking vector than reporting the version -- but that's a separate conversation. The point being, you can do so if you have a need, unlike on native platforms.
Apple could also of course de-bundle Safari from OS updates, which would be a large security/privacy benefit, but that would get in the way of the all-too-convenient coupling of Safari to iOS's security model. It might force them to actually build security layers into their OS rather than relying on privileged applications.
And notably, this is likely to get better on the web, there is an ongoing conversation about how to handle user agent strings and how to reduce the information they leak without breaking capability tests. It's a complicated issue, but there are some interesting ideas that are being proposed for the web. As far as I know, I don't really see that conversation happening for native platforms, which seem to have an expectation that running an app should just privilege the app to know everything about the hardware.
----
> You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
You can in fact have it both ways, you can implement native APIs via sensible changes that push those capabilities behind permissions. Notably, the battery life API does not currently require a permission in Chrome; it should.
Apple also had a good idea where PWA permissions were restricted to "installed" webapps. This shouldn't get rid of permission requirements, but it does significantly discourage webapps from requiring those permissions. The web is generally pretty good about this, but certain Google-proposed changes like the battery API are lagging. It would be good for the web and for users for Apple to be more involved in the standards process.
And as I've advocated for a while, you can take things even one step further than the web currently does and you can refuse to tell applications when permissions are denied, instead faking data. For the battery API, rather than reporting that a permission is disabled, browsers should instead report fake numbers.
But the idea that the web can't handle more advanced capabilities is false. Permissions are a complicated UX problem, but we have mechanisms to deal with them, and generally speaking the web has led the way on those mechanisms, with native platforms benefiting to a huge degree by imitating and building on web permission models and lessons.
People tend to forget how bad mobile permissions used to be. I would argue that the mainstream adoption of native platforms for runtime permissions, required optional permissions -- these are ideas that were popularized on the web and I would argue the web still often does a better job of handling that UX. Not that the web couldn't do better, but it is in comparison to other platforms doing a noticeably better job.
----
> These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
I agree with Apple that the majority of the APIs on this list (with a few exceptions) are unnecessary for web apps and should be approached with caution. In particular Web USB is extremely reckless, does not (as far as I can tell) have sufficient sandboxing to prevent device tampering or side-channel attacks through USB devices onto other parts of the OS, and at the very least it probably requires more safeguarding than just a permission prompt. Chrome is reckless in implementing those APIs, Apple is right to defer them.
That's not to say that they shouldn't be researched; NFC, Bluetooth, and MIDI input would be extremely important capabilities for the web if Google was proposing better privacy and security controls for them. Apple's policy around powerful web capabilities is often to stand to the side doing and saying nothing while Google develops bad specs, so that Apple has an excuse not to implement them. Needless to say, I don't give Apple credit for that. The world of notifications online would look very different if other stakeholders beyond Google had taken on bigger roles in shaping the API.
Of course, there are also plenty of APIs that Safari hasn't implemented that are not privacy risks. App badges are a good example, there's no privacy or security risk from being able to notify users that an app's state has changed. And of course it's been talked about to death, but the entire web notifications API as implemented by both Google and Apple actively encourages apps to be less private and to be looser with data. That didn't need to happen, Apple's negligence is part of the reason why web notifications are primarily only useful for advertisements and interaction reminders. Apple could easily lead the way on doing something better.
There is a lot of room for improvement here that doesn't require touching contentious or dangerous APIs. Typically when we talk about PWA capabilities on iOS, we're not talking about the ability to read device memory. What we're talking about is the ability to do much more innocuous things like schedule offline notifications without relying on a 3rd-party web server to trigger the notification -- something that would not only make PWAs more capable but would also make them more private and more secure.
Facebook could insert custom code into 3rd-party domains that have no relationship with it?
No, it can't. If Facebook could perform arbitrary XSS on 3rd-party websites it had no relationship with when you clicked on links on the Facebook website, that would be rightly treated as critical zero-day security flaw in any web browser.
I mean, you're saying you're familiar with this stuff, but you're also saying that Facebook can do arbitrary XSS via links, so forgive me for doubting you. Of course fingerprinting is possible on the web. It's easier with native apps. The web at least tries to shut down fingerprinting vectors; native platforms like iOS largely don't. Far from shutting down fingerprinting vectors, both Android and iOS have platform-supported device-specific advertising IDs that don't even require fingerprinting. At least Apple (eventually) started clearing the low, low bar of forcing applications to ask permission to access it, but that's a far cry from the kind of sandboxing and site/app isolation that happens in Safari.
> And what do you think is going to happen if there are more native APIs exposed in browsers?
I'm sorry, your defense for privileging native apps over browser apps is "if browsers could do everything native apps could do, it would be a nightmare for privacy"?
What do you think that says about the privacy and security of native apps?
> No, it can't. If Facebook could perform arbitrary XSS on 3rd-party websites it had no relationship with when you clicked on links on the Facebook website,
If you click on a link from Facebook on the web - the only reason you would view a page in a web view on the app - you don’t think FB could know that you clicked on the link?
I also see that you ignored the dozen or so well known ways that you can track someone across the web.
Are you really saying you’ve never searched for something on one site and seen ads follow you around on other sites?
> At least Apple (eventually) started clearing the low, low bar of forcing applications to ask permission to access it, but that's a far cry from the kind of sandboxing and site/app isolation that happens in Safari.
I just cited a list of ways that apps can’t track you across the web that you keep ignoring.
> If you click on a link from Facebook on the web - the only reason you would view a page in a web view on the app - you don’t think FB could know that you clicked on the link?
If you click on a link from Facebook on the web Facebook cannot perform arbitrary 3rd-party XSS on that page. On iOS, they could. You are misunderstanding what the native vulnerability was. I still feel like you do not understand what the vulnerability here is.
Facebook was allowed to insert arbitrary code into the system web view. That is not the same thing as knowing when you click on a link, it is the ability to arbitrarily execute code on 3rd-party domains regardless of whether or not those domains have any relationship with Facebook and regardless of whether they are fetching any Facebook resources/scripts. It is the ability to run custom Facebook code on sites like HN that do not normally insert Facebook pixels or tracking code.
It is not the same thing as a link ID or tracking what link you clicked on.
----
> I just cited a list of ways that apps can’t track you across the web that you keep ignoring.
I'm not ignoring any tracking vectors on the web, I'm pointing out (correctly) that every single tracking vector on that list and then some is available for native apps. Which... obviously, of course native apps can do graphics fingerprinting. They have access to the same system libraries.
You've never searched for something in a mobile app and then seen an add for it elsewhere? You don't think that tracking networks exist for mobile apps? They do. I hate to be the one to break this to you, but native apps can also run low-level graphics code to fingerprint you. They can also look at connected media devices. They can also do audio fingerprinting.
None of this is unique to the web.
The big difference is details like the fact that those mobile apps can't be used with adblockers or anti-tracking protections, and of course that the embedded web views for apps like Instagram/Facebook allow for arbitrary 3rd-party XSS, and that the native platforms expose device-specific tracking IDs and additional fingerprinting vectors in addition to all of the fingerprinting APIs that exist on the web.
You're not citing anything that's unique to the web.
And you keep ignoring the fact that native Facebook on iOS could do arbitrary XSS attacks on 3rd-party sites! Something that is not possible on the web and that is a much bigger deal than canvas fingerprinting. I don't understand what part of this is tripping you up. This really is not something that is debatable; fingerprinting is not unique to the web, every tracking vector you're bringing up exists for native apps, and in general native platforms do a worse job at allowing users to block them.
This really genuinely is not a subjective take -- it is an objective fact that mobile platforms expose more fingerprinting and tracking vectors than browsers do. This is not just an opinion, the device capabilities for native apps are higher than the capabilities exposed to websites and all of those capabilities are tracking vectors. In addition, native platforms like iOS allow nested content and inspection of nested content in a way that is not possible on the web, and allow for persistent storage and identifiers that are more difficult to construct on the web. And native platforms do not provide user-controller mechanisms like adblockers to reduce or eliminate trackers within apps. That is true of both iOS and Android.
And native mobile platforms do all that in addition to supporting all of the fingerprinting vectors that the web supports.
----
> Are you really saying you’ve never searched for something on one site and seen ads follow you around on other sites?
Generally no, on the web I use an adblocker so I don't see ads at all, let alone ads that follow me around. Notably, adblocking is not possible for native iOS applications to the same degree as it is even in browsers like Safari. That is yet another reason why native apps are worse for privacy and security than webapps are.
> You've never searched for something in a mobile app and then seen an add for it elsewhere? You don't think that tracking networks exist for mobile apps?
Well Apple decimated that ability with ATT. Facebook even admitted for instance they projected losing billions when Apple made cross app tracking opt in.
> The big difference is details like the fact that those mobile apps can't be used with adblockers or anti-tracking protections
> This really genuinely is not a subjective take -- it is an objective fact that mobile platforms expose more fingerprinting and tracking vectors than browsers do.
You named one additional way that you can track on an app if a user uses a web view.
There are dozens of ways that websites can track you without your permission that aren’t available in apps.
> and allow for persistent storage and identifiers that are more difficult to construct on the web
Really? You can’t do persistent storage on the web that’s available cross site?
> And native platforms do not provide user-controller mechanisms like adblockers to reduce or eliminate trackers within apps. That is true of both iOS and Android.
In fact they do, I just cited a list of VPNs you can install.
> Generally no, on the web I use an adblocker so I don't see ads at all, let alone ads that follow me around. Notably, adblocking is not possible for native iOS applications
Good thing that every single person or even the majority of people use ad blockers…
It is unclear to me that this vulnerability has ever been patched, though of course Facebook denies that they use it for tracking (but of course they do). In the interest of being diplomatic to Apple I am operating under the assumption that they eventually patched it, but I have never been able to find a source verifying that they did.
As far as I know, Facebook is still doing this today in iOS.
It is of course also notable that when Apple discovered that Facebook was essentially performing malware attacks on 3rd-party sites, they didn't remove Facebook from the app store or punish Facebook in any way. So let's also get rid of the idea that moderation is a solution here, because Apple has repeatedly proven that they are not willing to remove apps like Facebook that violate privacy rules. 3rd-party XSS was not a big enough deal to Apple to remove the Facebook app.
----
> [censored VPN advertising site]
VPNs are not a suitable alternative to native adblockers for a myriad of reasons that get discussed to death whenever VPNs come up in these conversations. Also, please do not link to a recommendation site that recommends NordVPN as the best VPN for privacy. NordVPN should be avoided.
In general, while I take a much more positive view on VPNs than many other HN commenters and while I do think they can enhance privacy, I still agree with the advice of many security professionals that VPNs can open up users to substantial privacy risks and should not be lightly used without a good reason or without a lot of research into their privacy policies and management.
> You named one additional way that you can track on an app if a user uses a web view.
No, many. Low-level graphics, contacts, device IDs, webview injection, long-term storage, precise location, bluetooth connections, etc, etc... the list goes on and on.
> There are dozens of ways that websites can track you without your permission that aren’t available in apps.
Such as? I can't think of a single one.
----
> Really? You can’t do persistent storage on the web that’s available cross site?
No, you can't! How is this a surprise to you?
The lack of persistent cross-site storage and the fact that any available cross-site storage is strictly opt-in is one of the biggest things that the web does. It used to be a little bit worse with 3rd-party cookies, but not only was that still subject to cross-origin restrictions and still required opt-in from every participating site, but also every major browser is now restricting 3rd-party cookies (even Chrome).
Even with PWAs on iOS, you can't access cross-site storage. In fact, Apple's entire justification for shutting down PWAs was that they wanted to ensure that cross-site storage restrictions continued to be respected (which is a bullcrap reason since every other browser already does this, but whatever).
Seriously, I'm trying to be diplomatic and respectful about this, but you need to look up how security models on the web work before you spout nonsense like this. 3rd-party site isolation is a big deal on the web, as is easily cleared storage that is treated like a temporary container. Safari goes a step further and auto-clears some of that storage. It was a big deal with PWAs when they announced a single way to get just 1st-party storage to reliably persist long-term.
There is no shared storage pool for the web that every site is subjected to, that is the entire point of cross-origin restrictions.
----
> In fact they do, I just cited a list of VPNs you can install.
See above.
> Good thing that every single person or even the majority of people use ad blockers…
More than the people using adblockers for iOS. Like seriously, do you think the number of people who pay for a VPN adblocker is higher than the number of people who install for free ublock origin or a similar Safari-compatible adblocker?
This is absurd, you're looking at a tangible way in which native privacy is worse and you're saying, "but nobody uses the better solution." That's not exactly a convincing argument. I use adblockers online. My whole family does. Having at least the ability to protect oneself to some degree is important. You're not denying that for anyone that actually cares about privacy, the web is easier to secure -- you're just arguing that nobody cares about privacy. But some of us do.
And if you're talking about what the average user does, the average user A) doesn't pay for VPNs (even if VPNs were a substitute for adblockers, which they're not), and B) doesn't turn down invasive data requests from native apps, of which there are far more available to make on native platforms than on the web.
Objectively, factually, native app privacy is worse. It just is; you can either accept that or you can keep pretending that reality is something that it's not. But your lack of acceptance doesn't change anything about the reality that native platforms expose more fingerprinting vectors, have fewer ways for users to protect themselves, and are generally capable of much more invasive and malicious behavior.
> It is unclear to me that this vulnerability has ever been patched
To my understanding Apple has provided a solution in the form of a new type of webview available to apps that protects privacy. Last I checked (I don’t have the FB app installed for this exact reason so I’m not up to date) FB have not switched to using this new webview. It would be difficult to remove the functionality from the original API (WKWebView) because app developers like myself use it for legitimate reasons with internal web content. There have been some moves to lock advanced features behind an app-defined list of domains but it’s far from comprehensive. Maybe in iOS 18 (he said skeptically).
The answer is simple: Apple just needs to deny FB App Store approval until they switch APIs. Of course they haven’t done that, and they won’t.
Thanks for the details, I've been curious for a while how this would shape up and I'm glad to get some information about the current state of things. Cross-origin privileges for inserting code would be my naive guess about how to lock that down, so it's good to hear that there's at least some dialog about it, even if it unfortunately seems to have not gone beyond the dialog.
> The answer is simple: Apple just needs to deny FB App Store approval until they switch APIs. Of course they haven’t done that, and they won’t.
Right, I guess to be a bit more fair to Apple, there are things they could do here that would make me more sympathetic to their arguments about moderation. The reason I'm generally unsympathetic to arguments that Apple moderation keeps the app store safe is because they don't moderate enough. I feel like I have a lot stricter standards about what apps should be able to get away with than Apple does.
If Apple had when this story broke literally removed Facebook from the app store and forced them to disable that code, that would have been decent evidence to me that their moderation of the app store could have a substantial impact on privacy.
I do think there are things Apple could do that would better justify their hold over the app store.
AFAIK Apple still doesn't support PWAs. As one example AFAIK, iOS Webkit doesn't support fullscreen mode and orientation so it's impossible to make a landscape game as a PWA. That is supported on Android Firefox and Chrome for like 10 years? And would likely be supported on an alternate browser on iOS
I'm pretty sure there are many other APIs that PWAs want, that native apps have, that Firefox and Chrome offer on Android, but since 3rd party browsers are not supported on iOS, don't exist there.
Yes, installed PWAs can run fullscreen. This limitation exists only inside of Safari proper.
The intent here is likely to avoid the messes that could be caused by arbitrary sites being able to fullscreen and confuse or trick the user. Requiring a user interaction to fullscreen doesn’t help here much, it’s easy to attach the function to an innocuous looking link or image that baits users into tapping them.
(1) Firefox and Chrome has shipped with that ability for 10+ years on Android and the world hasn't ended
(2) PWAs are effectively apps. Native apps can do that those things so there's no difference in terms of risks. You could certainly make it so web pages can't but PWAs can.
Also, no, Safari PWAs do not do allow you to lock the screen orientation
> The notion that Apple was purposefully trying to kill PWAs never made sense in light of their significant investment in supporting PWAs over the last four years, down to recruiting industry rockstars such as Jen Simmons.
Apple's investment into PWA support can charitably be characterised as "begrudging". You don't need to defend this company. They have been behaving badly for a long time.
> Apple's move also comes after a threat to look into the issue by European Commission authorities.
> "We are indeed looking at the compliance packages of all gatekeepers, including Apple," the European Commission said in a statement on February 26. "In that context, we're in particular looking into the issue of progressive web apps, and can confirm sending the requests for information to Apple and to app developers, who can provide useful information for our assessment."
Apple stated in their first statement regarding multiple engines support for PWAs, that it can be done, they just decided not to make it. Also, it’s an about 18 months old law. Not that they wouldn’t have time or resources for that matter. So there was clearly a purpose to kill PWAs on iOS, and it was clearly their decision according to them.
Another thing with EU, you can ask them. And normally, first, you ask them when something is questionable. This either didn’t happen, or Apple didn’t wait, or they already know what is the response. This was clearly a PR move.
So it’s totally understandable when people have problems with Apple, how they handled this.
One of the most valuable tech giants in the world is definitely capable of a simple red herring like this. This is amateur stuff. Apple likely has contingencies and plans for almost every scenario and if we learned anything apple email leaks is that they are keen on following up on any sound strategies, even ones that involve "we can't talk about this on email".
If (as many people have suggested) Apple's intention in suddenly devoting significant resources into PWAs (after completely ignoring them for years) was to avoid app store regulation, it makes perfect sense that when they failed to stave off regulation in the EU Apple would no longer have a motivation for investing into them within the EU.
Additionally, even if Apple is still looking at PWAs as a way of staving off regulation in the EU, it still makes perfect sense that Apple is running a cost-benefit analysis on PWAs being open to other browsers. PWAs on iOS are significantly limited even after Apple's increase in support. Supporting PWAs just well enough to stave off regulation while keeping them locked down so that other browsers can not extend them or push capabilities further is entirely in Apple's interest.
----
My take is that Apple as a company would prefer not to be working on PWAs at all. But that's not really an option, because both the EU and the US are looking at regulating the app store. The next best option is to have PWAs be a serviceable but ultimately inferior option for offline-only and privacy-preserving apps (and in fact many of the APIs Apple supports are entirely unusable for offline-only apps, although to be fair that's probably more Google's fault than Apple's). Apple may very well have thought the option of a semi-supported but ultimately inferior, controlled PWA experience was off the table in the EU; or they thought that with the app store opening up they could get away with killing the platform for EU users entirely. In either case, they now seem to believe they can keep PWAs locked down to only support Safari capabilities. Maybe they're right, I'm sure Apple has more access to regulators to ask these questions than anyone else here does.
And so none of this is incompatible with the notion that Apple wants to kill PWAs. The idea that a company can completely ignore a technology for years and years and years, and then suddenly out of the blue as soon as regulation gets suggested start pouring resources into their browser and openly arguing in court, "see, you don't need to regulate us, we have a browser" -- and we're supposed to believe that this means that Apple is suddenly on board with the technology and that they don't have ulterior motives or that their motives wouldn't shift back if the threat of regulation went away.
That is just silly. Apple has had literal years to both clarify with regulators what the browser regulations would mean and to build APIs for PWAs that Microsoft and Google have been perfectly capable of creating. And in light of their last-minute scrambling, the most likely and reasonable interpretation is that Apple thought they could get away with killing off PWAs now that they were no longer useful for avoiding app store regulation, a bunch of people screamed about it, regulators reached out, and suddenly Apple had a (partial) change of heart.
Note, of course, Apple has no timeline or plans or announcements about when (or if) PWA APIs are going to stop being 1st-party privileged and exclusive to Safari, despite the fact that Apple has known that this regulation would be coming for multiple years. Which does seem to conflict a little bit with the narrative that Apple is all-aboard with PWAs as a technology and that they've been investing into them as a long-term strategy or commitment to the web, but what do I know?
---
But I really, genuinely do not see what the past 4 years prove other than that Apple's motivations about the web can change on a dime the moment that regulation enters the picture. And I think that's really revealing, and I think it says something about Apple's commitment to the web that it took the threat of regulation to make them care at all about the web as a platform, and I think it really says something about Apple's motivations that the moment that regulation went through anyway, Apple suddenly reverted back to its previous stance on PWAs and was comfortable throwing all of the PWA investment of the past 4 years out the window.
I very honestly do not understand how people can look at these series of events and say, "this proves that Apple cares about the web." We're looking at the same timeline, but it's like you're reading it in a different language than I am.
The DMA was passed many years ago (January 2022), before the cited investments in PWAs. So if Apple was acting to proactively stave off regulation, you have a big hole in your theory of causality.
The web is more than a Chromium app runtime. We are commenting on the web without any of the random features Chrome builds because they are strategically invested in ChromeOS, and their user data harvesting business model relies on more clients sharing more data with Chrome and Google. Apple’s interest in the web cannot be gauged by how much they support technology funded and evangelized by a bunch of current and ex-Googlers that has little to do with open exchange of information. Conflating it is a strange rhetorical trick.
> The DMA was passed many years ago (January 2022), before the cited investments in PWAs. So if Apple was acting to proactively stave off regulation, you have a big hole in your theory of causality.
I'm not sure I do? The DMA was passed in January 2022. In that entire span of time when Apple was actively arguing in court that PWAs were an alternative to the app store, at no point did they ever consider building out a proper security model for PWAs that didn't rely on the assumption that Safari would be the only supported browser.
You're saying that Apple learned about the DMA before they started looking at PWAs seriously, then we got to February 2024 and suddenly Apple was caught flat-footed about browser requirements? That doesn't make sense: either they knew about the DMA and their current lack of PWA security models are an active decision that purposefully complicated compliance with the DMA, or Apple somehow wasn't thinking about the DMA in which case it's kind of silly to say that it disproves anything about their apparent web strategies.
This is a situation where the excuse makes Apple seem more suspicious, not less. Apple knows in 2022 that the DMA is coming. In February 2024 out of the blue they announce that they're shutting down PWA support. If that's not strategic, it's at least wildly incompetent. And I don't think that Apple is wildly incompetent -- I think that announcement was strategic.
> So if Apple was acting to proactively stave off regulation
I'll also note that this is not a theory, Apple is actively arguing in the US that PWAs mean that it shouldn't be regulated. I don't really understand the contention here, the way I see it Apple is saying that PWAs are a proactive strategy to stave off regulation.
We can disagree about their motivations beyond that regulation, about whether they would consider dropping support in the absence of regulation, but it is just a fact that Apple started investing more heavily in Safari around the same time that regulation arguments started popping up in both Europe and the US, and it is just a fact that Apple has proactively put forward PWAs as an argument in court cases as to why it shouldn't be regulated.
Is it really that weird to connect those dots?
----
> Apple’s interest in the web cannot be gauged by how much they support technology funded and evangelized by a bunch of current and ex-Googlers
Apple's support and advocacy for PWAs is pathetic even ignoring Chrome's support. It's not like Chrome has good PWA support, the entire notifications API is obviously designed by an advertising company with zero real input from any stakeholders other than advertisers.
Ideally, investment from Apple into the PWA ecosystem would mean not leaving the entire PWA specification to be written entirely by an advertising company, it would mean proactively getting involved in the process. It would mean asking questions like, "aside from Google, who on earth does it benefit that notifications have to be triggered by a remote server and can't be scheduled locally?"
The state of PWAs is as much a story about the apathy of every other company besides Google as it is a story about Apple holding back on basic support for extremely needed features like reliable offline storage. I'm not giving Apple credit for sitting back and twiddling its thumbs while Google ruins the spec, and then turning around and saying, "you can't expect us to implement these features, the proposed specs are terrible."
Yeah, of course they're terrible, where were you while Google was ruining them? I'm surrounded by people arguing that Safari is some kind of final bastion against Chrome hegemony, but in practice Apple does nothing with that bastion. They let Google make all the decisions, and then use that as an excuse to offer middling browser support. I'm not giving them credit for that. I'm not talking about exposing web usb support, I'm talking about things like: is it possible build an alarm clock as a PWA?
I'm not asking Apple to bow to Google's every demand, I'm asking them to act like they're a stakeholder in the web and to give even one single damn about whether it's possible to build privacy-respecting offline webapps. Apple's apathy towards influencing or pushing the PWA web standards process in a productive direction is just as much a problem as their apathy towards supporting obviously beneficial capabilities like icon badges. Apple defers power to Google and then uses that as an excuse for further inaction.
Just like Apple's 3-months free trial for the Apple Music service, keeping the Webkit-only PWAs were going to be seen as anticompetitive by Apple's opponents.
Making the change early is a strategy to exploit Apple's opponents into loudly decrying how important and useful PWAs are - and that removing PWAs is the true, evil, anti-competitive strategy. (With all of their typical exaggeration, in reality we know PWAs are a limited-use feature.)
In short, Apple played the useful idiots into being their cheerleaders and provided Apple exactly what they needed to maintain this feature.
It didn't even take an "open letter" from "Taylor Swift" to "Tim Cook" this time.
tl,dr: Apple exploits anti-apple rhetoric to get their way, again.
The histrionical descriptions of other people's takes are like nails on chalkboard and kinda gross. (bloody murder?)
No one thought removing them in the EU was the first step to removing them everywhere.
Jen Simmons isn't a "rock star."
Hiring someone with a lot of Twitter followers to do something doesn't preclude the company from stopping doing something.
I think everyone over 30 in tech has seen that first hand. Couple right off the top of my head for Apple: Graeme Devine, Max Howell...
In general, it is important for discussions to have nuance. I'm sure you've seen some un-nuanced discussions that I haven't. However, escalating rhetoric to condemn lack of nuance in others rhetoric should be reconsidered.
> The histrionical descriptions of other people's takes are like nails on chalkboard and kinda gross. (bloody murder?)
Claiming that Apple is trying to “kill” PWAs is in and of itself histrionic. Especially when behavioral evidence that clearly points to the opposite is completely ignored and the bad faith intents are attributed wholly based on “vibes”. My categorizing that as screaming bloody murder isn’t an escalation in rhetoric[0] in the slightest.
> Jen Simmons isn't a "rock star."
It’s a figure of speech within the industry, granted, it typically also implies big ego issues, so perhaps the term isn’t so suitable when it comes to Simmons.
> Hiring someone with a lot of Twitter followers
Trying to diminish someone’s accomplishments and relevance within an industry by pretending they “just have a lot of Twitter followers” does nothing to refute my arguments. She’s one of 82 web developers with a Wiki bio and one of 177 programmers, that alone signifies notability.
Point is that that she’s a high profile programmer and web developer and those come at a premium. That, plus the significant efforts made in the last four years to not only support PWAs but also improve standards, runs counter to the notion that Apple has ill will towards PWAs.
While she has spearheaded a lot of the investment in PWAs, for the purposes of this debate I only brought her up to emphasize Apple’s investments in making improvements.
Even with Simmons out of the equation there’s still four years of significant engineering efforts to reconcile.
> doesn't preclude the company from stopping doing something.
You’re begging the question here. Without you substantiating the implication that Apple has stopped improving PWAs, you’re just throwing around empty words.
Nevertheless, it’s clear Apple hasn’t stopped their efforts on PWAs, given that the next Safari update will, again, include a slew of improvements to the benefit of PWAs as can be seen in the Safari Technology Preview release notes[1].
I’m amenable to debate this further, provided you put in some effort into make a credible case with substantiated arguments and you can keep the tone policing to yourself.
It is quite explicitly not a statement indicating I believe them to be irrelevant or not famous.
This is immediately clear when, immediately after these two words, I mention Twitter followers, clearly indicating I believe they have fame and relevance.
It's abundantly clear when I spell out that companies don't make product decisions based on famous hires. (n.b. rock stars get to dictate the concert and album schedule)
It's ever the more clear when I name famous and relevant people as similes.
It's absolutely abundantly clear once you notice I never used the words famous and relevant, or words with stems of the same.
It's a fools errand to spend time imagining thoughts in other people's heads that twist their words into insults of other people.
Really? This is what you want to spend your time on doing?
> Source for where I claimed this?
Source for where I said you claimed this?
> Source for where I said anything about accomplishments or relevance?
Source for where I said anything about you straight up saying anything about accomplishments or relevance?
> Source? I don't know where this is from at all.
You said: “Hiring someone with a lot of Twitter followers to do something doesn't preclude the company from stopping doing something.”
Now you’re gonna act coy by acting undignified about me interpreting “to do something” and “stopping doing something” to refer to working on PWA support when that has been the topic of this thread the entire time?
This would have been easier: "oh, I missed a line break, imagine a \n after 'doesn't preclude the company from stopping doing something."
If you needed to get a dig in, could have appended "I would imagine you would have remembered and/or noticed that at least the first sentence was in your post"
The law requires Apple to open up iOS to 3rd-party browser engines and that Apple can't self-preference their own browser. This would mean that Apple has to open up anything that Safari can do (like run PWAs).
For all we know, the EU might be considering PWAs a thing completely orthogonal to DMA compliance, since they neither provide feature parity with native apps, nor are they widely used (at least according to Apple's measurements).
> open up anything that Safari can do (like run PWAs).
I think it would be just as valid a viewpoint to consider them an OS feature (as opposed to a browser feature). The question then is whether that OS feature would be considered protected under the DMA.
For example, it's also impossible to provide your own kernel extensions (e.g. to facilitate hardware device drivers) for iOS – but that's completely fine (as far as I understand) under the DMA, since it's not one of the covered areas like app stores, NFC payments etc.
I'm not very certain of the last point, FWIW – maybe the DMA does actually require Apple to provide, on demand, access to hardware interfaces available to their own product offerings! For example, wireless (Qi) outbound charging is supported by recent iPhones, but only works with Apple's own Magsafe power bank, and other power banks can only do inbound wireless charging and need to be charged via USB – maybe that's actually noncompliant too? That would likely kill, or at least strongly impact, Apple's MFI program in the EU – or maybe just expand it to cover all first-party hardware interfaces too?
> For all we know, the EU might be considering PWAs a thing completely orthogonal to DMA compliance, since they neither provide feature parity with native apps, nor are they widely used (at least according to Apple's measurements).
DMA wording made it very clear that it's about browser engine, not the browser product. And Safari is designated as a core platform service.
> The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
> DMA wording made it very clear that it's about browser engine, not the browser product.
Yes, but nowhere does it say explicitly that that third-party browser engine has to also be capable of hosting PWAs. It's definitely a possible read of the DMA, but not the only plausible one, in my view.
> The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper.
> Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.
They're pretty much just shortcuts/bookmarks to a browser window yes. If I "install" a PWA from Firefox I expect it to open in Firefox. I would be very surprised if I ended up in Safari instead.
From the casual user's perspective, it does not "open in Firefox", though. It opens in a separate window with very different chrome, and you have to poke around to even determine which browser is actually hosting it.
Furthermore, on macOS specifically, PWAs are fairly well decoupled from browsers. For example, if you install a PWA in Safari, and then click on an external link in said PWA, it will not open that link in Safari, but rather in whatever your default browser is.
yeah, it should just open up in the default browser setting within the OS. having to create a shortcut based on which browser would be ridiculous. must like the post you were replying to was a ridiculously proposed comment.
> having to create a shortcut based on which browser would be ridiculous
Depends how you look at it, Chromecast is only available from Chrome. If I want a specific page to open in Chrome because I use it mainly to cast videos should I have to switch my main browser to Chrome?
Probably not how it works today and my initial comment didn't imply always open in Firefox even if not default browser, but thinking about it maybe that's how it should work, or the option to choose should be available?
No, DMA wording made it very clear that it's about web browser engine.
> The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
And they cannot make self-preferencing on their products.
> The gatekeeper shall not treat more favourably, in ranking and related indexing and crawling, services and products offered by the gatekeeper itself than similar services or products of a third party. The gatekeeper shall apply transparent, fair and non-discriminatory conditions to such ranking.
> The gatekeeper shall not restrict technically or otherwise the ability of end users to switch between, and subscribe to, different software applications and services that are accessed using the core platform services of the gatekeeper, including as regards the choice of Internet access services for end users.
And Safari has been explicitly designated as a separate core platform service. There's no room for this kind of interpretation in the view of enforcement entity. Apple is just trying to buy time by pretending ignorance.
It’s more subtle than that. If Apple uses WebKit within one of their built-in apps or OS components, let’s say in their Weather app or some Apple Pay dialog, there surely is no requirement that this has to be replaceable by Chromium or Gecko. Similarly, the PWA runtime environment may not necessarily count as a “web browser engine”, since they aren’t used to browse the web. It remains to be seen how this will be judged by the EU institutions.
This is in fact how PWAs work on iOS. They do not run in Safari at all, but in a special runtime called Web.app, which is coded to use WebKit. Safari doesn’t have the ability to do the things the PWA runtime can do. Letting other browsers “run PWAs” would not be a matter of exposing an existing private API, it would require creating a a brand new plugin API for Web.app that would allow inserting other browser engines into it.
Surely the distinction is about the existence of a market. There is a market for competing browsers from different vendors which do compatible/interchangeable things that might be selected by different consumers for different reasons. The technical definition isn't the important bit, the regulation exists to preserve that interplay between consumer choice and market innovation.
There is no such consumer-driven market for in-app UI libraries, be they WebKit-based or not. The "consumers" in such a market would be the app vendors, and in fact this is an area well-served by existing products from competing vendors. That's clearly not what the DMA is trying to regulate.
It's because those apps are not core platform service. Safari and iOS both are core platform services, which are explicitly designated as a target of this regulation. Go read the actual wording and have some understanding before making this kind of assumption.
When you open a PWA, Safari does not appear. The argument can be made that this is not Safari, but a PWA runtime environment that happens to use WebKit internally. Basically, the PWA is it’s own separate app (i.e. not Safari) that is being run by iOS with the help of WebKit, similar to how other OS features also use WebKit internally. It is not clear at all that this would fall under the category “web browser engine” of the DMA, since using a PWA does not constitute browsing the web.
As for your argument about core platform services, the app store is a core platform service and (I’m pretty sure) uses WebKit internally, at least for some of its pages in login and payment flows, and similar for various iCloud-related functions accessible from Settings.
I’ve read the DMA, you don’t have to be condescending.
I'm not sure if you've only read some digests but not the full text including other supporting materials (it matters since this defines how the laws will be applied) since all you mentioned are already addressed in the designation decision doc. To be specific, in DMA.100027, EU clearly stated that it doesn't matter whether it's embedded in other apps or standalone:
> "... the Commision concludes that Safari, including all the elements that allow for the display and access to web content, either standalone, integrated or embedded in other software applications or similar, constitutes a web browser CPS ..."
If you've seriously worked on hashing out all the details of CPS and clearing up the ambiguities, you cannot be unaware of this decision since this will impact everything on your daily works. Yeah I did that because the precise definition of CPS was critical for my work in the last year.
EU is not that dumb, to my understanding they've been pretty serious in respecting the spirit of this specific legislation. You cannot say that some part of it can be simply opted out by adjusting the definition of your product. What they care about is how business is done and make the market control out of it.
> The argument can be made that this is not Safari, but a PWA runtime environment that happens to use WebKit internally.
This is a silly and thin technicality, and not at all the same as what people are mad about. Nobody cares that WebKit is used to render certain windows on iOS and MacOS - it's Apple's choice to implement first-party programs that way. They can defend their usage of it internally, the problem is the limitations they impose on competitors.
> I’ve read the DMA
You're certainly taking some elements in liberty. It remains unclear how defining WebKit as a "PWA runtime environment" exempts it from the terms of the DMA or DSA.
Sorry, but at this point it’s you who have to provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing.
Just to be clear, I’m absolutely in favor of having a free choice of PWA engines, I just don’t see this being implied by the DMA and the present gatekeeper designations. The question really is how a PWA runtime environment differs in principle from the regular iOS app runtime environment, which the DMA also doesn’t mandate to be replaceable.
> provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing.
Oh, this is easy.
First-party software is distributed by Apple. They choose how that software is presented because they are the operator of the software.
PWAs and websites are distributed by third-parties. They are websites, not curated by Apple, that load in your browser. It's only after you use your browser's "PWA" function (something everyone should have) that we change into this "WebView" scenario. It's arbitary, and not at all the same as Apple rendering Apple Music or Settings using WebKit.
> how a PWA runtime environment differs in principle from the regular iOS app runtime environment
A PWA is packaged by the user. If Apple's "solution" is forcing all apps to display PWAs in a Safari WebView, then yes, the DMA will target it as a core service. I don't see why the EU would roll over when they made specific carveouts for browser control in the DMA.
You’re misreading pretty much everything you’ve quoted from the DMA.
> No, DMA wording made it very clear that it's about web browser engine.
You follow this up by quoting a clause that manages core platform services.
What it says is:
> The gatekeeper shall not require [people] to use, to offer or interoperate with [stuff] of that gatekeeper in the context of services provided by [third party devs] who use the gatekeeper’s core platform services.
A good example where this is applicable is the App Store, which is designated as a core platform service. PWAs aren’t designated as core platform service and there’s also an argument to be made that web developers aren’t considered “third party devs” (or as the DMA calls them “business users” due to a lack of agreement between Apple and them.
> And they cannot make self-preferencing on their products.
Same here. This one is even narrower because it’s only limited to preferential treatment in the sense of “ranking and related indexing and crawling”
> The gatekeeper shall not treat more favourably [in ranking and related stuff] [their own products and services] than [similar products and services by others]
This applies to ranking apps in the App Store. It has no bearing whatsoever on PWAs unless somehow Apple starts ranking PWAs in a list and then chooses to rank their own PWAs higher.
The other one is also much narrower than you’re reading it.
> The gatekeeper [shall not prevent users from switching to and subscribing to different apps including browsers]
This mainly pertains to setting default apps and switching default apps. This tangentially relates to PWAs, but installed PWAs are technically not run in Safari and instead in their own app that uses WebKit under the hood, so it’s not so clear if this would apply to PWAs.
> There's no room for this kind of interpretation in the view of enforcement entity. Apple is just trying to buy time by pretending ignorance.
I can’t distill a lifetime worth of legal experience into a tangible piece of evidence nor are there readily available authoritative sources on compliance with government regulation narrow and simple enough that I can just present them without much worry of you understanding them, especially since you’re already struggling with, what is considered in European legal standards, rather straightforward legal text.
So all I have is a trust me bro, and perhaps an appeal to common sense: Apple’s lawyers didn’t just wake up today and said to themselves “You know what, we were too cautious with interpreting the DMA a couple of weeks ago, I’m sure it’ll be fine if we keep PWA installs without implementing a way for other browsers to install them as well”, much less a variation in which they are trying to buy time by feigning ignorance.
We already know that the EU reached out to Apple about disabling PWA installs. So with that in mind, do you think the lawyers woke up one day and said “fuck it” or do you think it’s more likely the lawyers gave the go ahead after the EU told them that PWA installs as implemented in iOS are beyond the scope of the DMA?
> A good example where this is applicable is the App Store, which is designated as a core platform service. PWAs aren’t designated as core platform service and there’s also an argument to be made that web developers aren’t considered “third party devs” (or as the DMA calls them “business users” due to a lack of agreement between Apple and them.
The core platform service in this case would be iOS itself.
Also, nowhere in the DMA does it say that there must be a contractual relationship between an entity and the gatekeeper in order for the former to be considered a business user. Windows is a designated CPS under the DMA and no contract with MS is required in order for you to make, distribute, and have your users run your software on their Windows PCs.
> The core platform service in this case would be iOS itself.
You’re right, iOS is a CPS. But that doesn’t change much in the meaning of the provision, nor does it make it applicable to web developers.
Specifically for iOS it would change to:
> The gatekeeper shall not require [people] to use, to offer or interoperate with [stuff] of that gatekeeper in the context of services provided by [third party devs] who use [iOS].
The PWA engine is a core part of the iOS operating system, so there is no “us[ing]” “offer[ing]” or “interoperat[ing]” with other stuff.
But the point below is more relevant here.
> Also, nowhere in the DMA does it say that there must be a contractual relationship between an entity and the gatekeeper in order for the former to be considered a business user.
True, I’m skipping the minutiae and going straight with the end conclusion.
Article 2 of the DMA contains all definitions.
For business users it states under clause 21:
> 'business user' means any natural or legal person acting in a commercial or professional capacity using core platform services for the purpose of or in the course of providing goods or services to end users
The CPS in this instance is not iOS because iOS isn’t used in the course of providing goods and services nor for the purposes stated above nor can it be used for those purposes.
The CPS in question is as defined under clause (2)(a), namely an intermediary service, more precisely, the App Store.
And Apple only allows usage of the App Store (and its IP needed to make apps) when under contract.
The DMA does not prohibit this, because doing so would be nationalizing private property.
Ipso facto, business users are under contract and web developers aren’t “business users” as defined under the DMA.
Hence the main clause in question, the one clarified at the top, doesn’t apply to PWA developers.
> Windows is a designated CPS under the DMA and no contract with MS is required in order for you to make, distribute, and have your users run your software on their Windows PCs.
That’s not a consequence of the DMA, it’s a consequence of Microsoft not monetizing their IP in that way.
I disagree with the general notion that making an app that is compatible with an operating system (i.e, that calls its APIs) is a "use" of the OS maker's IP, at least on a legal sense (which is all that matters in this context).
The final authority lies with the courts. If any of the third-party browser providers sue for being disadvantaged by PWAs being restricted to WebKit, no previous “back-channeling” with the Commission will have any bearing on the judgment. And the Commission knows this, so is unlikely to engage in that manner.
Setting the agenda matters. This drama probably made more people and businesses aware of the DMA and may influence the focus of some participants. For example, there's an "Apple DMA compliance workshop" in two weeks, to which interested stakeholders can register:
https://digital-markets-act.ec.europa.eu/events-poolpage/app...
What you said is true but not to the extent that you might think if you are used to the legal systems of countries like the USA or UK.
Since Brexit, almost all EU member countries follow the civil law system (the only member country following common law that I can think of is Ireland, not sure if there are others). https://en.wikipedia.org/wiki/List_of_national_legal_systems
Apple provided theirs reasoning on this (security issues due to how iOS is currently written...) when they initially stated they would be removing them and said the work was'nt worth the tiny base of users who use it.
Only technical reasons. When PWA’s were introduced in iOS 11, they were built with the assumption of WebKit as a privileged process. A re-arch is definitely doable, just a big expense for little return. And probably not feasible in just a year, can’t imagine it would be a top priority against all of the other work.
Myself, I'll use PWA to mean "promoted web app" - since it is closer in this context, and 99% of the market gets "progressive" wrong anyway.
I believe that third party browser engines will have the same privileges as WebKit (in the EU, on iOS only).
PWAs do not run directly on WebKit; they run on Web.app which is a WebKit-based application. Think something like Cordova, provided by the OS, but which does not require each PWA to be a separate wrapped app listed in the App Store.
There is a recently-added interface to create one of these Web.app PWAs by third party browsers, as well as to create home screen bookmarks (which I believe open in the default browser not the running browser, but I am not a browser implementer).
There is not however not a way for a browser vendor to ship their own Web.app-equivalent using their browser engine.
Simulating some of the behaviors of a PWA on iOS outside of Web.app is also difficult. For instance - the multi-window functionality of iPadOS is not present, so a fullscreen web app would block usage of other tabs.
They were basically negotiating in public. I think the EC probably realized that the DMA as currently written is flawed and producing outcomes they don't want, and this episode basically highlighted it to them. They probably told Apple there won't be any enforcement against only Safari having it, because the alternative is worse. A basic principle is that you are very unlikely to compel Apple to engineer anything unless they choose to, and you would most likely lose in the EU courts if you tried to. Any regulation that doesn't factor that in is going to be doomed to fail.
> A basic principle is that you are very unlikely to compel Apple to engineer anything unless they choose to, and you would most likely lose in the EU courts if you tried to. Any regulation that doesn't factor that in is going to be doomed to fail.
That sounds a bit like "Apple is beyond the law/regulations, regulators better accept that and move on" – is that what you mean?
There's a big difference between those cases. In the USB-C case there was no room for argument. It was either include the new port, or stop selling the iPhone.
In this case, they could just remove entire features and have the public do their lobbying for them.
It shouldn't be too hard to make the case for that being malicious compliance, though. It seems to have worked in this particular case, for example: People called Apple's bluff.
Malicious compliance and "spirit of the law" aren't real things when it comes to the legal system. You either comply with the law or you don't. And courts will ultimately decide if Apple's interpretation of the DMA complies or not.
They are, in Europe. We don't really like companies not following the spirit of the law. Companies usually learn via fines. Luckily for us, Apple is a slow learner.
It’s lucky because to a lot of android fans it isn’t really about consumer outcomes, it’s about finally legislating a solution to the android-iOS war.
If you can’t win in the marketplace of ideas, just ban walled gardens entirely. Flip the table and ban your competitors’ business model, bioshock style.
Now of course, since obviously most android fans aren’t actually owners of a major company… they aren’t really “your competitor” unless you’re parasocially attached… this is a rather obvious commentary on the degree of parasocial attachment that so many people seem to have towards android and against apple… but here we are.
> If you can’t win in the marketplace of ideas, just ban walled gardens entirely. Flip the table and ban your competitors’ business model, bioshock style.
But the DMA doesn't ban walled gardens. It requires the availability of competitive alternative marketplaces, which can certainly just lead to multiple walled gardens.
This is like saying "if you can't win the market, just ban slavery completely". Walled gardens are plain wrong, no need to invent a "market" justification.
Companies are compelled to develop features all the time. Mostly so far in the EU these features have been around accessibility, safety, and crime prevention, but there’s an awful lot of precedent for companies being required to develop something specific in order to be able to sell their product in the EU.
Companies comply with those regulations because, on balance, the incentives still make it logical to. That doesn't mean an unbalanced regulation that misunderstands the target's incentives would result in the outcome the regulator wants.
I think nobody in the EU can make such assurances. It's a law, and courts will decide if apple is following them.
The European Commission announced a few days ago that they will look into the decision of apple to remove PWAs, so they more or less announced they are trying to fine them because of it.
Which means that completely removing PWAs could be the more risky choice instead of keeping them Safari-only. Completely removing PWAs already started an investigation. Keeping them Safari-only might not start an investigation at all, so it might be the lower risk.
After all I think Android also has a Chrome-only implementation for PWAs, exactly like Windows, that runs PWAs on Edge. Also back in the days when Microsoft had to give users a choice to use another browser than Internet Explorer it was also not possible to exchange Internet Explorer as the engine for many system services that used the system web view component. I think it's still the case with the current Windiws WebView2 based on Edge.
> This means that all Home Screen web apps will still be powered by WebKit, regardless of whether the web app is added using Safari or not – exactly as it works today and has for years.
That works (I suspect) because they run them as JavaScript in a different browsing context and have implemented some of the WebExtension APIs themselves on the backend, e.g. HTTP request filtering (which is one of uBlock's primary functions).
That's a nifty workaround but not ideal, since it's not possible to actually provide all WebExtension APIs that way.
I doubt there was back-channeling - Apple is seeing how liberally they can interpret this act. They tried doing the same thing when they threatened to use MFi on USB-C, up until an EU Comissioner threatened to boot them from the market. Plus, making per-company agreements would kinda render the entire "point" of the Digital Market Act moot.
Apple knows exactly what the DMA wants from them, they're just deathly terrified of handing it over.
There is no evidence that Apple ever planned to introduce a MFi system with USB-C. What likely happened is that leakers misinterpreted the USB-C E-Marker as a MFi chip.
Or that Apple was considering a "made for iPhone" certification program to allow manufacturers of USB-C devices to certify that they'll work with iOS devices -- which would be a perfectly reasonable thing for them to have! -- and misinterpreted that as meaning that Apple intended to implement a restrictive device authorization scheme like they had for Lightning devices.
(Just because newer iOS devices have a USB-C port doesn't mean that all USB-C devices will work with them! Devices still require drivers; if iOS doesn't know how to handle a device, it won't work.)
Apple could fully comply with the letter and spirit of the DMA and remain profitable in the EU, but they would be less profitable. They probably have a very good estimate of how much less profitable, and they're doing their best to minimize the impact.
The fear of low-profitability is what drives that behavior, though. You're right that the DMA/DSA threatens Apple's bottom line, but as long as Apple continues to sell iPhone hardware in Europe then they should be turning a profit on hardware margins alone. Apple wants the control at any cost, and it's going to encourage more countries to draft even stronger legislation.
The DMA goes into force only tomorrow.
We will see if they will get away.
I guess they will get bonked, because they apply more favourable conditions for their own App Store.
They might get away if they would charge the fee for all Developers, but the Bullshit with "staying inside the old conditions" will surely get them into trouble
They can charge licensing fees for their SDKs, but the "core technology fee" is not structured that way. As currently structured, it would apply even to an app written from scratch in ARM assembly language (not that a reasonable person would build an iPhone app that way).
Making system/library calls to display something on the screen does not necessarily require the use of an SDK either; it might require quite a bit of reverse engineering work. As far as I understand copyright, that doesn't involve copying/distributing the library code and wouldn't be legally encumbered unless there's a patent covering it.
Unreal is a game engine, iOS is an operating system.
In almost every other case application software is not considered to be a derivative work of the operating system it runs on. If this wasn't the case, then Apple could have easily sued Cydia and AltStore for offering the equivalent of iOS fanfiction. Hell, even the Copyright Office was perfectly fine with adding a DMCA 1201 exemption for jailbreaking iPhones to install non-Apple software on them - and they're extremely tightfisted with those.
The reasons why this is different is very simple: you don't distribute Apple's SDK along with your application, but you do distribute Unreal's. The user got access to Apple's code when they bought their iPhone, you have to give them Unreal Engine, so you need a license for that.
The fee kills any real world possibility of an OSS App Store though.
1 million downloads for an app sounds like a lot for a paid app.
But on the desktop, popular OSS software packages do those kind of numbers in well under a year. There's no reason to believe OSS mobile apps on iPhone would be any different.
>The fear of low-profitability is what drives that behavior
Are you sure about that? Seems like a pretty bold statement where you would have to have some kind of inside information.
I don't have anything to substantiate this but I would like to believe that Apple still has the best interest of it's customers and security in mind when fighting these kinds of legislation. I switched from Android to Apple BECAUSE of those restrictions and the improved security the walled garden model provides. The other reason was the middle finger Apple gave to the cell providers about applying firmware updates to their phones. When I was using Android it was maddening to wait months for an update to be 'approved' and able to install. That led me to rooting and installing firmware that was outside of the manufactures control and who knows what might have been in that.
So for me everything that Apple does to keep a walled garden is what actually keeps me as a customer and helps their bottom line.
It does not seem to me that anything about the DMA will make it difficult for people who prefer to stay inside Apple's walled garden to do so. Most Android users only install apps from the Play Store and use Chrome as their browser.
Certain as I can be, without having seen the cards. Apple is a company about margins; you see it in their hardware profitability, but also in Tim Cook's service initiative. They fought Dutch regulators over this for months preceding the regulation, and it's not a stretch to say the DMA and DSA is a direct legislative response to Apple's wanton behavior.
Apple can move literal mountains, when it aligns with their incentive of increasing profit margins. Anything that falls outside that purview ends up sidelined or worse-yet, lobbied against.
> So for me everything that Apple does to keep a walled garden is what actually keeps me as a customer and helps their bottom line.
That's great, and Apple has every right to provide you a differentiated experience. I've been a historical Apple customer, and I still keep a Magic Trackpad around because it's mostly quite good.
But you and I aren't entitled to a sustained monopoly because it benefits us. Happy IE users or Bell Telephone customers aren't an argument against antitrust action, and it's ultimately entirely tangential to how legal they are.
Consider how Apple behaves in hardware, sponsoring dubious Chinese labor to make shareholders happy. They set industry-leading profit margins by sparing no expense in their exploitation of labor and parts manufacturing. Is it legal? They say so. But of course Apple would, and they have no incentive to ever stop the squeeze if shareholders cheer them on. They will behave just as insidiously with software, and if you do not treat their every action with that scrutiny then you'll pave the road to hell with good intentions.
I want businesses to be good people. I want God to run a killer froyo stand. But men are fickle, and Apple has been a swindling bastard of a company ever since Jobs cheated Woz out of $4,500 over an Atari contract.
> Does 20.1 percent market share constitute a monopoly?
Depends how it's used. Wabash v. Illinois set the precedent that a far-minority can be a monopoly if they block a government-designated common carrier. Europe's DMA doesn't even mention monopolies at all, and instead sets a new compliance bar for large tech-related companies. Japan's legislation is headed in the same direction.
Seems entirely feasible to me that the App Store or Safari policies could be seen as obstruction of a common service. Apple's de-facto tax hasn't been explicitly blocked in the US yet, but it also has never been explicitly sanctioned. Without guidelines like the DMA in place, Apple is flying blind against US regulators. Microsoft got trapped deep in that hall of mirrors, and nearly paid the ultimate price.
> Is that not what the free market does?
The free market is supplanted by a government that ensures that only a non-lethal portion of rat feces is processed into your container of SPAM or McDonalds meal. They prevent you from exposure to what businesses call, "profit maximization".
If you have a good government, they treat you a little better. They punish the companies that violate consumer rights and scrutinize anticompetitive behavior when it shows up. The free market chooses between regulated competitors; if you think that's unfair, you can move to a country without the rat-feces regulators and see how your breakfast tastes over there. Then we can all be happy.
> When companies make poor choices customers punish them. (Budweiser 2023)
Your evidence is proof to the contrary of your claim. Budweiser wasn't "punished" for making an anticompetitive move, they were boycott because insecure Budweiser customers had a slow news cycle. If Apple had customers protesting for the same reasons, they'd never even know.
"Poor choices" notwithstanding, Apple customers couldn't be assed if they were angry. Suicide nets go up at Foxconn and the harshest words HN or MacRumors can muster is 'poor choice of manufacturing partner'. Conscientious startups and their Macbooks, nary separated any easier than protesting trailer parks and Budweiser.
The issue isn't the size of Apple's market share, it's the tying between their hardware, the OS software, and app store, such that if you choose to buy their phone, you also are locked into their app store.
Apple is not subject to market forces because Apple is not a capitalist entity, it is a feudalist one. It is not a merchant buying metal and glass to turn into phones, it is a feudal lord that has put a gate on the river that anyone passing buy has to pay 30% in order to open.
> if you choose to buy their [device], you also are locked into their [software ecosystem].
Other than desktop computing, this describes nearly everything sold to consumers. For people in the Hacker News audience, desktop computing would feel like a gargantuan exception, but for most other people it isn't. Android is a partial exception, but one gets the sense from Google's recent behaviour that openness is an unwelcome vestige of its open source beginnings.
It's not an exception. Binary distribution is the norm - Apple founded their business on that norm, found success in it, fostered it and continues to support it on MacOS. The App Store style of distribution is not a replacement for it, especially when the escape hatches for developers cost an annual fee and still has limitations. If it takes legislation to change that, so be it. This is not the future for computing that anyone wanted.
If there's a good reason iOS can't run third-party software, now's the time to fix it. Otherwise, Apple might have to find a new economic zone to invest in.
Apple themselves distributed software as a binary before they had an App Store. If there was some other "norm" to speak of, it didn't exist when the Apple IIc hit shelves.
Correct, it didn't exist back then, because just about the only software a consumer would ever be exposed to was some kind of desktop computer. The closed model got its early start in the nineties when it became increasingly common for consumer devices to include software in their design.
Among the earliest examples of this emerging new normal in its gestational phase would be game consoles from the 16-bit era onwards. It also included just about all pre-smart cellular phones (but for occasional a rather pointless Java support), nearly all printers, nearly all camcorders, and so on. There are probably between 5 and 50 internet connected "computers" in the typical home and the typical consumer has some semblance of software control on maybe three of them.
Game consoles defend their software ecosystem because they don't have hardware margins (unlike Apple). Apple could try to use the console manufacturer defense, but they'd have to abandon their biggest cash cow to make it work.
> nearly all printers, nearly all camcorders, and so on.
I'm really starting to think nobody here read the Digital Service Act. Unless your toaster or smart-refrigerator is a gatekeeper platform with the required number of users, it doesn't matter. Apple is rightfully being called out for anticompetitive conduct, regardless of how you feel about the morality of an App Store.
If App Stores are the future, we'll have to Think Different and implement them in better way. Apple has their work cut out for them, the preemptive apologism falls on deaf ears.
> when they threatened to use MFi on USB-C, up until an EU Comissioner threatened to boot them from the market
Except this never happened.
And it doesn't even make any sense because MFi is when there is proprietary Apple technology involved which isn't the case for USB-C nor 3.5mm, Bluetooth etc.
Nope, that’s not what iA says, and it would be a gross misrepresentation of the DMA to be honest.
The section they’re referring to is clause 64 in the lead of the DMA[0] and it is not only limited to cases of interoperability, unlike what iA implies it doesn’t follow with a suggestion that gatekeepers can just ask if they’re unsure. Instead it states:
> In all cases, the gatekeeper and the requesting provider should ensure that interoperability does not undermine a high level of security and data protection in line with their obligations laid down in this Regulation and applicable Union law, in particular Regulation (EU) 2016/679 and Directive 2002/58/EC. The obligation related to interoperability should be without prejudice to the information and choices to be made available to end users of the number-independent interpersonal communication services of the gatekeeper and the requesting provider under this Regulation and other Union law, in particular Regulation (EU) 2016/679.
That’s why one of the main criticisms of the DMA is that gatekeepers generally can’t present proposals for approval and have to wait until after implementing to see if it is to the EC’s liking.
That said, the EU has inquired about the PWA stuff[1] and it seems that the outcome of that has been that Home Screen install doesn’t need to be provided for other browsers. Allowing Apple to back down from their careful interpretation.
That's not true. The section the blog post is quoting is saying that the EC can ask another regulatory body to make a decision specifically on whether the technical implementation of interoperability requirements is sufficient.
So it's only about a very thin slice of the DMA to start with, and a slice that's not the part that Apple was intending to violate when removing PWAs, but it's also not a process that Apple could trigger or even be a party of.
As far as I know, nothing in the regulation suggests that gatekeepers can get their compliance plans pre-approved or pre-rejected.
> That's not true. The section the blog post is quoting
That's the beauty of reading: you can read more than just the quote, and read the paragraph immediately after. Or the referenced section in the law: https://news.ycombinator.com/item?id=39565987
65 allows asking the EC for clarifications. But that process would (very explicitly) need to be public and allow input from third parties, there's no process for private feedback. In addition to that, the EC might choose to ignore the clarification requests entirely, and whatever decisions they do give are not binding.
It's certain that Apple does not have any kind of back channel approval for keeping PWAs Safari-only. That is not a possibility within the regulatory framework.
Apple didn't have to ask though, they fully knew they were breaking the law here. They are only backing down because of the pressure from the web community and from the DMA team starting an investigation.
The DMA plainly states that they have to give other browser vendors access to all features present on device, and that they cannot degrade the quality of their services.
Removing PWA support goes against both these obligations.
Firefox still supports them on Android, and macOS just introduced them (last year IIRC). In other words, every major OS has at least one implementation!
Devil's advocate: having a stable (maybe too stable) runtime for all iOS PWAs might actually be a benefit. Native apps, for instance, don't have to worry about rendering issues in various "viewers." This actually brings PWAs closer to the world of native apps, which I believe is what users would prefer.
That said, I literally did a jump for joy when the DMA news broke. (Then of course, I did scream bloody murder reading the details on PWAs.)
I'm not sure who backed off here, Apple or DMA officials. Apple's argument was that they wouldn't be able to enforce some privacy and security restrictions, if PWAs were running on a third-party browser engine. If DMA hadn't required PWAs to run on third-party browser engines, then Apple wouldn't have any concerns in the first place.
From [0]:
> “This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS,” Apple explains today.
Nowhere in Apple's statement or anywhere else does it say that the EU agrees with this. It's just Apple announcing a plan. I can imagine them being like "we showed we'd be willing to kill PWAs entirely, so they surely will be OK with our olive branch here and let us keep our WebKit restriction in place for PWAs"
But I'm not so sure. I certainly don't hope so.
The EU isn't stupid. They very much capable enough to see Apple's shenanigans for what they are.
I have to imagine Apple is in direct talks with EU regulators and passed this change by them and provided enough reasoning to do so. They might have even gave a concession in some other part of the OS to get this behavior greenlit.
I mean you'd think so, but my experience at another massive tech company during the GDPR transition period leads me to believe that this may not be the case.
Yes, but they also are smart enough to realize that the public can be swayed by Apple's shenanigans, and that sometimes you have to act low-key to not get the public opinion against you in these turbulent social times.
So glad they reversed that, it would have killed my side-project which I based around webapp push notifications just after they released PWA pushnotifications with iOS 16.4 not even 12 months ago. That backtrack would have been a punch in the face of all devs that jumped on that feature.
I feel like it’s still very useless and they implemented it in a way that makes it practically unusable.
“Apple's iOS has some limitations when it comes to push notifications. For example, iOS devices do not support background sync, which means that PWA push notifications cannot be delivered to the device when the user is not actively using the app. Additionally, iOS devices do not support silent push notifications, which means that notifications cannot be delivered to the device without the user's knowledge.
Another limitation of iOS devices is that PWA push notifications cannot be delivered to the lock screen. Instead, they are delivered to the notification center, which can be accessed by swiping down from the top of the screen. This means that users may see the notification later, which could result in missed messages.”
Apple will maliciously comply until people give up.
Your information regarding push seem outdated - both statements are NOT true. Since iOS 16.4 you can deliver push notifications even when the PWA is not actively in use. You need, however, to have the website added to the home screen (=PWA install in iOS world). I use both features on lockmeout.online - which core functionality is based on delivering push notifications on the lock screen. You need however to give permission/configure lockscreen notifications as with any other (non-PWA) app.
To anyone reading this as "the EU is okay with PWAs being restricted to Safari/Webkit":
(I've seen a couple of those comments go around here on HN)
I don't think so. Nowhere in Apple's announcement does it say "the EU is okay with this".
What Apple has announced today is a(n update to their) plan to comply with the DMA. The EU won't actually do anything until March 7th (the deadline for compliance). The fact that they did do something following Apple's announcements regarding PWAs just shows how obviously ludicrous those plans were. The EU recognized the urgency of the situation and acted [1] - If Apple would have shipped this update, many existing PWAs would stop working overnight, those apps would jump ship and offer their PWA in the App Store with (no way back?) and the damage to the reputation of PWAs would have been done: Apple would've sent a message that you can not rely on the web to reach your customers on iOS.
Nowhere does anyone say that the EU is OK with PWAs being restricted to WebKit. In fact, the DMA demands the opposite: Apple has to open up iOS to 3rd party browsers, and Apple can't self-preference Safari/WebKit for any of its features. Like, say, run PWAs.
I have read lots of comments and posts that said something along the lines of "Apple doesn't want other browsers to run Service Workers". That's not the reason for the attempt to remove PWAs on iOS. Service Workers are not PWA-only, every regular website in a browser tab can have a Service Worker. PWAs can be added to the home screen just fine without one. They are not mutually exclusive.
Apple removed PWA support so they would not have to open up the APIs to other browsers. Period.
So, to circle back to "the EU is okay with PWAs being restricted to Safari/Webkit":
I very much doubt it. Apple has announced a plan to comply, forgot to mention they were going to kill support for PWAs, then did confirm it (only took them 2 weeks), and now they backed down. We're back where we left off a month ago - and I believe the EU is very much going to have an opinion on the WebKit restriction Apple is trying to keep in place.
[1] The EU only announced they would start an investigation AFAIK, which is a long way from actually enforcing anything.
I think this is spot on. It might not seem like much, but the EU announcing they would open an investigation, during the beta of an OS is unheard of.
It's the kind of reactivity that might have surprised Apple, as it was a public response released even before the official answer to the current obviously malicious DMA compliance plan.
>Apple would've sent a message that you can not rely on the web to reach your customers on iOS.
I mean, given the rest of their malicious compliance over the paranoia of losing App store power, this seems to align with their goals. The only kink in this armor comes from old history where the Jobs era clearly didn't like the idea of the web on iPhone, but market forces made them add in all sort of specific exceptions and restrictions for browsers at the end of the day.
But that was in the Jobs era, nearly a decade ago. I can see them wanting to slowly try again.
>Apple removed PWA support so they would not have to open up the APIs to other browsers. Period.
All other browsers of... Mozilla? Most other people are perfectly fine staying in webkit land. Even Google probably wouldn't change much if IOS opened up.
Maybe, maybe not. It can also be explained by Apple wanting to do the minimum required. First choice: no PWA support at all, Second choice: PWA support independent of custom browser support, and final choice (most work): PWA support on top of the custom browser support.
The only thing we know for certain is Apple has shown no interest in making the best user experience given the rules vs complying with the rules only where required to.
That said, I doubt it here. they thought a feature was barely used and got enough flack to realize it may get them in deep wanted with DMA. But we don't know how strict they are with PWAs specifically. They probably backed off to prevent anymore of the various issues they caused themselves over this whole thing.
If so, it’s working. Now all the commenters who assume that Apple is doing the worst thing possible at all times are praising the EU for forcing Apple to save PWAs.
Otherwise they’d be complaining about how Apple was intentionally crippling PWA support by not letting you pick the rendering engine used.
As a fan of PWAs, I like the direction this is headed. Apple will both have to open up PWAs to other browser engines while increasing the abilities of PWAs in Safari. App developers will realize 80% of apps are fine as PWAs and it is a great way to avoid the app store.
For the time being, their excuse of not having enough time to validate and secure those capabilities seems valid. In a year, that won't seem as reasonable, and other browser engines will rightly complain.
Apparently the level of security required for home screen web apps can only be met by Apple. Because nobody else can be trusted to isolate the data of different web apps from each other.
I can tell from the phrasing that you don't agree with Apple on that, but just want to respond anyway. Apple will still be sandboxing the browser engines, so even if Apple doesn't trust the browser vendors, this still isn't a logical argument against allowing them to run PWAs.
It might not be practical for the OS to enforce sandboxes between multiple PWAs running on the same third party browser engines. Browsers are incredible resource hogs and loading many instances with perfect isolation enforced by the OS could result in a poor experience.
On Android I think PWAs do indeed share the same browser process. So it's like having another tab. Still, tab level isolation is taken extremely seriously by browser developers.
Runtime access, yes. But I’m assuming this is to also prevent cookie/storage sharing between PWA:s too, which third party browser vendors (well, Google) have incentive to allow and Apple wants to prevent.
Man that makes my day! I was prepared to not update to 17.4 and leave the Apple ecosystem in the longterm because of this, already checking out linux phones…same situation when they threatened to scan my photos. In both cases they reversed.
I will get an Android over this. I got an iPhone under the promise that I am the user, not the product. This seems is not the case anymore when it comes to Apple's services, such as the Appstore and iCloud.
The device, OS, and apps are also not any better, IMO.
I will aldo be trying android next round. I remember i had a samsung xcover back in the days and it handled touch in the rain. If there is a droplet of water on ypur thumb the iphone freaks out. Also mich more spelli g errors and slower typing. The only thing missi g is hide email and private relay
I think you could also argue the opposite — ie it’s precisely because Apple wants you to not be the product that they’re putting so much effort into preventing competing services from being able to spy on your PWA data.
Not coming down on either side, just pointing out the argument exists for both.
I would believe this line of argument much more if they didn't keep hiring ad sales people and if advertising wasn't a growing part of their services revenue.
After using an iPhone for more than 7 years, I started using Android again, close to 1.5 years now. Honestly don't miss a thing. I have realized I don't care about mobile or desktop OS these days. I use the same apps everywhere. Although browser experience is much better on Android.
Three physical buttons at the bottom are much better user experience than apple, where the back is somewhere on top of the phone. Maybe that design worked when Jobs was alive and artificially kept them small, but it just makes it feel like those phones were toys for kids.
On a side note, I would also like a physical "forward" button, to jump through some screens faster.
> Three physical buttons at the bottom are much better user experience than apple, where the back is somewhere on top of the phone.
If the app is a native iOS app, or at least built following Apple’s design guidelines, then swiping right will always navigate back in any app. It’s a universal gesture, and this is one way to easily spot apps that weren’t built for iOS.
Apple will give per-app prompts for system resources like location, but does not really have an iOS 'app prompts for permission to manipulate another app'.
These sorts of permissions are confusing to users, they imply an execution model where both apps will be guaranteed to be runnable side-by-side (rather than one suspended while the other executes), and provide efficient vectors to share privacy/tracking information across those boundaries about the user.
Browser extensions aren't web apps. It's a definitional thing. The whole model of the PWA is that it's an app implemented using only the fixed set of features, authentication and authorization mechanisms defined by the relevant standards, and thus requires no human to specifically audit and permit the installation. Anyone can put up a web app and run it on anyone's device, and we're all safe (modulo bugs).
Extensions can in principle do anything the browser can, like snoop on traffic with foreign sites, etc... They have more capability (for good reason!), but require some level of authorization to happen by the user and (usually) OS vendor to make sure nothing bad happens. And bad things happen anyway.
The fact that this could be so easily reversed probably provides evidence in favor of the argument that this was a purely punitive move by Apple as a way of throwing a tantrum against DMA. Somewhat akin to an abusive spouse saying "See! You _made_ me hit you!"
If this sort of behavior doesn't ring alarm bells in the minds of the regulators I don't know what will.
Given that reversing course here means "Home Screen web apps continue to be built directly on WebKit", this pivot doesn't actually contradict their claim that safely supporting PWAs from other engines was too much engineering work.
My hunch is that the initial change may have been performative, but it was likely performative for the EU regulators and not the customers. This pivot presumably means that the EU has now okayed browser engine lock in for PWAs.
This is not a reversal. They are allowing PWAs built on webkit, not other browser engines. Their argument was that they cannot reliably make sure that installing a webapp on other browser engines is secure. And that they do not have a way to do so reliably before the deadline, and other important things (with more uses)take priority. On Webkit, they already did it ages ago.
In a few months, once we see newer browser engines on iOS, we will see calls that it is unfair Apple allows for one kind of web apps (on their own browser engine) but not others and that is self-preferencing.
And yet you can run any browser engine on MacOS and the world hasn’t ended. This is a cash grab, it’s not about security and I don’t understand why people keep repeating that.
Because MacOs is around 10 to 15% market share it make sense to use every incentive available to attract developers to another platform than Windows. There is a hidden technology fee, but it make more sense not to charge for it.
iOS is more like 50 to 55% market share so the goal is more to filter out bad actors and keep a high standard. Also let's milk that cash-cow.
I'm not necessarily agreeing with this approach but I got to admit it makes sense.
Because they don’t have to sell on the Mac App Store, they can use their own website. That has nothing to do with other browser engines being available.
And they still must pay the 100$ annually to sign and notarize.
And they have different attack surfaces and vulnerabilities. In the abstract, our phones are (for better or worse) far more critical to our lives than our laptops. They go with us everywhere, they're increasingly our keys for various physical and digital access. They're off-board brains and backup. Generally speaking, I would say a compromised phone puts the average person in a worse situation than a compromised laptop.
Fine, but where’s the evidence alternate browser engines are such a massive security risk? I see none, but I see many billions of dollars Apple is making from applying a 30% tax on any app I buy. And to be clear, consumers pay that 30%, developers pass it on.
The consumer would switch their PWA default engine in one of the half dozen "you have to agree to continue" buttons when Edge and Chrome install themselves and demand every privacy and security toggle be turned off (as Microsoft Teams demands when you try to run it in Safari*), and then all PWAs would be insecure and monitored by the adtech engines.
This weird idea to force Apple to have OS viewports use a foreign engine would not be 99.9% of users' real choice at all, just like the users who installed Avast anti-virus didn't choose to have all their browsing sold to adtech, or the users who chose "Private Browsing" in Chrome didn't choose to have Google recording that activity to the user's profile.
* Note: Because Teams is actually "just" a skin on many different services and the Apple+CloudFlare private browsing confuse the coupling.
> The consumer would switch their PWA default engine in one of the half dozen "you have to agree to continue" buttons when Edge and Chrome install themselves and demand every privacy and security toggle be turned off (as Microsoft Teams demands when you try to run it in Safari), and then all PWAs would be insecure and monitored by the adtech engines.*
I suggest Apple takes inspiration from Android then, since that doesn't happen on Android. Maybe Android's security model is better.
This is solely about Apple getting a cut of App Store sales. They’ve been in cahoots with Google for years, as evidenced by the recent DoJ monopoly trial - “privacy” and “security” are marketing terms at Apple. Nothing more.
> This weird idea to force Apple to have OS viewports use a foreign engine
That is not what people are saying. Nobody cares that MacOS renders half its content using WebKit on Mac. Same goes for iOS - people do care that they can't use a PWA in their browser of choice. It's anticompetitive blockage that will be inevitably brought-up when the compliance deadline rolls around.
> would not be 99.9% of users' real choice at all
No reasonable person can claim that. Alternative browser engines aren't even allowed yet, you don't know that.
> just like the users who installed Avast anti-virus didn't choose to have all their browsing sold to adtech, or the users who chose "Private Browsing" in Chrome didn't choose to have Google recording that activity to the user's profile.
Or the people who left notifications on and got their iPhone information slurped up by the NSA. Pobody's nerfect, right? Get the strawmen out of here before they start a fire.
> Nobody cares that MacOS renders half its content using WebKit on Mac. Same goes for iOS - people do care that they can't use a PWA in their browser of choice.
What does it mean to "use a PWA in their browser"? That's the opposite of what the PWA experience is supposed to be. You're not supposed to be aware you're in a browser -- and "people" defined as normals, not HN users, do are not.
The "reasonability" of my view about what consumers care about is informed by building both enterprise and mass market web, and later app, products since the 90s, helping countless clients study their users' actual preferences in depth.
Our, and well known, studies show the "man on the street" has zero comprehension of what a browser engine is much less how a PWA or even Electron works. In general, their priority is everything just working and tech being out of their way.
HN is among the least representative forums for recognizing "normal" user interests I've seen, almost to the point of parody.
> Get the strawmen out of here
Avast and Google debacles are first party software provider exploitations of user trust, not targeted surveillance or dragnet by a government. Lockdown mode shows the length to which Apple takes this class of problem seriously as well.
> What does it mean to "use a PWA in their browser"? That's the opposite of what the PWA experience is supposed to be.
What does it mean to use a PWA without a browser? It's impossible to operate without an HTML engine and accompanying logic.
Even playing by your logic, there should be an equal and fair opportunity for third-parties to make the same experience. That's what the DMA and DSA are all about, when you boil them down. If Apple has a button that lets you open PWAs in their engine, others should get the same opportunity. Web apps are portable, this is the design of the web as a whole. Apple can make it a problem in their browser or a problem in their OS, but it remains a problem all the same.
> Our, and well known, studies show the "man on the street" has zero comprehension of what a browser engine is much less how a PWA or even Electron works.
> HN is among the least representative forums for recognizing "normal" user interests I've seen, almost to the point of parody.
Then why bring up the users at all? Let's discuss these solutions on their technical merit, since we're on a technical forum. Apple's defense is paper-thin here, and your "runtime" rationalization doesn't work for any other platform, let alone the open web.
> Avast and Google debacles are first party software provider exploitations of user trust
So... your defense of Apple's failure is that they provide Lockdown mode? Shit, I might as well cite GDPR and Google Takeout if I had any interest in defending the sycophants.
Apple's debacles are an example of first-party exploitation of trust. If their definition of local security and individual privacy is subject to third-party demands, then they are fundamentally compromised. You're utterly detached if you think Apple's got a humanitarian heart for the Chinese citizens they help implicate. Lockdown Mode won't save them.
It's 100% a reversal. Their previous statement was: "we will remove PWA support". Their new statement: "we won't remove PWA support, we will keep PWAs as they were in 17.3".
eh, you're both right. It's a 100% reversal of their decision to remove PWA support, but it's 100% consistent with their previous excuse/reason of it being too hard to support multiple browsers.
> we will see calls that it is unfair Apple allows for one kind of web apps (on their own browser engine) but not others and that is self-preferencing.
We have been seeing people say that for years. And mostly, they've been right; Apple's treatment of WebKit and Safari was anti-PWA for years. Even today, Apple has zero competitors who could meaningfully encourage them to adopt new PWA features or change Safari on iPhone.
I think they’ll keep pushing their luck but it’s not in a vacuum - Microsoft, Google, and Meta have been dealing with EU regulators a lot longer and on a much deeper level. They will see Apple’s missteps and use that towards their own benefit by gaming the refs.
Ironically, Microsoft now has a fairly good argument that Apple is abusing its OS control to stifle competition in web browsers. What a world!
Apple is playing checkers, Brad Smith is playing chess.
they didn't need to remove a capability they already had, so any lawyer clarification would be on if they would be punished for being anticompetitive by removing the capability
Except they have had to do this multiple times (although usually patents).
Examples include portions of AirPrint functionality on macOS, Bootcamp suspend/resume, and FaceTime peer-to-peer. The latter being the reason that Apple did not open up FaceTime as a broader industry initiative.
In the US we currently have Apple Watch being sold without access to the blood oxygen feature due to an import restriction.
There are also restrictions on showing certain maps in certain countries, as well as whether or not the Taiwan flag emoji displays in China.
So..you've never written software with a lawyer standing over your shoulder?
Very often legal requirements lead to removal of features that cannot easily comply rather than expansion of the feature to comply. Removal is less rick.
I won't say it is malicious. But I won't give Apple a pass either.
Ultimately, the truth is that a company like Apple doesn't want to deal with DMA. Their whole services business model (whether it be the App Store monopoly or the iMessage monopoly) relies on behavior that is counter to DMA.
It's also clear from their seething press releases about the DMA that they don't want to mince words about how much they don't like it or don't want to do it.
It's always easy for them to give a vague privacy / security argument to justify whatever benefits their monopolistic control. It's no different from the "Think of the children!" style of reasoning that politicians use to get what they want.
I think it's important for users to keep calling them out at every opportunity so they don't get away with it.
You’re the one who’s ascribing maliciousness to their actions. But you don’t have that backed up by anything concrete other than your subjective perception.
From what they’ve written they removed it initially to keep all browsers equal, which is what the DMA implies is necessary.
They now brought it back with only WebKit support.
It’s completely logical that their lawyers worked with the EU to clear this exception.
People here ascribe too much in the way of human emotion to corporations.
If they were really trying to kill PWAs they’d have done it everywhere. If they were really trying to stick it to the DMA, PWAs are such an insignificant feature to do it with.
What are the percentage of people who’d be so inconvenienced that the PWA would open in a browser tab instead of a pseudo browser instance?
> It's no different from the "Think of the children!" style of reasoning that politicians use to get what they want.
It is very different. The outcome from “think of the children” is loss of privacy, while Apple’s actions means loss of software functionality. The former is more dangerous for society and freedom of thought.
How can we be certain that Apple's actions don't mean a loss of privacy too? Whenever they're asked about seriously decentralizing their own trust model Apple tends to fall back on the "legal compliance" note, if not directly on think-of-the-children. Their lack of transparency (even the base level that Google provides with the AOSP) isn't very reassuring, at least to me.
Now, one could argue that Apple's decisions are less impactful than politicians. Circumstantially, they may be right, but I think it's appropriate to compare the line of reasoning. After all, Apple employs both.
IMO it would be better to avoid the language of spousal abuse and physical violence when describing what are actually dry business decisions. It kind of cheapens the real physical harm befalls vulnerable people.
The real fight is to get major online services to have safe and available noscript/basic (x)html portals. Because running on google blink|geeko or apple webkit is no better than native google|apple apps.
Now I'm glad I wrote that email to Tim Cook about this. Seems like the general backslash they got was so big that even Apple (which, I would add, always knows better) bent.
It should be obvious to everyone that Apple is Microsoft of the 1990s vintage. There isn't a lot of innovation in hardware that requires huge numbers of people to upgrade their phones and laptops as often as they did before. This requires services revenue to make up for it, and Apple is taking very aggressive tactics to ensure the App Store cash cow continues. They are fighting in every battlefield and spending enormous legal and tactical resources to do so. Any wedge into their closed ecosystem, from alternative app stores to side loading to web apps to alternative payment rails, must be prevented at all costs.
For people using Windows, Microsoft of the 2020s is also like Microsoft of the 1990s, and possibly even worse. All the bundled apps, cloud requirements, “accidental” pushes of features that people had already declined, telemetry, etc.
I'll chime in and say I'm not really interested in who's worse. Microsoft, Apple, and Google are all abusive in their own ways and should all be broken up.
When talking about antitrust it's very easy to slip into comparing companies (the Apple vs Windows narrative is one that Apple ingrained into culture for years), but all of these companies are terrible and we are fully capable of pursuing antitrust against all of them simultaneously. They don't have to be ranked.
I think we might see third party browser support for PWAs soon in iOS. Maybe with the next major iOS release. This might've been a stunt to delay that feature and buy them some time and plausible deniability that they tried their best and it just took longer than expected, because of poor decision making.
Honest question: why PWAs? As a user it's a lose/lose situation for me. I don't get a nice solid/stable native up and it will use up resources wastefully because of blink/webkit/gecko running nth process on the device and draining battery, the app's data is intertwined with web stuff which inclues a lot if anti-privacy and dynamic content not reviewed by the app store but like normal apps now has access to sensors, files,etc...
My opinion is that it makes life easier for devs and surveillance capitalists but not users. Am I incorrect? If so, why? For privacy, security and performance wouldn't native apps beat PWAs? Aside from the whole anti-apple bandwagon, why is the EU invested in enforcing this?
What's in it for you as a user is that the app exists at all. A lot of apps either aren't meant to be profitable (government services apps, ngos etc) or won't be profitable enough after paying for developing the app 3x. Building them as a PWA is what makes them viable at all.
If users are willing to pay the extra cost for a carefully handcrafted native app for any particular use case the market will step up and provide it.
Mostly this. Sandboxing on basically every single modern browser is better than sandboxing on mobile devices. Nearly any app that's delivered as a PWA is going to have better privacy guarantees than an equivalent native app.
The difficulty of course being that PWA limitations make many offline-only or account-free apps nearly impossible to build as PWAs.
Making a native app that's as cross platform as an Electron app is much more difficult than making an Electron app, from objective burden of work to finding the required talent.
We only have Discord and Slack on Linux (as an installable application out of the browser) because it's Electron-based.
It's an excellent distribution mechanism for apps that you don't want listed on the app store, or ones that won't be approved, or can't be distributed eg. Company/Internal apps (that are installed on employee's personal devices)
tracking can be done in either platform. but if there is tracking in an app you have no way to block it. in webapps you can block tracking with the browser.
I am not sure if pwa's are so bad on ressources. i haven't used pwa's or just to try it out. I don't like to have too many apps on my phone anymore, so i like webapps. i'd rather use a webapp. it doesn't use space on the phone and does not clutter. I think in that way i am old fashioned.
Agreed. Any time there's an option for something that could be native to instead be web-based, it's a loss for users.
And as far as cross platform stuff goes, may as well just keep it in a browser. Would rather have eight web apps and two native desktop programs than ten electron apps.
Until there is a nocript/basic (x)html browser, critical online services should be fine (if they have the decency to provide not only google/apple apps).
i agree. apple wants to control everything from how the users use the devices to what developers are allowed to do. android is much more open for users to do what they want.
People like you are an extreme minority. Most people just want a phone that works and that doesn’t get ‘viruses’. iOS accomplishes that; macOS does not.
Because this article decided not to do so, lets be very clear to give credit where it is due: The Open Web Advocacy group, who has been working for years with regulators around the world, and led this particular fight with an open letter to Tim Cook. It received 5500+ signatures in 3 days.
There were news that the EU has begun to ask for developers' opinions about the death of PWAs too. Apple doesn't want the EU to ask for developers' opinions.
For sure Apple doesn't want anyone to know how it has crippled the web for over a decade, prevented browser competition, and just tried to kill web apps once and for good, that's why they tried to sneak this change without even making it public before two weeks after it was introduced in iOS beta.
As absurd as it is, Apple forcing people to use Webkit/Safari is, at the moment, good for the browser landscape. You already have websites that say browsers that aren't chromium aren't supported, if iOS didn't force Safari on people this would be way more common as people would flock to chrome and websites decide it isn't worth it to support other browsers.
I use Firefox on my non-work machines ... in an ideal world, enough people would do that to prevent the "best in Internet Explorer" web of the dark ages, but I'll take getting forced to use Webkit on my phone over that, even if I'd prefer a "true" Firefox.
> You already have websites that say browsers that aren't chromium aren't supported
Is Webkit really so far diverged from Blink that the rendering result is different? I realize that Webkit doesn't support a bunch of stuff that Google pushed into Blink (like Web bluetooth, for instance), but I thought the end result wasn't that different.
Blink was forked 12 years ago, and the size of the team behind Chrome is probably at least ten times the size of the team behind Safari. So yes, there are major differences between two, and it's not just additional advanced APIs like Web Bluetooth. WebKit is lagging behind in all areas and ridden with bugs.
I doubt it's "at least 10 times the size" and probably somewhere closer to 5X tops with a 2X core that's the realistic measure since those are the non-rotating folks with real expertise who make things go. That team is probably about the same size as Mozilla's which is also non-rotating.
There are enough weird divergences to make targeting iOS annoying. Off the top of my head I can recall that Safari PWAs can't get callbacks from pages spawned in a new window. Things have a tendency to fail in strange and unexpected ways.
Worse yet, many people have older iPhones with outdated Safari. You can't tell them to just install another browser, because under the hood Apple mandates that all other browsers are still the same outdated Safari engine.
If you want to track these issues down, you need to invest in an Apple based set up. You can't run Safari outside of the Apple ecosystem to track these issues down. It is bad enough that people are now offering pay as you go Safari instances for testing. Apple gatekeeps, Apple invents problems and developers are stuck with the bag.
Apple banning browser engines is what has prevented the web from becoming relevant on mobile, and the reason why browsers like Firefox cannot distinguish themselves from Safari and end up becoming irrelevant.
So no, it is not in anyway good for the browser landscape or the web, it only serves the interest of one company: Apple.
Look at some overall browser/os usage stats and say again that the web isn't relevant on mobile, and look at browser usage stats for desktop and android and claim again that firefox would have a relevant market share on ios if browser choice was free. Those claims seem pretty disconnected from reality.
I don’t think WebKit is garbage. That title belongs to Gecko. Apple picked up their slack with Safari a long time ago. They do have faults with these decisions to intentionally break or not support some features for years, like Push Notificafions.
Whether it's garbage or not ultimately doesn't matter much. What's more important is the fact that it's the only choice for users on iOS right now.
WebKit will never have an incentive to get improved without healthy competition.
That's right, it doesn't matter! What's important is that pretty soon Chrome will be the only choice for iOS users as websites migrate over to requiring it, just like they started requiring IE back in the day.
I, for one, am eagerly anticipating unlocking the full monetization potential of the web with the demise of functional adblockers like uBO! No longer will Google be forced to support adblockers to remain competitive with Webkit and Gekko! Developers rejoice!
Thank you open-web-advocacy.org for finally killing off all browser competition! You are doing god's work, son.
> What's important is that pretty soon Chrome will be the only choice for iOS users as websites migrate over to requiring it
Meh, people say this, but what exactly is Safari doing to push back against Chrome hegemony? Supporting Chrome/Safari is still less work than supporting Chrome/Safari/Firefox. And in the meantime, Safari has a more restrictive adblocking API than Chrome (which is saying something), is pushing device attestation in the browser for circumventing captchas (which would be a death-knell for Firefox), and can't be run on non-Apple devices. And it gets billions of dollars every year from Google to influence its search engine (which weirdly enough, is a criticism that only gets lobbed at Firefox despite the fact that Apple gets way more Google money).
I'm convinced that the only thing that Safari exclusivity is going to guarantee is that websites list 2 supported browsers instead of 1, as well as giving Google more ammo to use when it inevitably tries to push device attestation for the web a second time. "But Apple did it" was already a common refrain during Google's last attempt.
Apple doesn't play well with other standards-makers and isn't taking a proactive role right now in the web standards process. In that vacuum, Chrome dominates and pushes anti-user specifications. So yes, Safari is an alternative to Chrome, but I'm not convinced it's a useful one or that it's doing anything to push for progressive enhancement or to push against user-agent sniffing. Does it really matter if there's an alternative to Chrome if it's only available on iOS, has a terrible extension API, and leaves every single other device to be Chrome-exclusive?
We need to break Chrome off from Google and examine the anti-competitive privileging that Google performs in Chrome. Safari isn't a substitute for that. Relying on Safari to hold off Chrome is effectively the same thing as ceding control of the web to Chrome.
> Mozilla and Google managed to reverse browser monopolies by just being better.
Mozilla has reversed a browser monopoly? When? Do you mean back in the late 90's when Mozilla's predecessor (Netscape) lost their monopoly to IE? I guess that's technically true they reversed a monopoly back then... but that's not exactly helping your argument.
Google did it not by creating a good web browser, but by forcing their browser on users of the most heavily-trafficked search site and video steaming site (by breaking features for those who used a different browser). You know, the very same anti-competitive arguments that so many people are wringing their hands about.
> Why can't Apple?
Safari already is a better browser... for users. I'm sorry that it doesn't have let you do the same tracking bullshit that you can do in Chrome, but having Bluetooth and serial number APIs is not something I want in my browser. I'm ever so sorry that it breaks all the cross-site tracking cookies.
The reason Apple can't reverse a monopoly with a better browser is that:
1. Safari is for iOS and MacOS only. By definition it won't ever rise above the user base of those OSs, which are a small minority in almost all markets. That is also why you don't have to worry about it become it's own monopoly, like Chrome did.
2. Safari won't add all the user tracking bullshit you want because that is the whole proposition of Apple's ecosystem. You seem to have forgotten what a browser is: It's a user agent. It's supposed to work for the user. But if website owners have the option to steer everyone to the browser that lets them reach into the operating system and pull out the device serial number, they'll do that.
> Why is Apple entitled for a free pass on forcing browsers down their users throat?
1. We often let minority players do things that we would not let a monopolist do. For example, Spotify is a gatekeeper to music streaming in the EU (I have to license to them if I want to stream my music to any significant number of EU customers), but the DMA does not apply because they are too small. Apple is a small minority player in the browser market, too.
2. Building a Chrome-only website (and enforcing that with DRM) today is a non-starter because it means shutting out the small but lucrative Apple customer base. But if iOS users have the option to use Chrome, websites can force visitors to use Chrome instead. Maybe Google will even pay higher ad rates to sites when the customer is a "verified real person". Google will have a hard time determining who a real person when they aren't using Chrome... but I'm sure that won't incentivize websites to steer users to Chrome, right?
3. If users don't like Safari they have the freedom to pick a different platform. If users don't like Chrome, they have a degraded experience with the primary purpose of a web browser: To visit certain websites.
When Safari is dead and your web browser has become a TV, you can thank the standup folks at Open Web Advocacy organization. It would be so simple to add a provision to the DMA that website owners are not allowed to steer users to a different web browser... yet they don't. Funny, isn't it? I guess this isn't really about anti-competitive behavior after all.
>Mozilla has reversed a browser monopoly? When? Do you mean back in the late 90's when Mozilla's predecessor (Netscape) lost their monopoly to IE? I guess that's technically true they reversed a monopoly back then... but that's not exactly helping your argument.
This later graph (from the same Wiki article) covers 2009-2022, and is much more telling: once Chrome launches, it overtakes Firefox in two years, and then IE in another year. By the time Firefox manages to overtake IE, it’s fighting for third and has only ~15% market share.
Today, Chrome has ~66% market share, and it’s somewhat clear that the remaining 34% of non-Chrome traffic is mostly iOS/Safari. Apple is absolutely being anti-competitive, but that anti-competitive position is the only thing blocking Google from taking control of client and forcing a browser monoculture.
The claim I addressed was "Firefox has never reversed a browser monopoly" (paraphrased - the original comment had much more derision and snark).
Obviously the person who made this comment was unaware of Firefox single handedly kickstarting the new browser wars (and the removal of IE as the only option).
I still think it's a bit of a reach to say that Firefox "reversed a browser monopoly" -- while 30% was significant, MSIE remained utterly dominant until Chrome hit the market, especially once Google started pushing the browser via their various properties.
Well, you're wrong. A monopoly is when there are no viable alternatives. "Mono" meaning "one".
Firefox presented not only a viable alternative, but was a demonstrably better browser. According to this site [0] Firefox peaked at 47.5% (vs IE 40.2%).
> Safari already is a better browser... for users.
Bold claim, wanna know how we test it? We let Safari compete with other browsers like it does on Mac. And having spent a lot of time around startups, I can assure you that the majority of Mac developers I've seen aren't daily-driving Safari.
> When Safari is dead and your web browser has become a TV, you can thank the standup folks at Open Web Advocacy organization.
If Apple is the only thing enabling an Open Web, then our web was never open to begin with. Let Safari die, for all I care. Maybe it will encourage Apple to try something different.
I don't trust commercial apps for something like this, sorry.
Gotta be public code and public block lists.
Also "Wipr blocks all ads ... EU cookie and GDPR notices".
That's another no. I want to see those notices so I can make an opinion on how predatory a web site is by how complex they have made their cookie dialog.
Nah, that open web advocacy place uses slimy tactics to muddy the situation while omitting details. Just look at that article you linked to: calling PWAs "web apps" is super misleading.
Great work everybody. I had people literally laughing at me for helping get the word out, saying that it would be impossible to influence a behemoth like Apple.
This goes to show the power that people have when they get together and fight for a common cause.
But the work isn't done! Keep following OWA for news and ways to keep pressuring Apple and the other tech giants in favour of an open, competitive and capable Web.
I was gonna say this.
They need to allow third party browsers the ability to create PWAs, but they can't (or don't want to).
So instead they just disabled it, saying that it was not possible, and wait for the backlash to restore it for them only.
Now we are at the beginning, PWAs are locked to Apple...but apparently that's good? I don't understand...
If this was their plan it’s not a good one. There’s no indication that the EU was interested in PWAs before this, but now Apple have made it a cause célèbre and brought the issue to the attention of the EU.
OWA says the plan was maliciously neglecting to mention the "killing" of PWAs. Hanlon's razor would require us to assume there was no malice and that there was mention because there was no such plan.
Mostly Apple wants to ensure that PWAs can't emerge as a viable option. As long as they're on WebKit, they can ensure that the apps are limited in their functionality.
PWA’s can run a ServiceWorker in the background too, I can imagine Apple does not want anyone to be able to run code they don’t control as a background task as this may negatively affect overall performance and battery life.
Apple not wanting PWA to work properly on iPhones has nothing to do with performance, security, privacy, battery life or whatever excuse they may officially come up with.
The only reason Apple does not want PWA is because it threatens their App Store profit.
Only one of the options affects the bottom line of Apple. Incentives incentives incentives. When you want to understand what and why people do what they do, always find out the incentives.
Web apps were the first apps that Apple supported on the iPhone, as of 2007. Back then they did not have native apps, that's why they bothered supporting them.
They then realized that they could make much more money with locked-down proprietary apps that they could tax at will through their App Store. Since then Apple has blocked any meaningful evolution of web apps, to prevent them from competing with native apps.
1) From a regulation standpoint, it's in Apple's interest for PWA's to exist; Apple has used the argument in court that PWA's are a viable alternative to it's App Store and therefore it does not have a monopoly on iOS "apps".
2) From a financial standpoint, it's in Apple's interest for the PWA experience to be sub-par.
PWA’s are not at all the same thing as the “pin to Home Screen” feature in iOS 1.0.
PWA’s were a brand new subsystem introduced in iOS 11 with substantial (yet not emough) ongoing investment since then.
The conspiracy theory still doesn’t answer “why have then been investing in PWA’s since iOS 11?”, if they wanted them dead they could have just removed them rather than doing incremental enhancements.
Misalignment of the company bottom line (incentives) and employees bottom line (incentives). Company gets money from variable App Store revenue which is directly threatened by PWAs. Employees get money from fixed monthly salary, which is only indirectly threatened by PWAs.
Employees take money and do what is required of them, and otherwise do what they think is awesome. Employees think PWAs are awesome so PWAs happen... until they threaten almighty App Store then it stops.
> Company gets money from variable App Store revenue which is directly threatened by PWAs.
I don't see how a PWA-enabled Safari fits into this narrative.
Timeline:
0) Apple hires key people and invests 4 years in PWA support for Safari on iOS.
1) Apple releases support for PWAs in Safari for iOS worldwide.
2) The DMA compliance thing happens.
3) Apple allows alternative browser engines + disables PWAs in the EU.
4) Apple rolls back PWA disablement in the EU.
I mean, 0 and 1 are not some skunkwork. It hasn't been sneaked into the release. PWA support predates this DMA drama. It was disabled only in the EU.
PWAs challenging App Store revenue is completely orthogonal to them being Safari-exclusive or not. PWA support for iOS has been invested on, released, enabled, and has even more features coming up and prereleased in the tech preview. Nobody forced Apple to do that. That alone is solid material fact, blowing away hypothetical claims of evil intent.
>Nobody forced Apple to do that. That alone is solid material fact, blowing away hypothetical claims of evil intent.
Apple has been actively using the existence of PWA's as an argument in court that it's App Store does not have a monopoly on iOS app distribution. So, yes... It's likely Apple want's PWA's to exist on iOS.
It's also very likely (given their financial incentives) that they don't want them to be a very good experience.
Are they not incentivized to maintain battery life? Perception of battery life impacts sales. You can't sell App Store apps without phone sales. Yadda yadda yadda. You can argue this towards any preconceived notion you want here. Nobody has any actual evidence, despite all the absolutism in their posturing.
What is boring is pretending that technical considerations about battery life play anywhere near as decisive a role in this matter as simply protecting a multi-billion dollar line item that is app store revenue.
Black and white? Apple not allowing other browsers to have their own browser engines is a black-and-white decision. All or nothing. Apple or nothing. It's all about what Apple wants, and that's MONEY. They don't care about anything else by keeping other browser engines off their platform. It doesn't matter what stupid reason they spout off. It's always about money. Allowing functional PWAs and other browser engines on their walled-garden platform will mean they make less money from their app store. That's it, that's literally all this is about.
No, I mean MONEY in any form. Apple doesn't really care about users or developers, all they care about is money. They have proven again and again that they will hobble the product if it means they can make more money.
Right, right; everything is 100% black or 100% white. There is no nuance to anything around Apple, and no point in even thinking about the reasons they give, let alone recognizing where they have a good point, whether or not that point outweighs the arguments against it.
...Like, seriously? I can fully understand disliking Apple, and disagreeing with their choices, but to claim that none of Apple's stated concerns—which are perfectly reasonable on their face, regardless of whether you consider their weight to be sufficient to justify the choice—are legitimate at all? That they are only concerned with profit?
Service Workers (SW) and installable PWAs are two different things.
Regular sites in browser tabs can have SWs.
When the full Chrome(ium) or FF hits iOS (engine and all), they will want to run SW. And, if I understand the DMA correctly, Apple will be forced to make that possible for 3rd party browser engines.
If that's Apple's motivation, why have they been implementing PWAs at all? Killing them would be even simpler if they just weren't on iOS in the first place.
They’ve been on iOS since the beginning, predating the App Store. They were originally supposed to be the only public API for building 3rd party apps on iOS.
For a long time they appeared to be in maintenance mode on iOS. They’re still years behind what Chrome allows PWAs to do.
Apple has also added PWA to Desktop Safari in the latest OS release (which seems to work well for Tana). So their Safari team is putting some continuing effort behind PWA in general.
I used this when I was taking a break from chrome, because Firefox cancelled their PWA support for Desktop.
So... you're saying that having PWAs is purely performative because nobody actually uses PWAs... meaning that the loss of PWAs has no impact on customers?
As far as I'm concerned, it's just an argument for them to use in antitrust lawsuits. "See, they could have developed a web app if they aren't happy with our store". It's better to keep an option opened, especially if it's not good enough to be used.
Yes. Would you rather install a full-on app for a once-off event (concert, festival or conference) or would you rather just install a light-weight PWA or just use the website?
I have attended conferences that can be described as "scrappy": flakey oversubscribed wifi, lots of interesting talks and multiple "streams" in different rooms over 2-3 days in a foreign country where my visit was too short to bother to buy a SIM card. Being apple to see the schedule offline would have been a boon, a problem that can be effectively solved by PWAs.
Any app that's geared towards visitors or tourists is better served as a PWA - think of the apps used to pay for transit, or parking in a city you're visiting. A website is Ok, but offline access and a shortcut on the homescreen would be better.
Just one user's opinion. I'd just use the web site for a one-off event. But if I had to install something for some reason, I probably wouldn't care what technology it was made with and would only care if there was a functionality or performance difference. Honestly, nobody but web developers cares about PWAs. If you put a gun to my head and made me choose between Native and PWA, I guess I'd choose a native app that looks and feels like a native app, performs like a native app, uses native controls and UX idioms, and has the security guarantees of a native app. I honestly don't think users's really care about this PWA vs. Native App war that web developers insist on making a big deal over.
Because it's technically a separate app in ios system, with all storage separation, permission… etc. enforced by the system itself. And ios don't actually allow any app to install another app unlike Android. The pwa install process is a somewhat backdoor build into safari and ios for this specific usage and never made public at first place.
To make this work with another browser. They would need to fix this, make a safe public api for it, and publish it in new ios version. (Which they think it's way too much work and rather want to get rid of it instead)
Browser can do the exact same thing as a PWA app. It's using the same web APIs.
Edit: don't know why I am getting downvoted. A web page can do exaxt same thing as a PWA. Access camera,mic, files system, Bluetooth etc, send push notifications here's an example.
Maybe you are getting downvoted because you are wrong. On iOS, you cannot receive push notifications unless you have been added as a PWA to the home screen.
Thanks. It's helpful to mention the specific features needed, as people often mean different things when discussing PWAs. I see https://letter.open-web-advocacy.org/ says «critical features including integration with iOS, push notifications, unread count badging, and the ability to run full screen».
Not to access native push notifications which was the one feature that Apple only just added in 2023.
Sure, Webkit and mobile safari have supported things like service workers for years and years, but we just freaking got notifications and so it felt like they were yanking it back.
But to make push notifications happen, you need a central push server. How do you handle that with a third party browser engine? Where does the browser app request notification access? But then how is that delegated to a separate PWA if you have notifications turned off for the browser specifically? Currently, notifications run through Apple servers on iOS. With third party engine support, that opens a can of worms needed to proxy the requests into an iPhone.
PWAs on ios couldn't send them until the it was supported in webkit and safari. Talking security concerns about a PWAs which is the same risk as allowing users browser the internet since it's using the exact same APIs. Banning PWAs security reasons wouldn't make sense unless you just banned users from browsing the internet on the device as well. It's the same security threat.
I have been making the argument that apple pulling back on this was a "security" issue.
Browsers are more code than most OS's they run on. Hell a browser IS its own operating system for all intents. One that can access the network and do all sorts of bad things on its own.
This matters for the phone. Its a device many people take with them everywhere, bathrooms, bedrooms etc.
Locking PWA's to web kit likely has some underlying security issues. If you dont think browsers aren't full of holes and permissions issues go look at the LAST compromise, Edge snarfing Chrome tabs.
All that said, there are a lot of places where PWA's still suck, because browsers suck.
The underlying problem is that when you pin a site to your home screen, that site gets a separate application identity and storage container[0]. SpringBoard shows it as a separate icon and window in the multitasking view and Settings shows a separate settings page for it, too.
If you squint a little, you'll notice that this sounds a little like the problem Craig Federighi cited with Xbox's cloud app. Namely that Apple doesn't want multiple apps wearing the same 'trenchcoat', so to speak. But they also don't want to actually implement the APIs necessary for an app to break itself apart in the UI and pretend to be multiple apps. So you can't have multiple icons on the home screen, or launch with different storage containers and permissions depending on what app was touched. You can't even have a dependency that gets shared across multiple apps, like what Microsoft wanted with the streaming and authentication code for Xcloud. Ship multiple copies.
Personally this still smells like malicious compliance. Apple does literally all of the things I just mentioned and has been doing them since iPhone OS 1.0. Any security issue caused by an app having two icons can be remedied by the exact same review process that Apple insists they need to be the kings of anyway.
[0] On Apple "device" OSes, each installed app has it's own sub-home directory inside the user's home directory (/var/mobile). This is called a container.
Originally the container had both the app install and it's data; but those were split around iOS 9 so that apps could write to shared containers. That's also why some apps don't actually show up on the Storage view in Settings, and instead there's a separate entry for the developer as a whole.
Containers don't exist on macOS. Mac App Store apps and iOS apps on macOS live in /Applications and write to your user home directory.
IIRC "Web Apps" pinned to the homescreen (which was the thing being broken) are hosted by Springboard (the shell), not Safari as part of the magic so they appear as separate apps. Rather than rework this to allow rendering engine switching, they obviously just decided to turn it off, at least at first.
That part was still present: You could still add a web app to your home screen. It was that it didn't run as a PWA, with the additional features PWAs get.
It’s super well documented if you care to look. PWA’s rely on a Safari service worker running as a system process. Under the current iOS PWA architecture, any browser hosting a PWA can ignore app sandboxing.
I don’t understand why people speculate weird conspiracies rather than doing a bit of research to see the actual issue. We can still pile on Apple for a bad design, lack of foresight, and unwillingness to totally rebuild the PWA architecture.
Not a fan of that wording. I’m going to build a PWA, and I’m going to serve it from web server. What it runs on is determined by the user and/or their device.
A PWA usually makes use of a few features, most commonly push notifications, local storage, and install to home screen. The last one allows a web app to open as if it's a standalone native app, basically only a web view with no nav bar.
It's these features that Apple is restricting to webkit.
That's sort of the point. The EU is requiring Apple to allow alternative app stores with all the same features as the main one. Originally Apple decided to remove these features from Safari rather than allow actual alternative browsers not based on webkit to have access.
Switching to Grapheneos on a Pixel phone and e.g. Debian on your desktop gives your better privacy and an open infrastructure. The hardest part is finding a goal for the thousands of dollars you save.
It was never dead. It was simply being unshipped in the EU until they could get it to be compliant. Compliance takes time and money to do and there are probably not many engineers for building out such a feature and they may have other priorities to balance.
From their announcement it was implied that given low user demand it didn't make sense to invest resources. If this changed and more user demand manifested then this decision would change. Additionally overtime the resources needed to add back support may decrease which changes the equation.
This announcement doesn't indicate that any of that has changed. They're not investing resources, they're just ... not removing an existing feature. A feature that they would need to maintain anyways, since it would remain enabled outside the EU.
A company wants RoI for what they spend money on. Having a high market cap doesn't mean money is able to be spent indescriminantly.
>with 161000 employees
Which may already be assigned to be doing work for something more important to Apple.
>had known about the regulation for two years
There are trade offs a company can make. Knowing about a potential trade off for years does not mean a company will pursue that option.
>cannot enable something they already implemented
PWAs being able to be supported in a secure way across arbitrary browser engines was not already implemented. Making it so PWAs can only use Webkit is a legal trade off that has seemingly been reconsidered since the original announcement.
The ROI is the approximately $100 billion they make in the EU each year. If that doesn't matter to Apple, I guess they could leave the EU market?
The security issues with PWAs were a fabricated excuse. Apple has already mandated security reviews on 3rd party browser engines. All of their claims about malicious browsers sharing PWA information across apps could be caught during those reviews. Either the reviews were never about ensuring security but just performatively putting up roadblocks where they could, or the claims about PWAs on other browsers being a security issue were a cynical lie.
>The ROI is the approximately $100 billion they make in the EU each year.
The RoI is how much they make from the PWA feature existing on their device. And yes, the PWA feature did leave the market for a period of time.
>All of their claims about malicious browsers sharing PWA information across apps could be caught during those reviews.
So they get caught and apple has no solution for 3rd parties to fix it so no other engines get approved for PWAs. That is essentially what we have now.
As has been demonstrated, removing PWAs wasn't actually an option. Apple tried it and backed down without a fight.
The options are to comply with the DMA, not comply with the DMA and be fined increasing amounts of money until they start complying, or to leave the EU market. (And let's be clear, Apple will rather compromise their products and users to the CCP than leave China. They're not leaving the EU either.)
When the sales can't happen at all without doing the compliance work, the compliance work really will have a massive ROI.
> So they get caught and apple has no solution for 3rd parties to fix it so no other engines get approved for PWAs.
Huh? No. The other browser engines would obviously implement PWAs safely, not unsafely, even if Apple doesn't provide them with a special API for ensuring safety. The idea that the other browser vendors are inherently malicious is absurd.
Which unshipping PWAs was doing. Putting Safari on an equal playing field as other browsers is what they needed to do.
>The idea that the other browser vendors are inherently malicious is absurd.
The point of the security is to protect even against browsers unintentionally doing malicous things due to bugs. Since it's impossible to prove that software is mug free, security is important.
.svg){kind=link}
I wonder if there was some sort of back channeling with the EU to determine that “actually this is fine, we don’t care about rendering engine competition for PWAs, WebKit-only is better than removing them.”
The law ultimately only requires changes to features the EU cares about.