For support, the Progressive Web Apps will still need to be built on WebKit, with all that entails.
I wonder if there was some sort of back channeling with the EU to determine that “actually this is fine, we don’t care about rendering engine competition for PWAs, WebKit-only is better than removing them.”
The law ultimately only requires changes to features the EU cares about.
I also wonder what's point of PWAs _only_ supported in WebKit.
It feels like they trying to keep playing cat and mouse.
Mostly Apple wants to ensure that PWAs can't emerge as a viable option. As long as they're on WebKit, they can ensure that the apps are limited in their functionality.
PWA’s can run a ServiceWorker in the background too, I can imagine Apple does not want anyone to be able to run code they don’t control as a background task as this may negatively affect overall performance and battery life.
Apple not wanting PWA to work properly on iPhones has nothing to do with performance, security, privacy, battery life or whatever excuse they may officially come up with.
The only reason Apple does not want PWA is because it threatens their App Store profit.
More information: https://open-web-advocacy.org/blog/apple-backs-off-killing-w...
These black and white takes are boring. It can be all of the above.
Only one of the options affects the bottom line of Apple. Incentives incentives incentives. When you want to understand what and why people do what they do, always find out the incentives.
Then why would they have bothered adding any support in the first place? There are market incentives in at least appearing to be modern.
Web apps were the first apps that Apple supported on the iPhone, as of 2007. Back then they did not have native apps, that's why they bothered supporting them.
They then realized that they could make much more money with locked-down proprietary apps that they could tax at will through their App Store. Since then Apple has blocked any meaningful evolution of web apps, to prevent them from competing with native apps.
I don’t see how that fits the timeline.
The App Store was opened in 2008, and was a huge success in 2018 (https://www.apple.com/newsroom/2018/01/app-store-kicks-off-2...: “New Year’s Day Sets Record With $300 Million in Purchases”)
If “Since then Apple has blocked any meaningful evolution of web apps”, why did they add support for PWAs on iOS in 2018? (https://medium.com/awebdeveloper/progressive-web-apps-pwas-a...: “Safari is finally adding PWA features.”)
It's more complicated than that.
1) From a regulation standpoint, it's in Apple's interest for PWA's to exist; Apple has used the argument in court that PWA's are a viable alternative to it's App Store and therefore it does not have a monopoly on iOS "apps".
2) From a financial standpoint, it's in Apple's interest for the PWA experience to be sub-par.
And this is how we got here.
PWA’s are not at all the same thing as the “pin to Home Screen” feature in iOS 1.0.
PWA’s were a brand new subsystem introduced in iOS 11 with substantial (yet not emough) ongoing investment since then.
The conspiracy theory still doesn’t answer “why have then been investing in PWA’s since iOS 11?”, if they wanted them dead they could have just removed them rather than doing incremental enhancements.
Misalignment of the company bottom line (incentives) and employees bottom line (incentives). Company gets money from variable App Store revenue which is directly threatened by PWAs. Employees get money from fixed monthly salary, which is only indirectly threatened by PWAs.
Employees take money and do what is required of them, and otherwise do what they think is awesome. Employees think PWAs are awesome so PWAs happen... until they threaten almighty App Store then it stops.
Company gets money from variable App Store revenue which is directly threatened by PWAs.
I don't see how a PWA-enabled Safari fits into this narrative.
Timeline:
0) Apple hires key people and invests 4 years in PWA support for Safari on iOS.
1) Apple releases support for PWAs in Safari for iOS worldwide.
2) The DMA compliance thing happens.
3) Apple allows alternative browser engines + disables PWAs in the EU.
4) Apple rolls back PWA disablement in the EU.
I mean, 0 and 1 are not some skunkwork. It hasn't been sneaked into the release. PWA support predates this DMA drama. It was disabled only in the EU.
PWAs challenging App Store revenue is completely orthogonal to them being Safari-exclusive or not. PWA support for iOS has been invested on, released, enabled, and has even more features coming up and prereleased in the tech preview. Nobody forced Apple to do that. That alone is solid material fact, blowing away hypothetical claims of evil intent.
Nobody forced Apple to do that. That alone is solid material fact, blowing away hypothetical claims of evil intent.
Apple has been actively using the existence of PWA's as an argument in court that it's App Store does not have a monopoly on iOS app distribution. So, yes... It's likely Apple want's PWA's to exist on iOS.
It's also very likely (given their financial incentives) that they don't want them to be a very good experience.
Are they not incentivized to maintain battery life? Perception of battery life impacts sales. You can't sell App Store apps without phone sales. Yadda yadda yadda. You can argue this towards any preconceived notion you want here. Nobody has any actual evidence, despite all the absolutism in their posturing.
Black and white? Apple not allowing other browsers to have their own browser engines is a black-and-white decision. All or nothing. Apple or nothing. It's all about what Apple wants, and that's MONEY. They don't care about anything else by keeping other browser engines off their platform. It doesn't matter what stupid reason they spout off. It's always about money. Allowing functional PWAs and other browser engines on their walled-garden platform will mean they make less money from their app store. That's it, that's literally all this is about.
You mean euros instead of money, right? Because the changes were only for the EU region, so it’s euros and not dollars or kroner or what have you?
No, I mean MONEY in any form. Apple doesn't really care about users or developers, all they care about is money. They have proven again and again that they will hobble the product if it means they can make more money.
Not all EU countries use the euro.
What is boring is pretending that technical considerations about battery life play anywhere near as decisive a role in this matter as simply protecting a multi-billion dollar line item that is app store revenue.
My take is that it's more about control of the experience, which is something baked into Apple's DNA.
Right, right; everything is 100% black or 100% white. There is no nuance to anything around Apple, and no point in even thinking about the reasons they give, let alone recognizing where they have a good point, whether or not that point outweighs the arguments against it.
...Like, seriously? I can fully understand disliking Apple, and disagreeing with their choices, but to claim that none of Apple's stated concerns—which are perfectly reasonable on their face, regardless of whether you consider their weight to be sufficient to justify the choice—are legitimate at all? That they are only concerned with profit?
but to claim that none of Apple's stated concerns—which are perfectly reasonable on their face
We don't need to speculate, cross-browser PWA work fine on Android and are secure.
No, Apple's claims do not seem reasonable or valid here since there's an existing implementation contradicting them.
They’re somehow only concerned with profit, but only concerned with profit in the EU, since their PWA changes only affected that region.
Service Workers (SW) and installable PWAs are two different things.
Regular sites in browser tabs can have SWs.
When the full Chrome(ium) or FF hits iOS (engine and all), they will want to run SW. And, if I understand the DMA correctly, Apple will be forced to make that possible for 3rd party browser engines.
Don't "installable PWAs" require service workers?
Like they have emerged as a viable option on Android?
Yes. Would you rather install a full-on app for a once-off event (concert, festival or conference) or would you rather just install a light-weight PWA or just use the website?
Well, and that all works on Safari…
And that’s not what most people consider a PWA.
I have attended conferences that can be described as "scrappy": flakey oversubscribed wifi, lots of interesting talks and multiple "streams" in different rooms over 2-3 days in a foreign country where my visit was too short to bother to buy a SIM card. Being apple to see the schedule offline would have been a boon, a problem that can be effectively solved by PWAs.
Any app that's geared towards visitors or tourists is better served as a PWA - think of the apps used to pay for transit, or parking in a city you're visiting. A website is Ok, but offline access and a shortcut on the homescreen would be better.
Or you know, go to the agenda before you leave your hotel and convert it to a PDF….
Just one user's opinion. I'd just use the web site for a one-off event. But if I had to install something for some reason, I probably wouldn't care what technology it was made with and would only care if there was a functionality or performance difference. Honestly, nobody but web developers cares about PWAs. If you put a gun to my head and made me choose between Native and PWA, I guess I'd choose a native app that looks and feels like a native app, performs like a native app, uses native controls and UX idioms, and has the security guarantees of a native app. I honestly don't think users's really care about this PWA vs. Native App war that web developers insist on making a big deal over.
AppClip would be best
If that's Apple's motivation, why have they been implementing PWAs at all? Killing them would be even simpler if they just weren't on iOS in the first place.
Because they are their go to excuse why the limitation to the App Store isn't a monopoly with the regulators.
So... you're saying that having PWAs is purely performative because nobody actually uses PWAs... meaning that the loss of PWAs has no impact on customers?
No, but they are obviously not equivalent in capabilities on iOS
They’ve been on iOS since the beginning, predating the App Store. They were originally supposed to be the only public API for building 3rd party apps on iOS.
For a long time they appeared to be in maintenance mode on iOS. They’re still years behind what Chrome allows PWAs to do.
Apple has also added PWA to Desktop Safari in the latest OS release (which seems to work well for Tana). So their Safari team is putting some continuing effort behind PWA in general.
I used this when I was taking a break from chrome, because Firefox cancelled their PWA support for Desktop.
As far as I'm concerned, it's just an argument for them to use in antitrust lawsuits. "See, they could have developed a web app if they aren't happy with our store". It's better to keep an option opened, especially if it's not good enough to be used.
Because it's technically a separate app in ios system, with all storage separation, permission… etc. enforced by the system itself. And ios don't actually allow any app to install another app unlike Android. The pwa install process is a somewhat backdoor build into safari and ios for this specific usage and never made public at first place.
To make this work with another browser. They would need to fix this, make a safe public api for it, and publish it in new ios version. (Which they think it's way too much work and rather want to get rid of it instead)
Browser can do the exact same thing as a PWA app. It's using the same web APIs.
Edit: don't know why I am getting downvoted. A web page can do exaxt same thing as a PWA. Access camera,mic, files system, Bluetooth etc, send push notifications here's an example.
Not to access native push notifications which was the one feature that Apple only just added in 2023.
Sure, Webkit and mobile safari have supported things like service workers for years and years, but we just freaking got notifications and so it felt like they were yanking it back.
But to make push notifications happen, you need a central push server. How do you handle that with a third party browser engine? Where does the browser app request notification access? But then how is that delegated to a separate PWA if you have notifications turned off for the browser specifically? Currently, notifications run through Apple servers on iOS. With third party engine support, that opens a can of worms needed to proxy the requests into an iPhone.
PWAs on ios couldn't send them until the it was supported in webkit and safari. Talking security concerns about a PWAs which is the same risk as allowing users browser the internet since it's using the exact same APIs. Banning PWAs security reasons wouldn't make sense unless you just banned users from browsing the internet on the device as well. It's the same security threat.
Maybe you are getting downvoted because you are wrong. On iOS, you cannot receive push notifications unless you have been added as a PWA to the home screen.
Thanks. It's helpful to mention the specific features needed, as people often mean different things when discussing PWAs. I see https://letter.open-web-advocacy.org/ says «critical features including integration with iOS, push notifications, unread count badging, and the ability to run full screen».
I have been making the argument that apple pulling back on this was a "security" issue.
Browsers are more code than most OS's they run on. Hell a browser IS its own operating system for all intents. One that can access the network and do all sorts of bad things on its own.
This matters for the phone. Its a device many people take with them everywhere, bathrooms, bedrooms etc.
Locking PWA's to web kit likely has some underlying security issues. If you dont think browsers aren't full of holes and permissions issues go look at the LAST compromise, Edge snarfing Chrome tabs.
All that said, there are a lot of places where PWA's still suck, because browsers suck.
The underlying problem is that when you pin a site to your home screen, that site gets a separate application identity and storage container[0]. SpringBoard shows it as a separate icon and window in the multitasking view and Settings shows a separate settings page for it, too.
If you squint a little, you'll notice that this sounds a little like the problem Craig Federighi cited with Xbox's cloud app. Namely that Apple doesn't want multiple apps wearing the same 'trenchcoat', so to speak. But they also don't want to actually implement the APIs necessary for an app to break itself apart in the UI and pretend to be multiple apps. So you can't have multiple icons on the home screen, or launch with different storage containers and permissions depending on what app was touched. You can't even have a dependency that gets shared across multiple apps, like what Microsoft wanted with the streaming and authentication code for Xcloud. Ship multiple copies.
Personally this still smells like malicious compliance. Apple does literally all of the things I just mentioned and has been doing them since iPhone OS 1.0. Any security issue caused by an app having two icons can be remedied by the exact same review process that Apple insists they need to be the kings of anyway.
[0] On Apple "device" OSes, each installed app has it's own sub-home directory inside the user's home directory (/var/mobile). This is called a container.
Originally the container had both the app install and it's data; but those were split around iOS 9 so that apps could write to shared containers. That's also why some apps don't actually show up on the Storage view in Settings, and instead there's a separate entry for the developer as a whole.
Containers don't exist on macOS. Mac App Store apps and iOS apps on macOS live in /Applications and write to your user home directory.
IIRC "Web Apps" pinned to the homescreen (which was the thing being broken) are hosted by Springboard (the shell), not Safari as part of the magic so they appear as separate apps. Rather than rework this to allow rendering engine switching, they obviously just decided to turn it off, at least at first.
That part was still present: You could still add a web app to your home screen. It was that it didn't run as a PWA, with the additional features PWAs get.
It’s super well documented if you care to look. PWA’s rely on a Safari service worker running as a system process. Under the current iOS PWA architecture, any browser hosting a PWA can ignore app sandboxing.
I don’t understand why people speculate weird conspiracies rather than doing a bit of research to see the actual issue. We can still pile on Apple for a bad design, lack of foresight, and unwillingness to totally rebuild the PWA architecture.
The fact that this could be so easily reversed probably provides evidence in favor of the argument that this was a purely punitive move by Apple as a way of throwing a tantrum against DMA. Somewhat akin to an abusive spouse saying "See! You _made_ me hit you!"
If this sort of behavior doesn't ring alarm bells in the minds of the regulators I don't know what will.
This is not a reversal. They are allowing PWAs built on webkit, not other browser engines. Their argument was that they cannot reliably make sure that installing a webapp on other browser engines is secure. And that they do not have a way to do so reliably before the deadline, and other important things (with more uses)take priority. On Webkit, they already did it ages ago.
In a few months, once we see newer browser engines on iOS, we will see calls that it is unfair Apple allows for one kind of web apps (on their own browser engine) but not others and that is self-preferencing.
And yet you can run any browser engine on MacOS and the world hasn’t ended. This is a cash grab, it’s not about security and I don’t understand why people keep repeating that.
MacOS and iOS have different security architectures and different UX.
And they have different attack surfaces and vulnerabilities. In the abstract, our phones are (for better or worse) far more critical to our lives than our laptops. They go with us everywhere, they're increasingly our keys for various physical and digital access. They're off-board brains and backup. Generally speaking, I would say a compromised phone puts the average person in a worse situation than a compromised laptop.
So why can't I benefit from a strong, secure virtualization on my phone, like I do with Qubes OS?
Why downvotes?
Fine, but where’s the evidence alternate browser engines are such a massive security risk? I see none, but I see many billions of dollars Apple is making from applying a 30% tax on any app I buy. And to be clear, consumers pay that 30%, developers pass it on.
Let’s stop pretending any of it makes sense. Why are Mac app devs not charged the “Technology Fee”.
Because they don’t have to sell on the Mac App Store, they can use their own website. That has nothing to do with other browser engines being available.
And they still must pay the 100$ annually to sign and notarize.
Because MacOs is around 10 to 15% market share it make sense to use every incentive available to attract developers to another platform than Windows. There is a hidden technology fee, but it make more sense not to charge for it.
iOS is more like 50 to 55% market share so the goal is more to filter out bad actors and keep a high standard. Also let's milk that cash-cow.
I'm not necessarily agreeing with this approach but I got to admit it makes sense.
It’s NextSTEP all the way down
MacBook has 100wh battery, iPhone has 12wh. Chrome is notoriously inefficient, easy 2x more battery drain over Safari.
Running an inefficient app is the user's choice, not Apple's.
There's no legitimate choice without education.
The consumer would switch their PWA default engine in one of the half dozen "you have to agree to continue" buttons when Edge and Chrome install themselves and demand every privacy and security toggle be turned off (as Microsoft Teams demands when you try to run it in Safari*), and then all PWAs would be insecure and monitored by the adtech engines.
This weird idea to force Apple to have OS viewports use a foreign engine would not be 99.9% of users' real choice at all, just like the users who installed Avast anti-virus didn't choose to have all their browsing sold to adtech, or the users who chose "Private Browsing" in Chrome didn't choose to have Google recording that activity to the user's profile.
* Note: Because Teams is actually "just" a skin on many different services and the Apple+CloudFlare private browsing confuse the coupling.
This weird idea to force Apple to have OS viewports use a foreign engine
That is not what people are saying. Nobody cares that MacOS renders half its content using WebKit on Mac. Same goes for iOS - people do care that they can't use a PWA in their browser of choice. It's anticompetitive blockage that will be inevitably brought-up when the compliance deadline rolls around.
would not be 99.9% of users' real choice at all
No reasonable person can claim that. Alternative browser engines aren't even allowed yet, you don't know that.
just like the users who installed Avast anti-virus didn't choose to have all their browsing sold to adtech, or the users who chose "Private Browsing" in Chrome didn't choose to have Google recording that activity to the user's profile.
Or the people who left notifications on and got their iPhone information slurped up by the NSA. Pobody's nerfect, right? Get the strawmen out of here before they start a fire.
The consumer would switch their PWA default engine in one of the half dozen "you have to agree to continue" buttons when Edge and Chrome install themselves and demand every privacy and security toggle be turned off (as Microsoft Teams demands when you try to run it in Safari), and then all PWAs would be insecure and monitored by the adtech engines.*
I suggest Apple takes inspiration from Android then, since that doesn't happen on Android. Maybe Android's security model is better.
This is solely about Apple getting a cut of App Store sales. They’ve been in cahoots with Google for years, as evidenced by the recent DoJ monopoly trial - “privacy” and “security” are marketing terms at Apple. Nothing more.
On MacOS, there are sandboxed apps, and not-sandboxed apps.
iOS never had a not-sandboxed option.
Wouldn't that make it safer to allow any app or rendering engine on iOS than on macOS then?
It seems like an argument against what Apple is claiming.
we will see calls that it is unfair Apple allows for one kind of web apps (on their own browser engine) but not others and that is self-preferencing.
We have been seeing people say that for years. And mostly, they've been right; Apple's treatment of WebKit and Safari was anti-PWA for years. Even today, Apple has zero competitors who could meaningfully encourage them to adopt new PWA features or change Safari on iPhone.
Exactly, the Safari team has been openly hostile to PWA for a decade.
It's 100% a reversal. Their previous statement was: "we will remove PWA support". Their new statement: "we won't remove PWA support, we will keep PWAs as they were in 17.3".
eh, you're both right. It's a 100% reversal of their decision to remove PWA support, but it's 100% consistent with their previous excuse/reason of it being too hard to support multiple browsers.
Why would you assume that it’s malicious and not just the result of getting further clarification from lawyers on both ends?
The DMA isn’t an exact set of steps to follow. A lot is left to interpretation
I won't say it is malicious. But I won't give Apple a pass either.
Ultimately, the truth is that a company like Apple doesn't want to deal with DMA. Their whole services business model (whether it be the App Store monopoly or the iMessage monopoly) relies on behavior that is counter to DMA.
It's also clear from their seething press releases about the DMA that they don't want to mince words about how much they don't like it or don't want to do it.
It's always easy for them to give a vague privacy / security argument to justify whatever benefits their monopolistic control. It's no different from the "Think of the children!" style of reasoning that politicians use to get what they want.
I think it's important for users to keep calling them out at every opportunity so they don't get away with it.
It's no different from the "Think of the children!" style of reasoning that politicians use to get what they want.
It is very different. The outcome from “think of the children” is loss of privacy, while Apple’s actions means loss of software functionality. The former is more dangerous for society and freedom of thought.
How can we be certain that Apple's actions don't mean a loss of privacy too? Whenever they're asked about seriously decentralizing their own trust model Apple tends to fall back on the "legal compliance" note, if not directly on think-of-the-children. Their lack of transparency (even the base level that Google provides with the AOSP) isn't very reassuring, at least to me.
Now, one could argue that Apple's decisions are less impactful than politicians. Circumstantially, they may be right, but I think it's appropriate to compare the line of reasoning. After all, Apple employs both.
Get away with what though?
You’re the one who’s ascribing maliciousness to their actions. But you don’t have that backed up by anything concrete other than your subjective perception.
From what they’ve written they removed it initially to keep all browsers equal, which is what the DMA implies is necessary.
They now brought it back with only WebKit support.
It’s completely logical that their lawyers worked with the EU to clear this exception.
People here ascribe too much in the way of human emotion to corporations.
If they were really trying to kill PWAs they’d have done it everywhere. If they were really trying to stick it to the DMA, PWAs are such an insignificant feature to do it with.
What are the percentage of people who’d be so inconvenienced that the PWA would open in a browser tab instead of a pseudo browser instance?
they didn't need to remove a capability they already had, so any lawyer clarification would be on if they would be punished for being anticompetitive by removing the capability
Except they have had to do this multiple times (although usually patents).
Examples include portions of AirPrint functionality on macOS, Bootcamp suspend/resume, and FaceTime peer-to-peer. The latter being the reason that Apple did not open up FaceTime as a broader industry initiative.
In the US we currently have Apple Watch being sold without access to the blood oxygen feature due to an import restriction.
There are also restrictions on showing certain maps in certain countries, as well as whether or not the Taiwan flag emoji displays in China.
So..you've never written software with a lawyer standing over your shoulder?
Very often legal requirements lead to removal of features that cannot easily comply rather than expansion of the feature to comply. Removal is less rick.
Steve Jobs was legendarily spiteful and petty. They just carry over the tradition.
Given that reversing course here means "Home Screen web apps continue to be built directly on WebKit", this pivot doesn't actually contradict their claim that safely supporting PWAs from other engines was too much engineering work.
My hunch is that the initial change may have been performative, but it was likely performative for the EU regulators and not the customers. This pivot presumably means that the EU has now okayed browser engine lock in for PWAs.
My hunch is that the initial change may have been performative, but it was likely performative for the EU regulators and not the customers.
Funny I was thinking the exact opposite: they floated it in case PWA removal got people to complain about the EU.
That's a good point
Regulatory worried?
The EU stated they will investigate this. And somehow Apple decides less than a week later that the feature will return.
Looks like regulators should not be worried about Apple complying in the medium term.
DMA has a catch-all: any circumvention can lead to penalties. You can try to play games like this, but it will just lead to fines.
I would expect a few more U-turns, especially on the fee structure.
I think they’ll keep pushing their luck but it’s not in a vacuum - Microsoft, Google, and Meta have been dealing with EU regulators a lot longer and on a much deeper level. They will see Apple’s missteps and use that towards their own benefit by gaming the refs.
Ironically, Microsoft now has a fairly good argument that Apple is abusing its OS control to stifle competition in web browsers. What a world!
Apple is playing checkers, Brad Smith is playing chess.
Users have been abused for a decade now. It’s normalized. Unfortunately, not much competition in this space.
OSS has potential to disrupt but needs a significant mover to patch it all together. And $$$ to motivate. Then there’s the hardware aspect.
IMO it would be better to avoid the language of spousal abuse and physical violence when describing what are actually dry business decisions. It kind of cheapens the real physical harm befalls vulnerable people.
So easily reversed
Yeah. It is easy to reverse committing an "if" statement.
Because this article decided not to do so, lets be very clear to give credit where it is due: The Open Web Advocacy group, who has been working for years with regulators around the world, and led this particular fight with an open letter to Tim Cook. It received 5500+ signatures in 3 days.
Here is their debrief post about it:
https://open-web-advocacy.org/blog/apple-backs-off-killing-w...
The fight isn't over though. WebKit is still garbage, so we need to keep pushing until other browser Engines have full capabilities!
I don’t think WebKit is garbage. That title belongs to Gecko. Apple picked up their slack with Safari a long time ago. They do have faults with these decisions to intentionally break or not support some features for years, like Push Notificafions.
Whether it's garbage or not ultimately doesn't matter much. What's more important is the fact that it's the only choice for users on iOS right now. WebKit will never have an incentive to get improved without healthy competition.
That's right, it doesn't matter! What's important is that pretty soon Chrome will be the only choice for iOS users as websites migrate over to requiring it, just like they started requiring IE back in the day.
I, for one, am eagerly anticipating unlocking the full monetization potential of the web with the demise of functional adblockers like uBO! No longer will Google be forced to support adblockers to remain competitive with Webkit and Gekko! Developers rejoice!
Thank you open-web-advocacy.org for finally killing off all browser competition! You are doing god's work, son.
Mozilla and Google managed to reverse browser monopolies by just being better.
Why can't Apple?
Why is Apple entitled for a free pass on forcing browsers down their users throat?
Mozilla and Google managed to reverse browser monopolies by just being better.
Mozilla has reversed a browser monopoly? When? Do you mean back in the late 90's when Mozilla's predecessor (Netscape) lost their monopoly to IE? I guess that's technically true they reversed a monopoly back then... but that's not exactly helping your argument.
Google did it not by creating a good web browser, but by forcing their browser on users of the most heavily-trafficked search site and video steaming site (by breaking features for those who used a different browser). You know, the very same anti-competitive arguments that so many people are wringing their hands about.
Why can't Apple?
Safari already is a better browser... for users. I'm sorry that it doesn't have let you do the same tracking bullshit that you can do in Chrome, but having Bluetooth and serial number APIs is not something I want in my browser. I'm ever so sorry that it breaks all the cross-site tracking cookies.
The reason Apple can't reverse a monopoly with a better browser is that:
1. Safari is for iOS and MacOS only. By definition it won't ever rise above the user base of those OSs, which are a small minority in almost all markets. That is also why you don't have to worry about it become it's own monopoly, like Chrome did.
2. Safari won't add all the user tracking bullshit you want because that is the whole proposition of Apple's ecosystem. You seem to have forgotten what a browser is: It's a user agent. It's supposed to work for the user. But if website owners have the option to steer everyone to the browser that lets them reach into the operating system and pull out the device serial number, they'll do that.
Why is Apple entitled for a free pass on forcing browsers down their users throat?
1. We often let minority players do things that we would not let a monopolist do. For example, Spotify is a gatekeeper to music streaming in the EU (I have to license to them if I want to stream my music to any significant number of EU customers), but the DMA does not apply because they are too small. Apple is a small minority player in the browser market, too.
2. Building a Chrome-only website (and enforcing that with DRM) today is a non-starter because it means shutting out the small but lucrative Apple customer base. But if iOS users have the option to use Chrome, websites can force visitors to use Chrome instead. Maybe Google will even pay higher ad rates to sites when the customer is a "verified real person". Google will have a hard time determining who a real person when they aren't using Chrome... but I'm sure that won't incentivize websites to steer users to Chrome, right?
3. If users don't like Safari they have the freedom to pick a different platform. If users don't like Chrome, they have a degraded experience with the primary purpose of a web browser: To visit certain websites.
When Safari is dead and your web browser has become a TV, you can thank the standup folks at Open Web Advocacy organization. It would be so simple to add a provision to the DMA that website owners are not allowed to steer users to a different web browser... yet they don't. Funny, isn't it? I guess this isn't really about anti-competitive behavior after all.
Mozilla has reversed a browser monopoly? When? Do you mean back in the late 90's when Mozilla's predecessor (Netscape) lost their monopoly to IE? I guess that's technically true they reversed a monopoly back then... but that's not exactly helping your argument.
It was circa 2002 (introduction of Firefox).
https://en.wikipedia.org/wiki/Browser_wars#/media/File:Brows...
Maybe you should have done some research before throwing out all that seething condescension?
The graph you linked shows Firefox topping out at around 30% of market share, a distant second behind IE.
https://en.m.wikipedia.org/wiki/Browser_wars#/media/File:Bro...
This later graph (from the same Wiki article) covers 2009-2022, and is much more telling: once Chrome launches, it overtakes Firefox in two years, and then IE in another year. By the time Firefox manages to overtake IE, it’s fighting for third and has only ~15% market share.
Today, Chrome has ~66% market share, and it’s somewhat clear that the remaining 34% of non-Chrome traffic is mostly iOS/Safari. Apple is absolutely being anti-competitive, but that anti-competitive position is the only thing blocking Google from taking control of client and forcing a browser monoculture.
Safari already is a better browser... for users.
Bold claim, wanna know how we test it? We let Safari compete with other browsers like it does on Mac. And having spent a lot of time around startups, I can assure you that the majority of Mac developers I've seen aren't daily-driving Safari.
When Safari is dead and your web browser has become a TV, you can thank the standup folks at Open Web Advocacy organization.
If Apple is the only thing enabling an Open Web, then our web was never open to begin with. Let Safari die, for all I care. Maybe it will encourage Apple to try something different.
What's important is that pretty soon Chrome will be the only choice for iOS users as websites migrate over to requiring it
Meh, people say this, but what exactly is Safari doing to push back against Chrome hegemony? Supporting Chrome/Safari is still less work than supporting Chrome/Safari/Firefox. And in the meantime, Safari has a more restrictive adblocking API than Chrome (which is saying something), is pushing device attestation in the browser for circumventing captchas (which would be a death-knell for Firefox), and can't be run on non-Apple devices. And it gets billions of dollars every year from Google to influence its search engine (which weirdly enough, is a criticism that only gets lobbed at Firefox despite the fact that Apple gets way more Google money).
I'm convinced that the only thing that Safari exclusivity is going to guarantee is that websites list 2 supported browsers instead of 1, as well as giving Google more ammo to use when it inevitably tries to push device attestation for the web a second time. "But Apple did it" was already a common refrain during Google's last attempt.
Apple doesn't play well with other standards-makers and isn't taking a proactive role right now in the web standards process. In that vacuum, Chrome dominates and pushes anti-user specifications. So yes, Safari is an alternative to Chrome, but I'm not convinced it's a useful one or that it's doing anything to push for progressive enhancement or to push against user-agent sniffing. Does it really matter if there's an alternative to Chrome if it's only available on iOS, has a terrible extension API, and leaves every single other device to be Chrome-exclusive?
We need to break Chrome off from Google and examine the anti-competitive privileging that Google performs in Chrome. Safari isn't a substitute for that. Relying on Safari to hold off Chrome is effectively the same thing as ceding control of the web to Chrome.
They're all garbage, but you can at least run uBlock Origin in Firefox. Looking forward to being able to do that on my phone too.
Wipr on my iPhone blocks all my ads, INCLUDING YouTube
I don't trust commercial apps for something like this, sorry.
Gotta be public code and public block lists.
Also "Wipr blocks all ads ... EU cookie and GDPR notices".
That's another no. I want to see those notices so I can make an opinion on how predatory a web site is by how complex they have made their cookie dialog.
With a content blocker, you don’t have to trust it, no data is being sent. It’s like a hosts file.
Would you mind elaborating?
I still find Firefox superior to safari.
Professionally, since we dropped IE11 two years ago, we've run into far more bugs with WebKit than both Chromium-based and Firefox combined.
Within the last six months we had a bunch of cross-site cookies break because webKit was handling SameSite outside of spec.
There were news that the EU has begun to ask for developers' opinions about the death of PWAs too. Apple doesn't want the EU to ask for developers' opinions.
For sure Apple doesn't want anyone to know how it has crippled the web for over a decade, prevented browser competition, and just tried to kill web apps once and for good, that's why they tried to sneak this change without even making it public before two weeks after it was introduced in iOS beta.
As absurd as it is, Apple forcing people to use Webkit/Safari is, at the moment, good for the browser landscape. You already have websites that say browsers that aren't chromium aren't supported, if iOS didn't force Safari on people this would be way more common as people would flock to chrome and websites decide it isn't worth it to support other browsers.
I use Firefox on my non-work machines ... in an ideal world, enough people would do that to prevent the "best in Internet Explorer" web of the dark ages, but I'll take getting forced to use Webkit on my phone over that, even if I'd prefer a "true" Firefox.
You already have websites that say browsers that aren't chromium aren't supported
Is Webkit really so far diverged from Blink that the rendering result is different? I realize that Webkit doesn't support a bunch of stuff that Google pushed into Blink (like Web bluetooth, for instance), but I thought the end result wasn't that different.
Blink was forked 12 years ago, and the size of the team behind Chrome is probably at least ten times the size of the team behind Safari. So yes, there are major differences between two, and it's not just additional advanced APIs like Web Bluetooth. WebKit is lagging behind in all areas and ridden with bugs.
I doubt it's "at least 10 times the size" and probably somewhere closer to 5X tops with a 2X core that's the realistic measure since those are the non-rotating folks with real expertise who make things go. That team is probably about the same size as Mozilla's which is also non-rotating.
There are enough weird divergences to make targeting iOS annoying. Off the top of my head I can recall that Safari PWAs can't get callbacks from pages spawned in a new window. Things have a tendency to fail in strange and unexpected ways.
Worse yet, many people have older iPhones with outdated Safari. You can't tell them to just install another browser, because under the hood Apple mandates that all other browsers are still the same outdated Safari engine.
If you want to track these issues down, you need to invest in an Apple based set up. You can't run Safari outside of the Apple ecosystem to track these issues down. It is bad enough that people are now offering pay as you go Safari instances for testing. Apple gatekeeps, Apple invents problems and developers are stuck with the bag.
Apple banning browser engines is what has prevented the web from becoming relevant on mobile, and the reason why browsers like Firefox cannot distinguish themselves from Safari and end up becoming irrelevant.
So no, it is not in anyway good for the browser landscape or the web, it only serves the interest of one company: Apple.
Look at some overall browser/os usage stats and say again that the web isn't relevant on mobile, and look at browser usage stats for desktop and android and claim again that firefox would have a relevant market share on ios if browser choice was free. Those claims seem pretty disconnected from reality.
That must be why web apps are so great on Android devices and why companies avoid publishing to the Google Play Store to avoid the “Google tax”…
The European Commission has been running "DMA workshops" for months: https://digital-markets-act.ec.europa.eu/events-poolpage/app...
Example: https://matrix.org/blog/2023/03/15/the-dma-stakeholder-works...
Are Apple's actions consistent with trying to make PWA producers participate less in the process?
Nah, that open web advocacy place uses slimy tactics to muddy the situation while omitting details. Just look at that article you linked to: calling PWAs "web apps" is super misleading.
Related discussion: https://news.ycombinator.com/item?id=39563982
It was never dead. It was simply being unshipped in the EU until they could get it to be compliant. Compliance takes time and money to do and there are probably not many engineers for building out such a feature and they may have other priorities to balance.
and there are probably not many engineers for building out such a feature
A trillion-dollar company with 161 000 employees that had known about the regulation for two years cannot enable something they already implemented.
A trillion-dollar company
A company wants RoI for what they spend money on. Having a high market cap doesn't mean money is able to be spent indescriminantly.
with 161000 employees
Which may already be assigned to be doing work for something more important to Apple.
had known about the regulation for two years
There are trade offs a company can make. Knowing about a potential trade off for years does not mean a company will pursue that option.
cannot enable something they already implemented
PWAs being able to be supported in a secure way across arbitrary browser engines was not already implemented. Making it so PWAs can only use Webkit is a legal trade off that has seemingly been reconsidered since the original announcement.
The ROI is the approximately $100 billion they make in the EU each year. If that doesn't matter to Apple, I guess they could leave the EU market?
The security issues with PWAs were a fabricated excuse. Apple has already mandated security reviews on 3rd party browser engines. All of their claims about malicious browsers sharing PWA information across apps could be caught during those reviews. Either the reviews were never about ensuring security but just performatively putting up roadblocks where they could, or the claims about PWAs on other browsers being a security issue were a cynical lie.
The ROI is the approximately $100 billion they make in the EU each year.
The RoI is how much they make from the PWA feature existing on their device. And yes, the PWA feature did leave the market for a period of time.
All of their claims about malicious browsers sharing PWA information across apps could be caught during those reviews.
So they get caught and apple has no solution for 3rd parties to fix it so no other engines get approved for PWAs. That is essentially what we have now.
As has been demonstrated, removing PWAs wasn't actually an option. Apple tried it and backed down without a fight.
The options are to comply with the DMA, not comply with the DMA and be fined increasing amounts of money until they start complying, or to leave the EU market. (And let's be clear, Apple will rather compromise their products and users to the CCP than leave China. They're not leaving the EU either.)
When the sales can't happen at all without doing the compliance work, the compliance work really will have a massive ROI.
So they get caught and apple has no solution for 3rd parties to fix it so no other engines get approved for PWAs.
Huh? No. The other browser engines would obviously implement PWAs safely, not unsafely, even if Apple doesn't provide them with a special API for ensuring safety. The idea that the other browser vendors are inherently malicious is absurd.
The options are to comply with the DMA
Which unshipping PWAs was doing. Putting Safari on an equal playing field as other browsers is what they needed to do.
The idea that the other browser vendors are inherently malicious is absurd.
The point of the security is to protect even against browsers unintentionally doing malicous things due to bugs. Since it's impossible to prove that software is mug free, security is important.
A company wants RoI for what they spend money on.
Indeed. They bet on being able to flaunt it weasel out of DMA by any means possible. So far that RoI bet hasn't panned out.
Meanwhile you're defending a company that made 93 billion dollars in net profit last year.
Meanwhile you're defending a company that made 93 billion dollars in net profit last year.
Yes
No part of their communication up until now had indicated that PWA removal was a temporary thing.
From their announcement it was implied that given low user demand it didn't make sense to invest resources. If this changed and more user demand manifested then this decision would change. Additionally overtime the resources needed to add back support may decrease which changes the equation.
This announcement doesn't indicate that any of that has changed. They're not investing resources, they're just ... not removing an existing feature. A feature that they would need to maintain anyways, since it would remain enabled outside the EU.
They are taking on legal risk instead of investing resources.
I might try an Android if Apple keep being dicks.
I will get an Android over this. I got an iPhone under the promise that I am the user, not the product. This seems is not the case anymore when it comes to Apple's services, such as the Appstore and iCloud.
The device, OS, and apps are also not any better, IMO.
I think you could also argue the opposite — ie it’s precisely because Apple wants you to not be the product that they’re putting so much effort into preventing competing services from being able to spy on your PWA data.
Not coming down on either side, just pointing out the argument exists for both.
I would believe this line of argument much more if they didn't keep hiring ad sales people and if advertising wasn't a growing part of their services revenue.
I will aldo be trying android next round. I remember i had a samsung xcover back in the days and it handled touch in the rain. If there is a droplet of water on ypur thumb the iphone freaks out. Also mich more spelli g errors and slower typing. The only thing missi g is hide email and private relay
I do it from time to time, just to keep tabs on how Android is doing. It is doing shit.
Still, you need to use both to see if you like one better so, do it.
Three physical buttons at the bottom are much better user experience than apple, where the back is somewhere on top of the phone. Maybe that design worked when Jobs was alive and artificially kept them small, but it just makes it feel like those phones were toys for kids.
On a side note, I would also like a physical "forward" button, to jump through some screens faster.
Three physical buttons at the bottom are much better user experience than apple, where the back is somewhere on top of the phone.
If the app is a native iOS app, or at least built following Apple’s design guidelines, then swiping right will always navigate back in any app. It’s a universal gesture, and this is one way to easily spot apps that weren’t built for iOS.
I find Android OS (Samsung in particular) to be vastly superior to iOS. I only like iPhone's hardware. But to each their own.
See ya in six months.
After using an iPhone for more than 7 years, I started using Android again, close to 1.5 years now. Honestly don't miss a thing. I have realized I don't care about mobile or desktop OS these days. I use the same apps everywhere. Although browser experience is much better on Android.
Honest question: why PWAs? As a user it's a lose/lose situation for me. I don't get a nice solid/stable native up and it will use up resources wastefully because of blink/webkit/gecko running nth process on the device and draining battery, the app's data is intertwined with web stuff which inclues a lot if anti-privacy and dynamic content not reviewed by the app store but like normal apps now has access to sensors, files,etc...
My opinion is that it makes life easier for devs and surveillance capitalists but not users. Am I incorrect? If so, why? For privacy, security and performance wouldn't native apps beat PWAs? Aside from the whole anti-apple bandwagon, why is the EU invested in enforcing this?
You get to run an app without worrying its tracking your location, contacts, who knows what else.
Mostly this. Sandboxing on basically every single modern browser is better than sandboxing on mobile devices. Nearly any app that's delivered as a PWA is going to have better privacy guarantees than an equivalent native app.
The difficulty of course being that PWA limitations make many offline-only or account-free apps nearly impossible to build as PWAs.
tracking can be done in either platform. but if there is tracking in an app you have no way to block it. in webapps you can block tracking with the browser. I am not sure if pwa's are so bad on ressources. i haven't used pwa's or just to try it out. I don't like to have too many apps on my phone anymore, so i like webapps. i'd rather use a webapp. it doesn't use space on the phone and does not clutter. I think in that way i am old fashioned.
It's mainly dev experience.
Making a native app that's as cross platform as an Electron app is much more difficult than making an Electron app, from objective burden of work to finding the required talent.
We only have Discord and Slack on Linux (as an installable application out of the browser) because it's Electron-based.
What's in it for you as a user is that the app exists at all. A lot of apps either aren't meant to be profitable (government services apps, ngos etc) or won't be profitable enough after paying for developing the app 3x. Building them as a PWA is what makes them viable at all.
If users are willing to pay the extra cost for a carefully handcrafted native app for any particular use case the market will step up and provide it.
When I already have a PS4, why would I want a Steamdeck. Because it opens up more opportunity, more things to do.
Agreed. Any time there's an option for something that could be native to instead be web-based, it's a loss for users.
And as far as cross platform stuff goes, may as well just keep it in a browser. Would rather have eight web apps and two native desktop programs than ten electron apps.
Would there actually be a security problem in allowing PWAs to run under whichever browser engine put them there?
Added from Chrome? Runs in Chrome.
Added from Safari? Runs in WebKit.
etc.
Why the drama?
Apparently the level of security required for home screen web apps can only be met by Apple. Because nobody else can be trusted to isolate the data of different web apps from each other.
I can tell from the phrasing that you don't agree with Apple on that, but just want to respond anyway. Apple will still be sandboxing the browser engines, so even if Apple doesn't trust the browser vendors, this still isn't a logical argument against allowing them to run PWAs.
It might not be practical for the OS to enforce sandboxes between multiple PWAs running on the same third party browser engines. Browsers are incredible resource hogs and loading many instances with perfect isolation enforced by the OS could result in a poor experience.
On Android I think PWAs do indeed share the same browser process. So it's like having another tab. Still, tab level isolation is taken extremely seriously by browser developers.
Runtime access, yes. But I’m assuming this is to also prevent cookie/storage sharing between PWA:s too, which third party browser vendors (well, Google) have incentive to allow and Apple wants to prevent.
Does Safari sandbox between multiple PWAs running?
Besides, shouldn't it be up to the browser engine to decide on sandboxing between PWAs?
The important part for Apple should be that the browser engine itself is sandboxed from the rest of the OS.
I'm not sure who backed off here, Apple or DMA officials. Apple's argument was that they wouldn't be able to enforce some privacy and security restrictions, if PWAs were running on a third-party browser engine. If DMA hadn't required PWAs to run on third-party browser engines, then Apple wouldn't have any concerns in the first place.
From [0]:
“This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS,” Apple explains today.
[0] https://9to5mac.com/2024/03/01/apple-home-screen-web-apps-io...
Nowhere in Apple's statement or anywhere else does it say that the EU agrees with this. It's just Apple announcing a plan. I can imagine them being like "we showed we'd be willing to kill PWAs entirely, so they surely will be OK with our olive branch here and let us keep our WebKit restriction in place for PWAs"
But I'm not so sure. I certainly don't hope so.
The EU isn't stupid. They very much capable enough to see Apple's shenanigans for what they are.
Yes, but they also are smart enough to realize that the public can be swayed by Apple's shenanigans, and that sometimes you have to act low-key to not get the public opinion against you in these turbulent social times.
You think a small amount of PWA users getting affected by this actually matter to "public opinion".
It is probably safe to say a random person on the street in EU doesn't know what PWA is.
I have to imagine Apple is in direct talks with EU regulators and passed this change by them and provided enough reasoning to do so. They might have even gave a concession in some other part of the OS to get this behavior greenlit.
I mean you'd think so, but my experience at another massive tech company during the GDPR transition period leads me to believe that this may not be the case.
For support, the Progressive Web Apps will still need to be built on WebKit, with all that entails.
Here we go...
What does that even mean? Isn't a PWA just a webpage with some Javascript? How can that be built on WebKit only?
A PWA usually makes use of a few features, most commonly push notifications, local storage, and install to home screen. The last one allows a web app to open as if it's a standalone native app, basically only a web view with no nav bar.
It's these features that Apple is restricting to webkit.
Ok, thanks. But aren't all browsers webkit based on iOS anyway? Is this about other browsers or also about Chrome on MacOS?
That's sort of the point. The EU is requiring Apple to allow alternative app stores with all the same features as the main one. Originally Apple decided to remove these features from Safari rather than allow actual alternative browsers not based on webkit to have access.
Not a fan of that wording. I’m going to build a PWA, and I’m going to serve it from web server. What it runs on is determined by the user and/or their device.
When will apps on iOS get the same status as apps on MacOS?
Apple can't keep hiding behind the "it's for your own safety", because everything they argue about happens on MacOS already.
A modern smartphone is a capable computer, yet I still feel like I'm carrying an expensive brick in my pocket.
People like you are an extreme minority. Most people just want a phone that works and that doesn’t get ‘viruses’. iOS accomplishes that; macOS does not.
Most people also want a MacBook that just works.
Or are you saying that people can't have that, so they love their iPhones and are unhappy about their MacBooks?
Non-technical people do seem to show a strong preference for their phones and iPads, yes.
iOS and the web accomplishes that
(not that I’ve ever had a virus on a mac)
why not get pinephone?
To anyone reading this as "the EU is okay with PWAs being restricted to Safari/Webkit":
(I've seen a couple of those comments go around here on HN)
I don't think so. Nowhere in Apple's announcement does it say "the EU is okay with this".
What Apple has announced today is a(n update to their) plan to comply with the DMA. The EU won't actually do anything until March 7th (the deadline for compliance). The fact that they did do something following Apple's announcements regarding PWAs just shows how obviously ludicrous those plans were. The EU recognized the urgency of the situation and acted [1] - If Apple would have shipped this update, many existing PWAs would stop working overnight, those apps would jump ship and offer their PWA in the App Store with (no way back?) and the damage to the reputation of PWAs would have been done: Apple would've sent a message that you can not rely on the web to reach your customers on iOS.
Nowhere does anyone say that the EU is OK with PWAs being restricted to WebKit. In fact, the DMA demands the opposite: Apple has to open up iOS to 3rd party browsers, and Apple can't self-preference Safari/WebKit for any of its features. Like, say, run PWAs.
I have read lots of comments and posts that said something along the lines of "Apple doesn't want other browsers to run Service Workers". That's not the reason for the attempt to remove PWAs on iOS. Service Workers are not PWA-only, every regular website in a browser tab can have a Service Worker. PWAs can be added to the home screen just fine without one. They are not mutually exclusive.
Apple removed PWA support so they would not have to open up the APIs to other browsers. Period.
So, to circle back to "the EU is okay with PWAs being restricted to Safari/Webkit":
I very much doubt it. Apple has announced a plan to comply, forgot to mention they were going to kill support for PWAs, then did confirm it (only took them 2 weeks), and now they backed down. We're back where we left off a month ago - and I believe the EU is very much going to have an opinion on the WebKit restriction Apple is trying to keep in place.
[1] The EU only announced they would start an investigation AFAIK, which is a long way from actually enforcing anything.
You've posted your comment twice.
Might have been a mistake? I've killed the other one as a dupe now (https://news.ycombinator.com/item?id=39565557).
Yep that was a mistake. Thank you!
I think this is spot on. It might not seem like much, but the EU announcing they would open an investigation, during the beta of an OS is unheard of.
It's the kind of reactivity that might have surprised Apple, as it was a public response released even before the official answer to the current obviously malicious DMA compliance plan.
Apple: You can have it our way, or you can have it our way.
I hope the commissioners write Apple another scary letter.
Who do you think gave their blessing for PWAs to run on WebKit only?
Beats me, it's their funeral.
I hope they bonk them with a huge fine, for their bullshit compliance with the App Store. A few percent of global turnover will hurt badly
It should be obvious to everyone that Apple is Microsoft of the 1990s vintage. There isn't a lot of innovation in hardware that requires huge numbers of people to upgrade their phones and laptops as often as they did before. This requires services revenue to make up for it, and Apple is taking very aggressive tactics to ensure the App Store cash cow continues. They are fighting in every battlefield and spending enormous legal and tactical resources to do so. Any wedge into their closed ecosystem, from alternative app stores to side loading to web apps to alternative payment rails, must be prevented at all costs.
For people using Windows, Microsoft of the 2020s is also like Microsoft of the 1990s, and possibly even worse. All the bundled apps, cloud requirements, “accidental” pushes of features that people had already declined, telemetry, etc.
Perhaps, but Apple in the 2020s is certainly worse than Microsoft in the 1990s.
At least Microsoft has Microsoft Research. All Apple does is milking developers.
I'll chime in and say I'm not really interested in who's worse. Microsoft, Apple, and Google are all abusive in their own ways and should all be broken up.
When talking about antitrust it's very easy to slip into comparing companies (the Apple vs Windows narrative is one that Apple ingrained into culture for years), but all of these companies are terrible and we are fully capable of pursuing antitrust against all of them simultaneously. They don't have to be ranked.
Is there any chance they'll ever allow Safari web extensions to run in PWAs?
Last time I checked content blockers already seemed to work in PWAs, but there was no way to disable them.
Ideally, of course, Apple would allow PWAs to use different browser engines and then competing browsers could add support for extensions in PWAs.
It is possible, but unlikely.
Apple will give per-app prompts for system resources like location, but does not really have an iOS 'app prompts for permission to manipulate another app'.
These sorts of permissions are confusing to users, they imply an execution model where both apps will be guaranteed to be runnable side-by-side (rather than one suspended while the other executes), and provide efficient vectors to share privacy/tracking information across those boundaries about the user.
Browser extensions aren't web apps. It's a definitional thing. The whole model of the PWA is that it's an app implemented using only the fixed set of features, authentication and authorization mechanisms defined by the relevant standards, and thus requires no human to specifically audit and permit the installation. Anyone can put up a web app and run it on anyone's device, and we're all safe (modulo bugs).
Extensions can in principle do anything the browser can, like snoop on traffic with foreign sites, etc... They have more capability (for good reason!), but require some level of authorization to happen by the user and (usually) OS vendor to make sure nothing bad happens. And bad things happen anyway.
Does it seem like this was the plan all along to anyone else? Apple gave us the worst possible outcome so that this now seems like a win.
I was gonna say this. They need to allow third party browsers the ability to create PWAs, but they can't (or don't want to). So instead they just disabled it, saying that it was not possible, and wait for the backlash to restore it for them only.
Now we are at the beginning, PWAs are locked to Apple...but apparently that's good? I don't understand...
If this was their plan it’s not a good one. There’s no indication that the EU was interested in PWAs before this, but now Apple have made it a cause célèbre and brought the issue to the attention of the EU.
Hanlon’s razor should be applied.
Apple was already discussing PWAs in their DMA compliance plan, under "dedicated browser apps and apps providing in-app browsing experiences": https://developer.apple.com/support/dma-and-apps-in-the-eu/#...
OWA says the plan was maliciously neglecting to mention the "killing" of PWAs. Hanlon's razor would require us to assume there was no malice and that there was mention because there was no such plan.
Great work everybody. I had people literally laughing at me for helping get the word out, saying that it would be impossible to influence a behemoth like Apple.
This goes to show the power that people have when they get together and fight for a common cause.
But the work isn't done! Keep following OWA for news and ways to keep pressuring Apple and the other tech giants in favour of an open, competitive and capable Web.
OWA[0]
I think people were laughing at the tactics OWA uses. For example, saying "web apps" are being killed is intentionally misleading.
As a fan of PWAs, I like the direction this is headed. Apple will both have to open up PWAs to other browser engines while increasing the abilities of PWAs in Safari. App developers will realize 80% of apps are fine as PWAs and it is a great way to avoid the app store.
For support, the Progressive Web Apps will still need to be built on WebKit, with all that entails.
They are not opening PWA's to other browser engines.
For the time being, their excuse of not having enough time to validate and secure those capabilities seems valid. In a year, that won't seem as reasonable, and other browser engines will rightly complain.
So glad they reversed that, it would have killed my side-project which I based around webapp push notifications just after they released PWA pushnotifications with iOS 16.4 not even 12 months ago. That backtrack would have been a punch in the face of all devs that jumped on that feature.
I feel like it’s still very useless and they implemented it in a way that makes it practically unusable.
“Apple's iOS has some limitations when it comes to push notifications. For example, iOS devices do not support background sync, which means that PWA push notifications cannot be delivered to the device when the user is not actively using the app. Additionally, iOS devices do not support silent push notifications, which means that notifications cannot be delivered to the device without the user's knowledge.
Another limitation of iOS devices is that PWA push notifications cannot be delivered to the lock screen. Instead, they are delivered to the notification center, which can be accessed by swiping down from the top of the screen. This means that users may see the notification later, which could result in missed messages.”
Apple will maliciously comply until people give up.
I’ve written a PWA that I use daily on my iPhone, and it delivers push notifications when I’m not using the app to the lock screen.
Don’t get me wrong, Apple’s PWA implementation is very limited, but you can definitely have background notifications and lock screen notifications.
Does anyone else think that this was the plan all along? Apple gave us the worst possible outcome so that this now seems like a win.
Maybe, maybe not. It can also be explained by Apple wanting to do the minimum required. First choice: no PWA support at all, Second choice: PWA support independent of custom browser support, and final choice (most work): PWA support on top of the custom browser support.
The only thing we know for certain is Apple has shown no interest in making the best user experience given the rules vs complying with the rules only where required to.
If so, it’s working. Now all the commenters who assume that Apple is doing the worst thing possible at all times are praising the EU for forcing Apple to save PWAs. Otherwise they’d be complaining about how Apple was intentionally crippling PWA support by not letting you pick the rendering engine used.
Thanks god! I've already started porting my personal app from sveltekit pwa to react native...
Why not just use WebView?
I've had problems with getting service workers to work.
Don’t agree with politicians using this as a money making opportunity with no clear rules where the money can be spent.
Would be happier if it were burned to be honest.
I don't understand how this is politicians making money. It happens all the time, sure, but what about the DMA is making politicians rich?
Just. Stop. Using. Their. Products.
Apologies but it had to be said.
i agree. apple wants to control everything from how the users use the devices to what developers are allowed to do. android is much more open for users to do what they want.
I'll believe it when I see it. I'm sure they'll find new ways to drag their feet.
Until there is a nocript/basic (x)html browser, critical online services should be fine (if they have the decency to provide not only google/apple apps).
The real fight is to get major online services to have safe and available noscript/basic (x)html portals. Because running on google blink|geeko or apple webkit is no better than native google|apple apps.
Fantastic. That's one giant step backwards not taken for the web platform.
Congrats everyone, it isn't cool that Web is practically ChromeOS, on the other hand Apple's behaviour as spoiled child against EU is much worse.
It was either this, or having to explain EU why PWAs work just fine on Android and Windows, and not on iDevices.
Man that makes my day! I was prepared to not update to 17.4 and leave the Apple ecosystem in the longterm because of this, already checking out linux phones…same situation when they threatened to scan my photos. In both cases they reversed.
The real reversal is committing to not trying this again
This is a good news <3
This Web App support needs to die, until Apple finds a way to prevent 3rd party from digging into our personal info.
I think we might see third party browser support for PWAs soon in iOS. Maybe with the next major iOS release. This might've been a stunt to delay that feature and buy them some time and plausible deniability that they tried their best and it just took longer than expected, because of poor decision making.
.svg){kind=link}
This is the most likely theory.
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.
0: https://9to5mac.com/2024/02/26/apple-blocking-web-apps/
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.
This makes absolutely no sense. It came out in the Eoic trial that 90% of App Store revenue comes from games and in app purchases.
Those apps are no more going to leave the App Store and go to the web than they are going to leave the Google Pay Store. In app purchases monetize too well and people aren’t going to put their credit cards on every third party website.
That’s not even to mention all of the ways that you can pay via in app purchases that you can’t pay via the web and all of the kids with phones without credit cards attached.
If it’s only Apple, then why aren’t Android developers creating great PWAs to escape the same 30%?
That's a good question: Apple has argued in court that PWAs are a serviceable alternative to the app store.
So why aren't developers using them? Is Apple wrong? Are they not a serviceable alternative to the app store?
Android has better support than iOS, and Android's userbase spends less money on apps and is more often monetized through ads. So it's not the payment platform that causes developers to avoid PWAs, otherwise they'd be used all over the place on Android.
Android also has a semi-thriving community of Open Source applications through F-Droid that are privacy preserving and completely non-monetized. But installing apps through F-Droid is complicated. And F-Droid has zero user reviews. So it's clearly not the ease of delivery or advertisement that's causing those developers to ship native apps that need to be sideloaded through a complicated process that involves going into your phone settings and turning on sideloading instead of just shipping web apps.
So what's left? Well, invasive apps like Facebook/Twitter could ship as PWAs (with the caveat that their notification support would be worse). But they'd be giving up tracking ability by doing so. Web browsers are better secured than phones are. Facebook on iOS has an easier time tracking your behavior than Facebook in Safari does. Facebook on iOS could even at one point (and might still be able to, I can't find a source that this is patched) push custom code into web views of other articles through its iOS native app. So yeah, they're obviously interested in shipping an iOS app because (frankly) the Safari team is better at security than Apple's iOS developers are.
The only reason left that explains that behavior is the fact that PWAs on both Android and iOS are severely lacking in APIs that would enable anything other than shallow internet-connected services. They are not alternatives to the app store in their current state, no matter how much Apple pretends otherwise. Notification support on Android for PWAs is a joke, it's basically only usable for advertisements. And it's even worse on iOS. If you want to make an alarm app as a PWA, it is literally impossible to do that reliably. Want to make an RSS reader? I have no clue how that would be done as a PWA, I don't think it can be done without a web server handling the article fetching.
----
And I'm sure you would say at this point that there are tons of apps that don't need this stuff and that really it's not about capabilities it's about payments and about what the users want and where they look for apps...
And I would just repeat your question back to you -- there are a ton of apps that are not monetizing through app store payments that aren't shipping PWAs. There are a ton of apps that are not looking for mass-market appeal that are not shipping PWAs. And Apple is arguing in court that they could. But they're not. They're not using PWAs on iOS or on Android. They're not shipping PWAs when they rely on advertising. They're not shipping PWAs when they would benefit tremendously from not needing to pay so many commissions to Apple. Even when they're Open Source and don't monetize at all, they're not shipping PWAs.
Why not? What do those developers know that Apple either doesn't know or is pretending not to know? There's no NewPipe for iOS shipping through Safari. Why is that?
Just a quick Google search shows that App Store revenue is 67%/33% split Apple/Google.
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.
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.
This is not true by any metric. Native apps have more access to fingerprinting vectors than web apps do, are capable of requesting deeper levels of user information like contacts. Native Facebook on iOS got called out for injecting custom code into the in-app web view when users clicked on links within Facebook for 3rd-party sites. That's something that's not possible to do in any modern web browser.
Native apps are indisputably easier to use to fingerprint and track users on both iOS and Android.
Even if you're unfamiliar with the technical side of this, you can still think of it this way: if apps like Facebook had an easier time tracking you on the web than on mobile devices, they wouldn't try to get you to install mobile apps. They would force you to use the website. The reason why Facebook ships an iOS app is because it is easier to track you via iOS than through the Facebook website.
I’m very familiar both - exactly how can apps track you - without your permission that the web can’t?
And your example of how Facebook can track you by knowing what links you clicked on off the site from the app, of course Facebook could do that from the web.
There are at least a dozen ways to do fingerprinting o the web
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?
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.
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?
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'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.
----
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.
https://cybernews.com/best-vpn/vpn-for-ad-blocking/
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.
Really? You can’t do persistent storage on the web that’s available cross site?
In fact they do, I just cited a list of VPNs you can install.
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.
----
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.
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.
Such as? I can't think of a single one.
----
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.
----
See above.
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.
There are plenty of APIs exposed to native apps that are not exposed to the web, stuff like your OS version, loaded libraries, boot time, …
The Safari version is exposed and the Safari version is tied to the OS version for iOS.
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.
Note that native iOS apps do have access to battery level, which is another fingerprinting vector that can be avoided by using websites through Safari or Firefox.
Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
And which way are you arguing that Apple should add more OS level APIs for web apps or should have less for native apps?
You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
https://www.zdnet.com/article/apple-declined-to-implement-16...
In, at minimum, any way you agreed to on the permission screen when installing.
Facebook and Twitter webapps are awesome, by the way.
Software created by user-hostile organization is normally best on the environments where they have the least permissions.
I do want to encourage people to use Facebook/Twitter via their mobile browsers instead of through the native apps. I worry a little bit re-reading this that it sounds like I'm saying they're unusable, and no, they're not, and you should use them on the web.
Yes, you'll miss out on features like reliable message notifications, but it's mostly fine. Do not install Facebook on your phone.
...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.
If it’s just Apple, then why aren’t developers leaving Google Play Services in droves to avoid the same 30% cut?
And Microsoft did that not because they didn’t want to be in the store, but because at the time Apple wouldn’t allow them. Yes I disagree with this.
If PWAs could be made one to one with apps - and today games like Candy Crush could be web apps - game developers who make up 90% of App Store revenue still wouldn’t give up the direct access to users wallets they get from in app purchases.
If PWAs were on par with native feature-wise, why couldn't they have single-click in-app purchases? All you'd need is some large trusted platform to provide a single sign-on experience and process payments.
Why do small merchants sell physical goods on Amazon today when they could sell on their own website with much lower selling costs?
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?
I don’t understand the argument you’re making.
“No one wants to use the web because it lacks the centralized payment processing”
“If PWAs were fully featured a third party could offer that”
“Why do you think people sell on Amazon?”
The last statement has little to do with the two preceding it. We all understand the strength of a centralized payment system. Amazon themselves already offer Amazon Payments. That could absolutely be an alternative to in-app purchases. Except Apple wouldn’t get their cut, so they don’t want that.
The correct answer here is to let the market decide. If I’m willing to trade 15%/30% of my revenue for an easier purchasing flow I can do that. But if I’m willing to tolerate more friction for a lower cut I should be allowed to do that too. But App Store rules expressly forbid that. The web could be an alternative but Apple has a vested interest in under developing it.
Where hard to understand? You don’t have to sell on Amazon and deal with their commissions but people do.
A news website doesn’t have to allow Google to crawl them since they complain that Google takes their ad revenues - yet they do.
And Apple would get no cut if Candy Crush were on the web and even the cut they would get from using Apple Pay (not in app payments) are standard credit card payments.
But kids who probably don’t have access to credit cards still can use in app payments along with people who don’t have credit cards at all who can use Apple gift cards. I gave up a reliable reference from a well known analyst about Aggregation Theory.
Outside of the App Store, parents aren’t going to give their kids unfettered access to their credit cards compared to parental controls that are available within the App Store.
If so many developers are in such a hurry to leave the OS providers App Store, then why don’t the same developers leave the Google Play store where it is allowed?
How did that work for Epic with Android?
The fact is that game developers - who make up 90% of App Store revenue according to data that came out during the Epic trial - complain about the 30% cut. But they want access not only to Apple’s customers but also to in app purchases so they can use every psychological trick to take advantage of the whales.
Neither Google nor Apple care about the Indy developer and the little revenue they make.
Are you fighting for the independent developer or the slimy pay to win game developers?
I think my previous comment was very clear: developers should get to choose. If they want to pay a high commission for easy payments they should be able to. If they want to introduce greater friction for a lower cut they should be allowed to do that too.
Apple expressly forbids this in native apps. If the PWA platform were more viable it would offer this choice but it isn’t, an Apple has a vested interest in things staying that way. At the very same time they defend their restrictions upon native apps in court citing the web as an alternative platform. It’s very convenient.
Okay, developers can choose on Android. Yet to a first approximation, all of them still use the Google Play Store, why is that?
If it’s only mean old Apple stopping developers from using PWAs, then why do Android developers still use Google Play services instead of PWAs, alternate app stores or direct downloads? All of which are available?
Candy Crush - still one of the most profitable games in the App Store is not graphic intensive and could be done on the web today and use Apple Pay (normal credit card charges), why don’t they?
Because Candy Crush relies upon being an impulse purchase. If people had to go through five steps to buy it a ton of people would abandon it.
That isn’t the same for every app. There are plenty of apps folks would be happy to go out of their way to purchase because they provide a ton of value. But the developers are not allowed to.
Again: my argument here is choice. Let developers decide. Your counter is “but one of them is better”. You’re entitled to your opinion but that isn’t a counter argument to letting developers choose what type of payment system they want to use. Apple does not let developers do that and they should. There’s really not much more to the debate than that. If, as you argue, Apple’s ecosystem is better in all aspects then it will win out in a free market. What’s not to like?
If we ever reach a point where compiled code is equally as performant as web apps, I'll eat a shoe.
I don’t think the comment you’re replying to was saying Apple’s PWA support was world-leading.
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.
The cynical view would be that apple was only doing that to try staving off anti-trust litigation. The fact that PWAs are seriously crippled on iOS vs Android still seems certainly makes it appear Apple has ulterior motives. If you make PWAs not able to do everything a native app can do then you're incentivizing native apps.
Apple wants everything to go through their store. (1) so they can ban anything they don't like. (2) they can get their 30% (can't get 30% of websites)
I'd say this is not a cynical view at all, rather a quite realistic one.
They only added support for push notifications to iOS in 2023 (7 years after Firefox and 8 years after Chrome on Android), right after the UK regulator started its investigation in mobile ecosystems.
Yeah I’m not sure how that seemed to get lost in some of the revisionist history in the comments here but it at a minimum sure was a hell of a coincidence that they managed to not make any meaningful investments in supporting the web as a viable app platform right up until the moment that regulators started looking into it.
This is an important server, not some small anonymous fringe forum. The idea that various political games are not played and manipulated also here is dangerously naive.
Could be just die hard fans or current employees/investors, but... I've seen and read enough to know how these games are played by all relevant players. Again, this is too important and trivial to infiltrate place to ignore by many many players. Sure mods can remove outright lies but the key is in subtle ways crowds can be manipulated via ie direct attack on negative emotions, or mildly revisioning history one step at a time.
It's really not. Self important maybe
Given the number of comments trying to find the craziest justifications for a giant corporation just attempting to break a law, silently kill thousands of apps used by millions of users, destroy businesses and kill the only open and free app distribution platform competing with their closed and taxed one, there is indeed very little doubt that a lot of people here have a vested interest in Apple.
Of course, Apple $1B legal department thought they had to kill web apps to conform with the DMA whose purpose is to open iOS to competition. Sure ;)
Nowadays, using push notification, users can be exposed from behind VPN.
Perhaps this is why Apple dragged their feet.
Lol, good one. And they just forgot to remove them for native apps, right?
You own Apple stock?
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'm pretty sure that no single person can code a modern web browser by themselves in 4 years. Even just rendering and layout alone is insanely complex with modern CSS. And then you need a decently fast JS interpreter (which means JIT these days - and web apps do assume that kind of perf), and Wasm, and canvas, and ...
https://ladybird.dev/
wrong, Apple only started implementing the bare minimum because they felt the heat from devs & feared the legal consequences for their anti-competitive behavior.
Apple still has the unquenchable desire to kill PWAs, they will just keep sabotaging them more subtly. Apple will keep up their shenanigans until the bitter end, but I hope that the EU will have none of it.
Yes… and what I was saying in my response is that even if Apple did want to kill PWA there is good legal reason to have made the investments they have in the past few years. In court they can argue that app makers are free to make a PWA if they don’t want to pay the 30% cut. If they removed PWA support they’d not be able to make that argument.
“The competition” is just Google/Chrome.
Unless there’s someone else?
I don’t understand the relevance of that, why would it invalidate the point?
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.
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].
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
2: https://wpt.fyi/interop-2024
3: https://wpt.fyi/interop-2022?stable
On the flip side, I think past actions are a better indicator of intent than assuming good intent.
Having a closed ecosystem has been baked into Apple's DNA since day 1. Not just software, but even the hardware was sealed to prevent modifications to the hardware in an age when upgrading and modding PCs was the norm.
Over the past few decades there have been a lot of changes at Apple, but preventing user customization has been intertwined with their design-first philosophy. It seems naive to think they are doing anything but the minimal required action to maintain their hermetically sealed ecosystem.
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.
AFAIK Apple still doesn't support PWAs. As one example AFAIK, iOS Webkit doesn't support fullscreen mode and orientation so it's impossible to make a landscape game as a PWA. That is supported on Android Firefox and Chrome for like 10 years? And would likely be supported on an alternate browser on iOS
I'm pretty sure there are many other APIs that PWAs want, that native apps have, that Firefox and Chrome offer on Android, but since 3rd party browsers are not supported on iOS, don't exist there.
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.
Yes, installed PWAs can run fullscreen. This limitation exists only inside of Safari proper.
The intent here is likely to avoid the messes that could be caused by arbitrary sites being able to fullscreen and confuse or trick the user. Requiring a user interaction to fullscreen doesn’t help here much, it’s easy to attach the function to an innocuous looking link or image that baits users into tapping them.
And yet
(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
"rotates" is not the same as "forces a rotation". If there's a PWA that forces landscape orientation in iOS, same as a native app, please post a link.
Maybe it is a tactical move to create a precedent were the EU tells Apple "in this case this is ok to require execution by safari"
Business is hard enough operating directly. Triple bank shots that require business and legal to coordinate are too complicated to attempt.
One of the most valuable tech giants in the world is definitely capable of a simple red herring like this. This is amateur stuff. Apple likely has contingencies and plans for almost every scenario and if we learned anything apple email leaks is that they are keen on following up on any sound strategies, even ones that involve "we can't talk about this on email".
They already did that with iMessages though.
The histrionical descriptions of other people's takes are like nails on chalkboard and kinda gross. (bloody murder?)
No one thought removing them in the EU was the first step to removing them everywhere.
Jen Simmons isn't a "rock star."
Hiring someone with a lot of Twitter followers to do something doesn't preclude the company from stopping doing something.
I think everyone over 30 in tech has seen that first hand. Couple right off the top of my head for Apple: Graeme Devine, Max Howell...
In general, it is important for discussions to have nuance. I'm sure you've seen some un-nuanced discussions that I haven't. However, escalating rhetoric to condemn lack of nuance in others rhetoric should be reconsidered.
Just shows the poster read the relevant threads on this very site.
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.
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.
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-...
Gene Simmons however is a rock star.
If (as many people have suggested) Apple's intention in suddenly devoting significant resources into PWAs (after completely ignoring them for years) was to avoid app store regulation, it makes perfect sense that when they failed to stave off regulation in the EU Apple would no longer have a motivation for investing into them within the EU.
Additionally, even if Apple is still looking at PWAs as a way of staving off regulation in the EU, it still makes perfect sense that Apple is running a cost-benefit analysis on PWAs being open to other browsers. PWAs on iOS are significantly limited even after Apple's increase in support. Supporting PWAs just well enough to stave off regulation while keeping them locked down so that other browsers can not extend them or push capabilities further is entirely in Apple's interest.
----
My take is that Apple as a company would prefer not to be working on PWAs at all. But that's not really an option, because both the EU and the US are looking at regulating the app store. The next best option is to have PWAs be a serviceable but ultimately inferior option for offline-only and privacy-preserving apps (and in fact many of the APIs Apple supports are entirely unusable for offline-only apps, although to be fair that's probably more Google's fault than Apple's). Apple may very well have thought the option of a semi-supported but ultimately inferior, controlled PWA experience was off the table in the EU; or they thought that with the app store opening up they could get away with killing the platform for EU users entirely. In either case, they now seem to believe they can keep PWAs locked down to only support Safari capabilities. Maybe they're right, I'm sure Apple has more access to regulators to ask these questions than anyone else here does.
And so none of this is incompatible with the notion that Apple wants to kill PWAs. The idea that a company can completely ignore a technology for years and years and years, and then suddenly out of the blue as soon as regulation gets suggested start pouring resources into their browser and openly arguing in court, "see, you don't need to regulate us, we have a browser" -- and we're supposed to believe that this means that Apple is suddenly on board with the technology and that they don't have ulterior motives or that their motives wouldn't shift back if the threat of regulation went away.
That is just silly. Apple has had literal years to both clarify with regulators what the browser regulations would mean and to build APIs for PWAs that Microsoft and Google have been perfectly capable of creating. And in light of their last-minute scrambling, the most likely and reasonable interpretation is that Apple thought they could get away with killing off PWAs now that they were no longer useful for avoiding app store regulation, a bunch of people screamed about it, regulators reached out, and suddenly Apple had a (partial) change of heart.
Note, of course, Apple has no timeline or plans or announcements about when (or if) PWA APIs are going to stop being 1st-party privileged and exclusive to Safari, despite the fact that Apple has known that this regulation would be coming for multiple years. Which does seem to conflict a little bit with the narrative that Apple is all-aboard with PWAs as a technology and that they've been investing into them as a long-term strategy or commitment to the web, but what do I know?
---
But I really, genuinely do not see what the past 4 years prove other than that Apple's motivations about the web can change on a dime the moment that regulation enters the picture. And I think that's really revealing, and I think it says something about Apple's commitment to the web that it took the threat of regulation to make them care at all about the web as a platform, and I think it really says something about Apple's motivations that the moment that regulation went through anyway, Apple suddenly reverted back to its previous stance on PWAs and was comfortable throwing all of the PWA investment of the past 4 years out the window.
I very honestly do not understand how people can look at these series of events and say, "this proves that Apple cares about the web." We're looking at the same timeline, but it's like you're reading it in a different language than I am.
The DMA was passed many years ago (January 2022), before the cited investments in PWAs. So if Apple was acting to proactively stave off regulation, you have a big hole in your theory of causality.
The web is more than a Chromium app runtime. We are commenting on the web without any of the random features Chrome builds because they are strategically invested in ChromeOS, and their user data harvesting business model relies on more clients sharing more data with Chrome and Google. Apple’s interest in the web cannot be gauged by how much they support technology funded and evangelized by a bunch of current and ex-Googlers that has little to do with open exchange of information. Conflating it is a strange rhetorical trick.
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.
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 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.
Apple stated in their first statement regarding multiple engines support for PWAs, that it can be done, they just decided not to make it. Also, it’s an about 18 months old law. Not that they wouldn’t have time or resources for that matter. So there was clearly a purpose to kill PWAs on iOS, and it was clearly their decision according to them.
Another thing with EU, you can ask them. And normally, first, you ask them when something is questionable. This either didn’t happen, or Apple didn’t wait, or they already know what is the response. This was clearly a PR move.
So it’s totally understandable when people have problems with Apple, how they handled this.
Just like Apple's 3-months free trial for the Apple Music service, keeping the Webkit-only PWAs were going to be seen as anticompetitive by Apple's opponents.
Making the change early is a strategy to exploit Apple's opponents into loudly decrying how important and useful PWAs are - and that removing PWAs is the true, evil, anti-competitive strategy. (With all of their typical exaggeration, in reality we know PWAs are a limited-use feature.)
In short, Apple played the useful idiots into being their cheerleaders and provided Apple exactly what they needed to maintain this feature.
It didn't even take an "open letter" from "Taylor Swift" to "Tim Cook" this time.
tl,dr: Apple exploits anti-apple rhetoric to get their way, again.
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.
From the bottom of OP:
Significant investment... For apple or app store profits it's just a rounding error ( to put things in perspective).
What is the end result?
I doubt there was back-channeling - Apple is seeing how liberally they can interpret this act. They tried doing the same thing when they threatened to use MFi on USB-C, up until an EU Comissioner threatened to boot them from the market. Plus, making per-company agreements would kinda render the entire "point" of the Digital Market Act moot.
Apple knows exactly what the DMA wants from them, they're just deathly terrified of handing it over.
I think terrified is the wrong take here.
Apple could fully comply with the letter and spirit of the DMA and remain profitable in the EU, but they would be less profitable. They probably have a very good estimate of how much less profitable, and they're doing their best to minimize the impact.
The fear of low-profitability is what drives that behavior, though. You're right that the DMA/DSA threatens Apple's bottom line, but as long as Apple continues to sell iPhone hardware in Europe then they should be turning a profit on hardware margins alone. Apple wants the control at any cost, and it's going to encourage more countries to draft even stronger legislation.
I'm surprised the EU appears to be letting them get away with charging a fee for apps installed outside the app store.
Most companies e.g. Unreal charge a fee for using their SDKs.
The idea that you would be forced to give it away for nothing would be a pretty extraordinary and unworkable intervention in the market.
The fee kills any real world possibility of an OSS App Store though.
1 million downloads for an app sounds like a lot for a paid app.
But on the desktop, popular OSS software packages do those kind of numbers in well under a year. There's no reason to believe OSS mobile apps on iPhone would be any different.
Non-profit organisations are exempt from the core technology fee.
Cool, that might make it workable then. :)
They can charge licensing fees for their SDKs, but the "core technology fee" is not structured that way. As currently structured, it would apply even to an app written from scratch in ARM assembly language (not that a reasonable person would build an iPhone app that way).
CLI apps are not supported on iOS.
So at some point you have to interact with Apple SDKs.
Making system/library calls to display something on the screen does not necessarily require the use of an SDK either; it might require quite a bit of reverse engineering work. As far as I understand copyright, that doesn't involve copying/distributing the library code and wouldn't be legally encumbered unless there's a patent covering it.
Unreal is a game engine, iOS is an operating system.
In almost every other case application software is not considered to be a derivative work of the operating system it runs on. If this wasn't the case, then Apple could have easily sued Cydia and AltStore for offering the equivalent of iOS fanfiction. Hell, even the Copyright Office was perfectly fine with adding a DMCA 1201 exemption for jailbreaking iPhones to install non-Apple software on them - and they're extremely tightfisted with those.
The reasons why this is different is very simple: you don't distribute Apple's SDK along with your application, but you do distribute Unreal's. The user got access to Apple's code when they bought their iPhone, you have to give them Unreal Engine, so you need a license for that.
They haven't hit the deadline yet, lobby your national and EU representatives if you want rid of this.
The DMA goes into force only tomorrow. We will see if they will get away. I guess they will get bonked, because they apply more favourable conditions for their own App Store. They might get away if they would charge the fee for all Developers, but the Bullshit with "staying inside the old conditions" will surely get them into trouble
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.
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.
Is that not what the free market does? When companies make poor choices customers punish them. (Budweiser 2023)
The issue isn't the size of Apple's market share, it's the tying between their hardware, the OS software, and app store, such that if you choose to buy their phone, you also are locked into their app store.
Apple is not subject to market forces because Apple is not a capitalist entity, it is a feudalist one. It is not a merchant buying metal and glass to turn into phones, it is a feudal lord that has put a gate on the river that anyone passing buy has to pay 30% in order to open.
Other than desktop computing, this describes nearly everything sold to consumers. For people in the Hacker News audience, desktop computing would feel like a gargantuan exception, but for most other people it isn't. Android is a partial exception, but one gets the sense from Google's recent behaviour that openness is an unwelcome vestige of its open source beginnings.
It's not an exception. Binary distribution is the norm - Apple founded their business on that norm, found success in it, fostered it and continues to support it on MacOS. The App Store style of distribution is not a replacement for it, especially when the escape hatches for developers cost an annual fee and still has limitations. If it takes legislation to change that, so be it. This is not the future for computing that anyone wanted.
If there's a good reason iOS can't run third-party software, now's the time to fix it. Otherwise, Apple might have to find a new economic zone to invest in.
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.
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.
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.
Yeah, who knows what's inside of OpenSource Firmware like LineageOS. It's a huge mystery
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?
It does not seem to me that anything about the DMA will make it difficult for people who prefer to stay inside Apple's walled garden to do so. Most Android users only install apps from the Play Store and use Chrome as their browser.
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.
You need MFI to use Bluetooth unless it’s audio through the system UI or BTLE
Bluetooth is not part of MFI for any of the standard profiles.
https://mfi.apple.com/en/faqs
There is no evidence that Apple ever planned to introduce a MFi system with USB-C. What likely happened is that leakers misinterpreted the USB-C E-Marker as a MFi chip.
Or that Apple was considering a "made for iPhone" certification program to allow manufacturers of USB-C devices to certify that they'll work with iOS devices -- which would be a perfectly reasonable thing for them to have! -- and misinterpreted that as meaning that Apple intended to implement a restrictive device authorization scheme like they had for Lightning devices.
(Just because newer iOS devices have a USB-C port doesn't mean that all USB-C devices will work with them! Devices still require drivers; if iOS doesn't know how to handle a device, it won't work.)
No, DMA wording made it very clear that it's about web browser engine.
And they cannot make self-preferencing on their products.
And Safari has been explicitly designated as a separate core platform service. There's no room for this kind of interpretation in the view of enforcement entity. Apple is just trying to buy time by pretending ignorance.
It’s more subtle than that. If Apple uses WebKit within one of their built-in apps or OS components, let’s say in their Weather app or some Apple Pay dialog, there surely is no requirement that this has to be replaceable by Chromium or Gecko. Similarly, the PWA runtime environment may not necessarily count as a “web browser engine”, since they aren’t used to browse the web. It remains to be seen how this will be judged by the EU institutions.
It's because those apps are not core platform service. Safari and iOS both are core platform services, which are explicitly designated as a target of this regulation. Go read the actual wording and have some understanding before making this kind of assumption.
When you open a PWA, Safari does not appear. The argument can be made that this is not Safari, but a PWA runtime environment that happens to use WebKit internally. Basically, the PWA is it’s own separate app (i.e. not Safari) that is being run by iOS with the help of WebKit, similar to how other OS features also use WebKit internally. It is not clear at all that this would fall under the category “web browser engine” of the DMA, since using a PWA does not constitute browsing the web.
As for your argument about core platform services, the app store is a core platform service and (I’m pretty sure) uses WebKit internally, at least for some of its pages in login and payment flows, and similar for various iCloud-related functions accessible from Settings.
I’ve read the DMA, you don’t have to be condescending.
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.
You're certainly taking some elements in liberty. It remains unclear how defining WebKit as a "PWA runtime environment" exempts it from the terms of the DMA or DSA.
Sorry, but at this point it’s you who have to provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing.
Just to be clear, I’m absolutely in favor of having a free choice of PWA engines, I just don’t see this being implied by the DMA and the present gatekeeper designations. The question really is how a PWA runtime environment differs in principle from the regular iOS app runtime environment, which the DMA also doesn’t mandate to be replaceable.
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.
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.
I'm not sure if you've only read some digests but not the full text including other supporting materials (it matters since this defines how the laws will be applied) since all you mentioned are already addressed in the designation decision doc. To be specific, in DMA.100027, EU clearly stated that it doesn't matter whether it's embedded in other apps or standalone:
If you've seriously worked on hashing out all the details of CPS and clearing up the ambiguities, you cannot be unaware of this decision since this will impact everything on your daily works. Yeah I did that because the precise definition of CPS was critical for my work in the last year.EU is not that dumb, to my understanding they've been pretty serious in respecting the spirit of this specific legislation. You cannot say that some part of it can be simply opted out by adjusting the definition of your product. What they care about is how business is done and make the market control out of it.
This is in fact how PWAs work on iOS. They do not run in Safari at all, but in a special runtime called Web.app, which is coded to use WebKit. Safari doesn’t have the ability to do the things the PWA runtime can do. Letting other browsers “run PWAs” would not be a matter of exposing an existing private API, it would require creating a a brand new plugin API for Web.app that would allow inserting other browser engines into it.
Surely the distinction is about the existence of a market. There is a market for competing browsers from different vendors which do compatible/interchangeable things that might be selected by different consumers for different reasons. The technical definition isn't the important bit, the regulation exists to preserve that interplay between consumer choice and market innovation.
There is no such consumer-driven market for in-app UI libraries, be they WebKit-based or not. The "consumers" in such a market would be the app vendors, and in fact this is an area well-served by existing products from competing vendors. That's clearly not what the DMA is trying to regulate.
You’re misreading pretty much everything you’ve quoted from the DMA.
You follow this up by quoting a clause that manages core platform services.
What it says is:
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.
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”
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.
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.
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.
They were basically negotiating in public. I think the EC probably realized that the DMA as currently written is flawed and producing outcomes they don't want, and this episode basically highlighted it to them. They probably told Apple there won't be any enforcement against only Safari having it, because the alternative is worse. A basic principle is that you are very unlikely to compel Apple to engineer anything unless they choose to, and you would most likely lose in the EU courts if you tried to. Any regulation that doesn't factor that in is going to be doomed to fail.
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.
There's a big difference between those cases. In the USB-C case there was no room for argument. It was either include the new port, or stop selling the iPhone.
In this case, they could just remove entire features and have the public do their lobbying for them.
It shouldn't be too hard to make the case for that being malicious compliance, though. It seems to have worked in this particular case, for example: People called Apple's bluff.
Malicious compliance and "spirit of the law" aren't real things when it comes to the legal system. You either comply with the law or you don't. And courts will ultimately decide if Apple's interpretation of the DMA complies or not.
They are, in Europe. We don't really like companies not following the spirit of the law. Companies usually learn via fines. Luckily for us, Apple is a slow learner.
Why is that lucky for us? We want them to comply to the DMA. The fines are a drop in the bucket.
It’s lucky because to a lot of android fans it isn’t really about consumer outcomes, it’s about finally legislating a solution to the android-iOS war.
If you can’t win in the marketplace of ideas, just ban walled gardens entirely. Flip the table and ban your competitors’ business model, bioshock style.
Now of course, since obviously most android fans aren’t actually owners of a major company… they aren’t really “your competitor” unless you’re parasocially attached… this is a rather obvious commentary on the degree of parasocial attachment that so many people seem to have towards android and against apple… but here we are.
https://paulgraham.com/fh.html
In short: Freudian slip. They said the quiet part out loud. Hurting apple is the goal here.
Spirit of the law is literally a thing and EU courts interpret in line with it. Each and every EU directive has first lines state the spirit.
Malicious compliance is totally a thing in this specific case and is expected to happen. The act itself is written in a very pointed way so to say.
To make matters worse, the executive is given powers to tell Apple what exactly they need do to comply if they start funny business.
Companies are compelled to develop features all the time. Mostly so far in the EU these features have been around accessibility, safety, and crime prevention, but there’s an awful lot of precedent for companies being required to develop something specific in order to be able to sell their product in the EU.
Companies comply with those regulations because, on balance, the incentives still make it logical to. That doesn't mean an unbalanced regulation that misunderstands the target's incentives would result in the outcome the regulator wants.
The law requires Apple to open up iOS to 3rd-party browser engines and that Apple can't self-preference their own browser. This would mean that Apple has to open up anything that Safari can do (like run PWAs).
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
Are PWAs browsers?
They're pretty much just shortcuts/bookmarks to a browser window yes. If I "install" a PWA from Firefox I expect it to open in Firefox. I would be very surprised if I ended up in Safari instead.
What happens to those PWAs when you uninstall Firefox?
yeah, it should just open up in the default browser setting within the OS. having to create a shortcut based on which browser would be ridiculous. must like the post you were replying to was a ridiculously proposed comment.
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?
We just don't know that at this point.
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).
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.
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.
It does:
Clause 7 Article 6 of the DMA states:
Hopefully they'll respond with huge fines.
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
That's not true. The section the blog post is quoting is saying that the EC can ask another regulatory body to make a decision specifically on whether the technical implementation of interoperability requirements is sufficient.
So it's only about a very thin slice of the DMA to start with, and a slice that's not the part that Apple was intending to violate when removing PWAs, but it's also not a process that Apple could trigger or even be a party of.
As far as I know, nothing in the regulation suggests that gatekeepers can get their compliance plans pre-approved or pre-rejected.
That's the beauty of reading: you can read more than just the quote, and read the paragraph immediately after. Or the referenced section in the law: https://news.ycombinator.com/item?id=39565987
65 allows asking the EC for clarifications. But that process would (very explicitly) need to be public and allow input from third parties, there's no process for private feedback. In addition to that, the EC might choose to ignore the clarification requests entirely, and whatever decisions they do give are not binding.
It's certain that Apple does not have any kind of back channel approval for keeping PWAs Safari-only. That is not a possibility within the regulatory framework.
Apple didn't have to ask though, they fully knew they were breaking the law here. They are only backing down because of the pressure from the web community and from the DMA team starting an investigation.
They knew they were breaking the law in their lack if browser choice.
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.
The DMA plainly states that they have to give other browser vendors access to all features present on device, and that they cannot degrade the quality of their services.
Removing PWA support goes against both these obligations.
Nope, that’s not what iA says, and it would be a gross misrepresentation of the DMA to be honest.
The section they’re referring to is clause 64 in the lead of the DMA[0] and it is not only limited to cases of interoperability, unlike what iA implies it doesn’t follow with a suggestion that gatekeepers can just ask if they’re unsure. Instead it states:
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...
1: https://9to5mac.com/2024/02/26/apple-blocking-web-apps/
64: says that gatekeepers should provide a reference of what they are intending to implement, and commission will say if it's in compliance
65: For anything more complex we can have an extended dialog
There’s always back channel that’s how these things always work. One team of lawyers hashing it out with another.
Does this mean that users will only be able to add the pwa from Safari or that when adding it from any browser it will always run with WebKit?
Great question. Orion is built on WebKit and works with firefox extensions (uBlock)
That works (I suspect) because they run them as JavaScript in a different browsing context and have implemented some of the WebExtension APIs themselves on the backend, e.g. HTTP request filtering (which is one of uBlock's primary functions).
That's a nifty workaround but not ideal, since it's not possible to actually provide all WebExtension APIs that way.
Presumably that you can only add the PWA from Safari, because there does not exist any API to add a PWA from a third-party app.
Yes there does, other browsers already use it.
Other browsers can already add PWAs. Presumably they'd just continue using WebKit to matter what engine the browser in question uses.
The final authority lies with the courts. If any of the third-party browser providers sue for being disadvantaged by PWAs being restricted to WebKit, no previous “back-channeling” with the Commission will have any bearing on the judgment. And the Commission knows this, so is unlikely to engage in that manner.
What you said is true but not to the extent that you might think if you are used to the legal systems of countries like the USA or UK.
Since Brexit, almost all EU member countries follow the civil law system (the only member country following common law that I can think of is Ireland, not sure if there are others). https://en.wikipedia.org/wiki/List_of_national_legal_systems
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.
The authority of the courts is the same, it's precedent which has less relevance in civil law systems
Setting the agenda matters. This drama probably made more people and businesses aware of the DMA and may influence the focus of some participants. For example, there's an "Apple DMA compliance workshop" in two weeks, to which interested stakeholders can register: https://digital-markets-act.ec.europa.eu/events-poolpage/app...
On android PWA home shortcut create by one browser, will use that browser, regardless of default browser. I don't see why Apple couldn't do the same.
Apple provided theirs reasoning on this (security issues due to how iOS is currently written...) when they initially stated they would be removing them and said the work was'nt worth the tiny base of users who use it.
Only technical reasons. When PWA’s were introduced in iOS 11, they were built with the assumption of WebKit as a privileged process. A re-arch is definitely doable, just a big expense for little return. And probably not feasible in just a year, can’t imagine it would be a top priority against all of the other work.
Who else even does PWAs? Firefox removed them which leaves chrome, edge, and now maybe safari.
Firefox still supports them on Android, and macOS just introduced them (last year IIRC). In other words, every major OS has at least one implementation!
I think nobody in the EU can make such assurances. It's a law, and courts will decide if apple is following them.
The European Commission announced a few days ago that they will look into the decision of apple to remove PWAs, so they more or less announced they are trying to fine them because of it.
Which means that completely removing PWAs could be the more risky choice instead of keeping them Safari-only. Completely removing PWAs already started an investigation. Keeping them Safari-only might not start an investigation at all, so it might be the lower risk.
After all I think Android also has a Chrome-only implementation for PWAs, exactly like Windows, that runs PWAs on Edge. Also back in the days when Microsoft had to give users a choice to use another browser than Internet Explorer it was also not possible to exchange Internet Explorer as the engine for many system services that used the system web view component. I think it's still the case with the current Windiws WebView2 based on Edge.
This 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).
I hope that the UK CMA enforcement action will smack Apple over the head for this one.
...to what end? Removal of the feature from iOS in the UK?
Devil's advocate: having a stable (maybe too stable) runtime for all iOS PWAs might actually be a benefit. Native apps, for instance, don't have to worry about rendering issues in various "viewers." This actually brings PWAs closer to the world of native apps, which I believe is what users would prefer.
That said, I literally did a jump for joy when the DMA news broke. (Then of course, I did scream bloody murder reading the details on PWAs.)
There's no such thing as an iOS-only PWA. You need to test with other browser engines regardless because other kinds of devices still exist.