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.
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.
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.
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)
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.
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.
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 ;)
It's really not. Self important maybe
Perhaps this is why Apple dragged their feet.
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.
I could probably code a web browser by myself in 4 years, how does a 2 trillion company not have world-leading PWA support listen to yourself.
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..
0: https://wpt.fyi/interop-2021?stable
1: https://wpt.fyi/interop-2023?stable
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.
Which non-Chromium competitors are you speaking to here? 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.
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%?
...Microsoft did exactly that, though:
https://www.macrumors.com/2021/06/30/hands-on-xbox-cloud-gam...
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.
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.
Even back before the App Store and there was just iTunes, Apple had more credit cards on file than anyone in the world except for Amazon.
Read up on “Aggregation theory” by Ben Thompson. Also people have access to in app purchases that don’t have access to credit cards - like kids.
Who is going to be that large trusted platform?
“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.
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?
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.
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?
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?
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.
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.
> Also if it is only Apple holding PWAs back
It's not. Apple is one party holding PWAs back.
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.
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
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.
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.
Yes, I’ve done it at scale and yes it’s that easy.
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.
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….
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.
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?
Background Sync on iPhones is terrible, see https://developer.mozilla.org/en-US/docs/Web/API/Background_...
In addition, Apple exposes limitations on local storage that go far beyond what specs demand. PWAs can save a maximum of 50mb of storage, which is woefully insufficient for an app platform that lacks good data export mechanisms. This is entirely Apple's choice, there is no limitation in the spec that requires this.
In addition, Apple wouldn't need to use a web spec to improve storage reliability. We're not talking about a web standard at this point, we're just talking about persisting data in a way that users can inspect, and syncing data across devices. There is no web standard that Apple would need to adopt to allow Safari data from PWAs to be stored in iCloud. And that shouldn't be a web standard, it should be part of the browser as a user agent. Browser sync is not a web standard and should not be a web standard, and yet every major browser supports it to some degree including Safari. Apple isn't following a web standard when it syncs your bookmarks, and it's not obeying a web standard when it refuses to sync your localstorage.
Apple is also not following web standards when it periodically deletes localstorage for non-PWA websites when they haven't been visited in a while. Imagine if you played a game on your phone, put it down for a month, and came back and everything you saved was just erased because Apple deliberately erased it. That's how Apple approaches web storage, and obviously that's a dealbreaker for serious application development.
And this is not something Apple has to sit around waiting for web standards to evolve in order to fix. It's 100% their choice.
> No you were saying that users don’t care about device sync and would be happy with only local storage.
No, I very clearly was not. I was saying that local storage is important and it matters, and that device sync is not a perfect substitute or necessarily desirable for every app. Which is correct. Device sync is not a substitute for reliable offline storage.
Note that it's extra super-not a substitute for reliable offline storage if Apple is the one in charge of it, because the offline storage is what gets synced. And if Apple is regularly deleting all of your data, then it doesn't matter that Apple is syncing it, because they will also sync the deletion.
We could sort of broaden this out and say that PWAs lack reliable storage period, whether it's synced or not. Only 3rd-party servers can be trusted not to delete data (which is terrible for privacy), and Apple devices can't be trusted to send that data to the 3rd-party server if the app is used offline.
In short, Apple has ensured that PWAs are not a great fit for storing any kind of important data, regardless of how you store it.
> And BTW, the notes app on Mac also automatically syncs between my Mac, iPad and iPhone - yours doesn’t?
Synchronization for every single app you mentioned is optional. Not everyone uses that stuff. And yeah, there are large portions of the population that use apps that don't sync. I don't know if it's a majority, probably not. But like... I'm sorry that programmers get to use apps too? I don't know what you want me to say, it's a non-trivial demographic that doesn't sync their data everywhere, and if you're trying to build a private platform that respects user autonomy, data sync should be optional.
> Apple restricts background processes for all third party apps to save battery life. It’s been this way since 2010.
This is a silly excuse. First, 3rd-party apps are restricted far less than the web is, it's not an example of Apple just applying the same rules everywhere. Second, 3rd-party apps don't need the same level of background access because they have reliable offline storage and their data gets synced to iCloud. Third, Apple doesn't need to give extensive background process access to web apps, it just needs to not randomly erase their data or fail syncing process.
Background updates are available to 3rd-party apps to a higher degree and with more reliability than are available to the web.
Finally, it's worth mentioning a detail that you glossed over here: 3rd-party apps. Part of the anticompetitive complaint against Apple is its privileging of 1st-party apps, both allowing them to collect more data than they should be able to collect and allowing access to privileged APIs that aren't available to other developers. This is part of the reason why Apple doesn't currently have a good solution for 3rd-party PWAs on iOS -- because they never built a security model. They just trust Safari to handle everything, which has led to some fairly embarrassing security vulnerabilities in the past. This lack of separation between the OS and 1st-party apps is part of the reason why privilege escalation bugs tend to be more serious in Safari than in other browsers.
I'm sure your take on this is that Apple is completely justified in giving its 1st-party apps access to capabilities that are not available even to other native apps, but the majority of us would call that anticompetitive behavior.
Not really relevant to the web but worth bringing up, this is not Apple's first time restricting competing platforms.
> You really think iOS users don’t have iCloud accounts? Have you actually ever tried to use an iOS device without an account?
Yes, I set up devices for my nieces without one, and I used a dedicated work Mac without one. Apple devices are very usable without accounts. It's not perfect, but it's impressive, Apple IDs really are fully optional for every Apple device I've ever seen or used.
Which, good on Apple for realizing that is an important use-case to support.
> You realize that Apple’s equivalent of Google Docs - the iWorks suite has synced across devices since 2010 don’t you?
Optionally. Also, wasn't restricted to only 50mb of data either. There's no comparison here, there is no strangled logic path for you to go down to pretend that native apps are not privileged over the web in this area.
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%
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.
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?
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.
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?
These are maybe not the shining corporate examples you want to compare Apple to.
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.
The FTC put out a blog post going into more detail about their complaints, which go beyond price adjustment to match competitors: https://www.ftc.gov/news-events/news/press-releases/2023/09/.... Their full complaint is at https://www.ftc.gov/system/files/ftc_gov/pdf/1910134amazonec...
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.
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.
> It's not that the App Store provides value, it's that PWAs are not a viable alternative.
So the App Store doesn’t provide value except for having features that app developers need that provide value?
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.
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?
Yes, you'll miss out on features like reliable message notifications, but it's mostly fine. Do not install Facebook on your phone.
https://www.bigabid.com/apple-app-store-vs-google-play-store....
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.
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.
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
https://fingerprint.com/blog/browser-fingerprinting-techniqu...
And what do you think is going to happen if there are more native APIs exposed in browsers?
There is also a battery level API that is not supported by Safari.
https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
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.
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?
https://www.zdnet.com/article/apple-declined-to-implement-16...
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?
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 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.
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
https://cybernews.com/best-vpn/vpn-for-ad-blocking/
> 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…
No, wrong again, please look this stuff up before you say things with this much confidence. The concerns I'm talking about popped up after ATT (https://www.theguardian.com/technology/2022/aug/11/meta-inje... and https://www.itechpost.com/articles/113985/20220923/meta-sued...).
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.
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.
> 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.
Unless there’s someone else?
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.
That to me says Apple doesn't want PWAs.
I just opened a web app saved to the Home Screen, and it’s both full screen and rotates orientation.
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
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."
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.
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 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.
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.
What is the end result?
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.
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.
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.
0: https://www.merriam-webster.com/dictionary/scream%20bloody%2...
1: https://developer.apple.com/documentation/safari-technology-...
Just shows the poster read the relevant threads on this very site.
I don't believe for a minute that the EU is OK with the WebKit restriction here, they simply haven't responded: https://news.ycombinator.com/item?id=39565553
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?
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.
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.
Clause 7 Article 6 of the DMA states:
> 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.
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.
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?
> 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.
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.
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.
> "... 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 ..."
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.
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.
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.
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.
> 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?
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.
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.
For furher clarification, please see this fellow HNer's comment and its response by user kmeisthax: https://news.ycombinator.com/item?id=39564383
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
Additionally, there is no official doctrine of precedent in EU Law per se https://academic.oup.com/book/32630/chapter-abstract/2705268...
TL;DR - the authority of the courts in Europe is not the same as in USA or in the Commonwealth countries.
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.
That sounds a bit like "Apple is beyond the law/regulations, regulators better accept that and move on" – is that what you mean?
It worked just fine for USB-C, fwiw.
In this case, they could just remove entire features and have the public do their lobbying for them.
Why is that lucky for us? We want them to comply to the DMA. The fines are a drop in the bucket.
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.
https://paulgraham.com/fh.html
In short: Freudian slip. They said the quiet part out loud. Hurting apple is the goal here.
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.
To make matters worse, the executive is given powers to tell Apple what exactly they need do to comply if they start funny business.
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 is not true for Android. I am using PWA's with Brave (the PWA does get a tiny brave-icon badge overlaid on the corner of the app icon).
That's a nifty workaround but not ideal, since it's not possible to actually provide all WebExtension APIs that way.
Apple knows exactly what the DMA wants from them, they're just deathly terrified of handing it over.
(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 idea that you would be forced to give it away for nothing would be a pretty extraordinary and unworkable intervention in the market.
So at some point you have to interact with Apple SDKs.
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.
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.
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.
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?(2023 Forbes) Seems like people have plenty of choices of what kind of cell phone to purchase.
>treat their every action with scrutiny
Is that not what the free market does? When companies make poor choices customers punish them. (Budweiser 2023)
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.
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.
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.
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.
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.
> 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.
Also I never needed to wait for a carrier to approve an Update for my Android Phone. Neither for my Pixel, Nexus or Samsung Galaxy ones.
And beside the "strict" controls, malicious Apps got in the App Store, and the iPhones themselves also pwned.
Are there other Apple Fanboy Horror Stories about Android that you've missed?
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.
No back channeling is required. It's literally written in the law that you can go ahead and ask if you're unsure: https://ia.net/topics/unraveling-the-digital-markets-act Scroll to Law: Ask us if you find issues
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.
0: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
65: For anything more complex we can have an extended dialog
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 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
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.
The PWA issue is a completely different one.
Although what I assume is they floated removing PWAs to see if that would get users / communities on their side.
It might have worked if PWA support was first class rather than half abandoned.
Removing PWA support goes against both these obligations.
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.)