30 some million lines of code in chromium browsers.
Thats bigger than the linux kernel.
The HN crowed might not LIKE apples response but they have a very defensible position.
Edit: Its not like we haven't seen this play out on the desktop recently: https://www.theverge.com/24054329/microsoft-edge-automatic-c...
What you link is a case of one app (edge) reading the data of another app (chrome), which is entirely unrelated to PWAs.
Indeeed, and 'whatever browser engine you picked here' is responsible for correctly implementing these additional security features.
That's the argument; if you write an app that lets you run other apps inside it how do we make sure your app does security correctly?
When you look at it from that perspective, you can see that unless at an OS level you provide additional 'meta-security' features that allow apps that run in other apps to have fine grains access control that is managed by the OS, it's pretty much "security? Well, whatever...".
Right? I mean, whether you agree or not, it's a pretty reasonable position to take and it entirely makes sense.
I don't think that's the only solution. A simple alternative is to declare that "apps that run in other apps don't get to do anything at all."
I.e. in this case, in response to a EU requirement to support alternative browser engines, Apple could — rather than disabling PWA integration altogether — drop all additional privileges that PWAs have that regular webpages don't.
Make installed PWAs in the EU market into just "webpages, but with a home-screen icon, a separate task-manager card, and no address bar." Which is 99% of the reason anyone installs a PWA anyway. No camera/microphone, no extra storage, etc. Not for Chrome PWAs, not for Safari PWAs; not for any PWAs (on these devices.) They're just webpages presented differently. No "meta-security" required!
And the nice thing about PWAs, is that there's no way for a PWA to know or care that it's being run "installed", and change its expectations/requirements — as there's just no web API for that. Instead, a PWA must just attempt to talk to each of these permission-gated APIs it wants to use, and find that it's now being [prompted for and] given access to them, rather than silently refused them.
So, unlike tightening the security model around regular native apps, tightening the security sandbox around PWAs shouldn't actually fundamentally break them — they should be designed to gracefully degrade when refused these capabilities. Presuming these PWAs were already ordinary fully-functional web-apps, which have just been progressively enhanced with these features when and where available, they'll just act like they do "on the web" — which should still deliver on the app's use-case. That's what the "Progressive" in "Progressive Web Apps" is supposed to mean!
Of course, some PWAs 1. will have been designed from the ground up as PWAs, and 2. will have a purpose/use-case that's very specific to the use of these high-integrity web APIs, such that they're completely useless without these PWA-only permissions. A video-chat PWA, for example, won't do much without access to your camera + microphone. There's no point to using these webapps as webapps — and often they don't even let you do so (i.e. they attempt to access the specific API they need on launch; if they succeed, they render the app UI; if they fail, they render a prompt to install the PWA.)
I don't know if you'd really call these PWAs, since there's nothing progressive about them — there almost needs to be a different term for these apps that need the high-trust APIs to do anything-at-all. For the sake of discussion, I'll refer to these as "Elevated Web Apps" (EWAs), since they require elevated permissions to be useful.
It's only these Elevated Web Apps that would benefit from having what the GP called "meta-security": the ability to interact with the OS security on a per-webapp basis, through e.g. an Android-like install-time gate where the app presents a capabilities manifest (displayed to the user as a set of permissions it wants) and the user makes a decision of whether to accept that.
And, if Apple simply neutered PWAs rather than removing them, it's only these Elevated Web Apps that people would "miss out on."
As cool as PWAs are as a technology, these Elevated Web Apps are a true minority or them — maybe 1% or so.
And — at least as far as I know — almost all Elevated Web apps only exist for one of two reasons:
1. to serve use-cases that users with access to native apps from an app store, just have no reason to care about. (Specifically, they were developed to allow users to accomplish native-app-equivalent things on OSes that don't support any kind of native apps — like FirefoxOS nee KaiOS, or early ChromiumOS.)
2. to benefit the developer at the user's expense, by forcing the user to give the developer permissions that allow the developer to spy on the user more effectively, before the app will work — but where the app doesn't actually do anything with these permissions to serve the use-case. (I've seen a few scammy Chinese dating sites demand to be installed as a PWA for this reason.)
In other words: on iOS, at least, you probably won't miss them! (Especially with the third-party App Store ruling also in place in the EU! Things like emulators don't need to be relegated to "WASM running in a PWA" any more; in the EU, they can just be third-party-store apps!)
so, Apple? Since Apple has also required browsers for years to use their own safari backend, this isn't even an issue of "oh well it doesn't work on Firefox".
Sounds like they cornered themselves there.
I imagine that if you’re on HN you are close to developers or are a developer yourself.
And if so, I imagine that you have already had an important customer (to who you cannot say “no”), completely change your plans and architecture with a new feature request while setting an aggressive deadline (ie, you don’t have time to implement everything and must make choices)
Now replace you with “Apple” and “important customer” with EU.
They had 1,5 years from the time of being identified as gatekeepers to work on this.
The DMA was voted on by the EU parliament and then the council in july 2022, Apple was identified as a gatekeeper in september 2022, the law became legally implemented in november 2022, with gatekeepers required to comply with it by march 6th 2024.
I do not buy for a second that the richest tech company on the planet, that owns, designs and manufactures the whole tech stack their product uses was unable to respond in due time to the legally required changes and so 'just had to go this route due to time constraints'.
They don’t see money with PWA at this point in time and therefore decided that breaking support was not a big deal.
It obviously outrages everyone on HN, but HN is not your average customer of Apple.
However the parent argument was a weak one, and so had to be answered with facts.
Sure. I sure do wish the demands were actually consumer centric, and not "force all these advertising tracking into your site, tank performance, and grab a bunch of unneeded user data".
And of course, if I maliciously complied and "oops the tracking only gets 1% of user data", I would simply be fired instead of get another strongly worded letter leading to meetings re-defining what "grab a bunch if unneeded user data" is.
EU is the “important customer”, the users of PWA are “other customers”.
Using your example, you would implement tracking for that important customer (and comply 100% to the requirements as Apple did) but because of this additional bloat, the website would load 2 times slower.
After a discussion with your colleagues, you would realize that:
- Most users won’t care about the slow loading (including the important customer)
- Re-architecturing the website to keep the same level of performance while adding the necessary tracking required by the important customer would delay shipping the tracking by 1 year, past the 2 months deadline required by the important customer.
Back to your desk, you start implementing the tracking that will incur a 2x slower load time.
I'd love to one day work for a place where I can dismiss monetization as "the other customer". But alas, my career hasn't been that friendly.
>Using your example, you would implement tracking for that important customer (and comply 100% to the requirements as Apple did) but because of this additional bloat, the website would load 2 times slower.
Given how the topic is:
>Following developer complaints and press reports about how PWAs were no longer functional in the EU after installing the most recent iOS betas
I fail to see how the EU is the "important customer" here. And not the powers that be in Apple telling me to maliciously comply.
The EU said "allow other app stores to exist" and my theoretical manager at Apple is saying "okay, PWAs can exist but they don't have to run well. Add in unnecessary security (because the NA version doesn't have it) that disables functionality". I don't even see how it has to do with complying with the EU, unless it's soke long term OS lock down for future app stores.
Tell me how the EU here is the one telling me to slow down my OS/browser?
But browsers already have this security features that isolates websites from each other? How come PWA, which essentially just placing a website shortcut in the home screen and hiding browser ui, affect browser's existing security features?
But that is a new retort when I ask that same question most of the time. Often it’s because of mean old Apple that PWAs aren’t more popular on Android.
But since now that there will be alternate means of distribution in the EU, you should be okay with no PWAs in the EU?
> But since now that there will be alternate means of distribution in the EU, you should be okay with no PWAs in the EU?
I see, a hardened Apple defender. Nice show of cards! There are no alternative means of distribution in the EU that don't involve paying large sums of money to Apple, but you already knew that.
My second point is if it just Apple and Safari holding back the adoption of PWAs, then why aren’t they more popular on Android if Chrome is so much better?
Why aren’t companies creating PWAs for Android to avoid the same 30% cut? Are they okay with paying “large sums of money” to Google?
Why aren’t they using third party app stores on Android or letting users download directly from them?
(And the HN gods are mad at me for some reason)
It's all just code sandboxed by the OS. Apple is just being pathetic because they couldn't force legislators to do their bidding.
Yes, and Apple now (against their will) allow me to select this browser myself to browser the web with.
Whether I use this to load a webpage normally or as a PWA does not change the risk I was exposed to. PWAs just let a web application ask the browser to run "fullscreen" without browser chrome, to set its badge and colors, to register as a handler for certain URL types, and to open the share panel. All actions already taken regularly by said browser.
Even if we assume Apple's statement that other browsers are insecure is correct, there is no value in blocking PWAs and requiring me to instead use bookmarks: I am still loading said application in said browser that implements and uses all this functionality itself. To the OS, a PWA is nothing more than a type of bookmark for a browser.
So, no - this is not reasonable and their argument makes no sense. If it was true that Safari was actually safer, then Apple should instead spend energy sharing how so that other apps can be equally safe - it would be incredibly irresponsible for the platform owner to keep security as secret sauce - rather than handicapping other apps.
In one sense, sure.
But in another sense Edge taking Chrome's tabs means Microsoft is getting insight into Google's data. A lot of Apple's defenses seem really targeted at reducing the ability of Microsoft, Google, and Meta to extract value from Apple's users. Apple sees the union of all the app data, but their competitors can't put together that picture. So in that sense, Edge eating Chrome data may be the sort of thing they're looking to prevent.
Ofc, like a bond, a user pays for a reason: he gets something out of the facility provided by Apple, in kind.
The real issue, however, is that Apple is not saying “we need more time to implement the APIs”, which the EU would very likely concede, but “we don’t think it’s worth it for us”.
That does not mean that their decision is the proper one, just that it's legally ok.
We do this all the time. I don’t uniquely depend on Microsoft for stuff that runs on Windows. Same for stuff that runs on macOS. And on Linux I’m not even sure who I’m trusting from the ground up other than a huge and disparate collection of people.
So what makes iOS so unique that it can’t run PWAs, which is little more than adding some chrome and a handful of APIs to already pre-existing browser capabilities.
What an F’ing joke. And the bigger joke are the Apple fans who are going out of their way to defend Apple sticking it up their nether parts.
This seems to be over-generalization? Users are using Apple devices because those are good products, not because they want to delegate every single trust problem to the Apple ecosystem. That might be a great proposition for people like you, but there is a significant number of people who consider it a compromise rather than a value.
As a long time user of Windows which historically had an incomparably large amount of security incidents, I can assure you that Apple won't get blamed that much for 3rd party data breach unless it involves Apple's own service and user data.
I’m talking about the general public. If a story about a data breach in a 3rd party app — affecting iOS users — hits the news cycle, Apple will take the blame and their brand reputation and sales will be impacted. It doesn’t matter whose fault it really is, Apple is the face of the iPhone and through their walled garden they have accepted final responsibility for everything that occurs on iOS.
You can draw a direct line between Apple’s original marketing pitch (easy to use, simple, secure, appliance-style computing) and the iOS walled garden. Just as you can with Disney and their family-oriented brand. It’s not a compelling argument to say that other film studios have nudity in their films when Disney is the brand at issue.
They didn't take security seriously when they were laying down the architecture for Windows because they didn't think they had to. Apple is taking the exact opposite approach. They're fairly obsessed with security and privacy because that's one of the big selling points for the whole iOS ecosystem. They miss things because they (like us) live in the real world but they do pay a lot of attention to it and the number of updates for things like 0day defects that arrive within days of the defects being reported tells me that this continues to this day.
Apple doesn't have a monopoly. Per https://gs.statcounter.com/os-market-share/mobile/worldwide Android has twice the market share that iOS has. The reason for all of this generated drama is found in https://www.businessofapps.com/data/app-revenues/. The key bullet points are:
"App Revenue Key Statistics
* Mobile ad spend in 2022 reached $362 billion, a 7.7% increase on the previous year * Android and iOS app consumer spending increased to $135 billion in 2023 * iOS was responsible for 66% of app consumer spending in 2023 * Games accounted for 60% of consumer app spending in 2023. Google Play contributed 41% of the total amount * Subscription revenues increased to $45.6 billion in 2023, iOS was responsible for 76% of that revenue"
The real reason for all this foolishness can be found in these bullet points. 66% of $135 billion is $89.1 billion, and lots of people would love to get a piece of that pie without dealing with Apple (who built and owns the stack). It isn't a monopoly, though, and all of that monopoly talk is misdirection.
I suspect that from Apple's perspective, it is definitively not a significant number.
For Apple, ownership of the "trust problem" is an intrinsic part of "making good products".
Yes, this might be true. And the majority of elected officials in EU fundamentally disagrees with that statement.
Well, EU can and will force, fine, or ban US companies as they see fit but there is not some fundamental correctness to their viewpoint
Indeed, who apple is or isn't able to sell to, doesn't affect what people think is moral or immoral.
As for Apple's CEO representing Apple's customers: Are you sure? We didn't elect him. We just bought stuff made by an organization he currently runs.
I'm saying that customers decide whether or not to buy from Apple based on whether they resonate with them from a moral standpoint, at least as part of their decision to purchase their products. And I said Apple's CEO is accountable to their customers, not that they represent them. Yes, they're also accountable to shareholders, as your sibling comment points out. But if the company screws up enough to elicit a popular boycott, you can bet the reason shareholders will be exercising that accountability is due to the actions of the customer base.
> I'm saying that customers decide whether or not to buy from Apple based on whether they resonate with them from a moral standpoint
I fully believe that you might do that yourself. There's no evidence everyone else does, or even that a majority do. Especially since most people aren't informed of working conditions involved in manufacturing Apple products (or indeed, many others' products).
It's just not believable that everyone thinks that buying a product = agreeing with every single moral stance made by the person currently running the company. And what if he changed his mind tomorrow? Would he offer a full refund to everybody who asked for one?
> And I said Apple's CEO is accountable to their customers, not that they represent them.
He's not accountable to them, only to the board*, but we're discussing representation - that is, speaking on behalf of a people, according to those people, not you or I or the speaker individually. If you mentioned accountability while we were on the topic of representation, and I returned us to the topic of representation, you're welcome :)
[*]: Your example illustrates this: a complex chain of accountability from CEO to Corporation and BoD to Corporation and Corporation to shareholders is required for any action to happen. Being accountable to customers means customers can decide to fire him _directly_.
Because they are interrelated concepts. Without accountability you can’t be trusted to faithfully represent someone. “Representation” without accountability is autocracy.
Also, chill with the condescension.
In this case, though, the CEO is not accountable to customers, and the CEO does not represent customers, so not too confusing. He is accountable to the BoD (nobody else can fire him) and represents the corporation. The interests of other parties, including customers, are secondary to, and when opposed lose to, the interests of the corporation.
It has control over the people living in China, true, but I do not think controlling a person, being able to put them in jail if they don't obey you, is the same thing as representing them.
Politicians aren't expected to be experts due to the immense breadth of subjects they need to consider - they're expected to consult experts. Whether an individual politician is an expert[1] is pretty irrelevant.
All of these statements are about our general expectations of politicians - whether you think politicians adhere to that point or have comments on specific politicians is beside the scope of my comment. As a less controversial example it might be good to instead consider how judges operate who are expected to provide well reasoned judgements on subjects they know nothing about.
1. Sometimes those former expert politicians are the worst of all since they _think_ they know the way things are and won't listen to actual experts but they've been out of the industry so long that they've lost their familiarity with the subject.
That didn't go hilariously wrong, though - the internet is a series of tubes. Not physically (copper cables aren't tubes) but he obviously wasn't talking about specific stuff but broad-strokes analogy (his exact line was "It's not a big truck. It's a series of tubes."), and his description was basically accurate.
People don’t think of it that way, they tell themselves all the reasons why that’s a good thing, but that’s ultimately what it is - a legislative solution to end the “android vs iOS” debate for all time.
The argument is walled gardens shouldn’t exist, so the solution is to either legislate requirements that apple destroy the walls, or that they exit the market. That is a statement that most android advocates would agree with.
And the EU will largely just keep ratcheting up the legislation until that happens. Driving apple out is the point - walled gardens are (in the EU sense) unacceptable and the option for a walled-garden business model needs to be removed from the market.
Apple is (correctly) perceiving this and pulling out of the market, first by dropping the affected features, and I’m sure there will be a “next compliance requirement” before many years too.
1. Still hoping to see something amazing RIM!
That'd be "corporate freedom" rather than "end user freedom" yeah?
That's my impression of what the NA model of freedom seems to mean these days.
This actively reduces freedom, the freedom of running your business. You just don't care about it.
If you don't like walled gardens you can just not use them (I certainly never bought anything Apple for this very reason), there's no need to infringe on the freedom of everyone else who wants to use walled gardens.
The EU is in general becoming increasingly less free, thanks to barely elected bureaucrats who line up their pockets with sponsors money.
1. I'd point to a great example from one of our current justices in this regard: https://www.theguardian.com/law/2017/mar/23/neil-gorsuch-sup...
No-one's forcing Apple customers to go outside the walled garden. They can still source their apps from only the Apple App Store.
That's not just an EU problem though. It seems to be well established (and perhaps worse?) in many places.
Companies are designed and allowed, by characters, to operate within the scope of whats good for society. If it harms the public good then it needs to be reigned in. I have no illusions that companies have the same standing and rights as living beings do. They are lifeless entities meant to be subject to the will of people.
In the same way Right to Repair, Minimum Wage, and Disciminatory hiring affects the freedom of running a business, sure. Unfortunately, rules are written in blood and this is happening because other businesses at this point abused the point of labor or customer satisfaction and needed to get dinged for it.
In this case, Blame Microsoft, I guess. Heck, even Google. we already know the result of a closed system abusing its platform and large share to make its product worse. I'm glad we're actually jumping into this before it's too late (like we usually do).
if someone wants to sell systems where the only supported configuration is SELinux, why should that be illegal?
For general populace good also include secure by default.
"every single trust problem to the Apple ecosystem." is rather technical point that very few people would even understand meaning of it.
> significant number of people who consider it a compromise
How significant compare to iPhone user base?
Apple has no interest in working with public institutions that have a close relationship with the people they serve. That's a big red flag in my book. You cant trust a company that serves content and hardware and at the same time trust them with security. It's too many eggs in one basket, to easy of a target for rogue entities (NSA) even if they have good motives .
I don't hate Apple, but rather realise that it's bottom line and fiduciary duty to its shareholders is stronger than what is best for us (consumers/developers).
I do not trust the corporate marketing one bit (and honestly, why should I?).
This behaviour of Apple just further supports that view. As a company, it seems to believe it is somehow above following the rules meant to benefit consumers/developers, something the conpany has been marketing its self with since the 80's.
So lets stop the 'Leave Apple alone (and us that work there)' crying, and just acknowledge what the whole thing revolves around.
Seems like they hate us (developers) back though so it’s a mutual relationship I suppose.
Have you seen the world around you for the past 20 years or so? I'd say this characterises developers (well, companies they work for at least) quite well, don't you think?
But there are some trying to scam you…and some of those are also in the App Store…as long as they use IAP to scam you all is well.
What Apple and some users here are saying that users don't have intelligence to judge it and so will have to trust only Apple.
Trusting Apple is nice in the US where it's probably a net contributor to the country's development. Elsewhere, not so.
That just doesn't exclude trusting others as well.
Except that's exactly what Apple is saying. Their engine -- and their brand depends on it -- offers users assurances arbitrary engines do not offer. Apple says PWAs are safe because Safari is safe, while not-Safari PWAs are not-safe.
And, if not safe, Apple is at least accountable.
Google's brand, for instance, does not depend on it: https://www.engadget.com/the-morning-after-google-will-settl...
They are just afraid the browsers will host PWAs better than Safari does, making them a more viable alternative to the App Store.
You misunderstand. If a foreign browser engine was to be made available for PWAs, it would be because the user installed the browser and browsed the web with it. In other words, if loading a web page in this browser was unsafe - which is what a PWA is - the user would already be compromised. PWA or bookmark does not matter.
PWAs do not change the risk profile. PWAs only get a few extra APIs, but nothing major. Location, microphone, webcam, bluetooth, usb, etc. are all standard web APIs available to web pages, not PWA specific.
The argument that PWA specifically has a special risk profile is null and void. The only sensible reasoning is that Apple is strongly against opening their platform at all (their way of implementing compliance is borderline malicious), and maybe want to weasel their way out of any effort they can avoid (allowing users to install new types of apps is zero work, changing which app opens a link by default is near-zero, while allowing users to replace the engine for PWAs require a bit more integration).
Since when was loading web pages ever considered safe, at least by those who actually breathe computer?
It's frankly alarming how much trust we (must) give to Arbitrary, Remotely Executed Code(tm), especially given how many attack vectors are remote code executions.
I honestly prefer to pay a vendor who will (a) complete a product until it's usable (b) be motivated to maintain it because they are paid and (c) be motivated to maintain it because they are scared of the bad PR of not maintaining it.
43 points by vitplister 4 months ago | 32 comments
https://news.ycombinator.com/item?id=37875370
Apple fined $8.5M for illegally collecting iPhone owners' data for ads (gizmodo.com)
334 points by nixcraft on Jan 8, 2023 | 134 comments
https://news.ycombinator.com/item?id=34299433
Apple's Cooperation with Authoritarian Governments (jessesquires.com)
468 points by ig0r0 on March 31, 2021 | 291 comments
https://news.ycombinator.com/item?id=26644216
Apple reportedly dropped plan for encrypting backups after FBI complained (2020) (theverge.com)
425 points by samename on Jan 14, 2021 | 137 comments
Second, it’s entirely dependent on the regulation whether it crushes (or even just hurts) a behemoth.
Yes: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
I tested just now in Firefox with an app from https://appsco.pe and it does indeed work!
I can do the same with the Android version of Brave.
> If you install Firefox it uses Gecko but still has native app look feel?
That depends on your definition. Making an app _feel_ native is a matter of implementation. But the opposite is also true: A native app is free to feel non-native if the app creator makes it that way.
The app does show as a distinct entry in the app switcher, but still has a Firefox icon when I tested it just now.
I tested just now in firefox with an app from https://appsco.pe and it just...opened a browser tab with the website.
So I understand a PWA is just a website but isn't the whole point to have a dedicated window/card for it?
It looks like appsco.pe has some incorrect entries in its list of PWA.
So if you install a PWA from Firefox it runs in Firefox and from Chrome it runs in Chrome similar to desktops. Looking at it this way I could see Apple doing something similar with less effort than trying to standardize a web view API and have PWA use the "system default browser".
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
https://web.dev/learn/pwa/tools-and-debug#using_physical_dev... at "Firefox Remote Debugging" says there's a way to debug Firefox for Android PWAs.
So I'm fairly sure the PWA is running using Firefox for Android.
I also never accepted the terms and conditions for Chrome on this phone.
Google's very means of income relies on gathering and to an extent sharing your personal data.
Edit: and "Android" as in the AOSP (where PWAs still function) does not sell data.
You and Apple both are ignoring the fact that these permission APIs exist even if the website isn’t being displayed in standalone/full screen mode. The modern web is built on them, and third-party browser engines WILL provide access to these APIs in Europe.
This is just Apple wanting to avoid people being able to develop a platform on top of their platform without paying a tax.
Likely, most are worried about the other direction.
And yes, if Windows had this feature and then Europe demanded it work like I described, Microsoft would be acting reasonably if it disabled the Desktop App feature in Europe.
Apple doesn't disable competing browsers, it just doesn't allow different web engines to underly the browsers. You can argue with that but it isn't the same as "uninstalling all competing browsers".
I understand that they've built this image of being a grand infinite protector for all their users within the walls of their garden, but they've had plenty of security issues within their own software, and plenty of cases where application developers have sidestepped their rules.
This relationship of trust with Apple is cultish at best. To say that I can trust Apple but not Mozilla? What are we smoking here?
Have you ever worked an IT support desk?
Will you blame the software maker that you used to install the icon on the screen? or the one that is seemingly unrelated to the icon on your Home Screen?
That sounds like a bad UX. At least make the existing PWA stay with Safari and provide the ability to switch the underlying engine for each PWA afterwards if migrating is possible.
They can either allow third party browsers the elevated system access that Safari currently has in order to be able to access the data for multiple PWAs ... which compromises Apple's security standards, but puts Safari and other browser engines on the same footing.
Or, Apple can remove the additional security permissions that Safari uses in order to access the data of multiple PWAs so that Safari and other web browsers are on the same footing again.
Or, Apple can invest significant time and resources into creating a new sandbox for browser engines (including Safari) such that a PWA running in the browser engine will not be able to escape and access the elevated permissions of the browser engine or the data of other PWAs through a flaw in the browser engine.
Given the amount of effort that the third option would take, the low adoption of PWAs from most users within the European market, and the not going to compromise on the first option - the second option of removing security permissions from Safari (and other browser engines) to run PWAs is the only option to comply with the law in Europe.
That’s a fable. Apple have a good history in security design. There is absolutely no way Safari have some "system access" that another app can’t have. Safari is probably just as sandboxed by the OS than every other app or else that would be an incredibly stupid decision.
If Apple wanted to implement PWAs correctly, they’d just run whatever engine + the web page in the same solid OS sandbox and there wouldn’t be any more security issue than with any App Store App.
Any iOS dev knows that it’s impossible for any app to gain any useful access without being granted the permission by the OS. The point is Apple is stuck being forced to hide that the security model of iOS is based on this (working well) sandboxing because it goes against their narrative that all the security comes from App Store policies (which they technically can’t enforce because all they’ve got to review is binary code).
Does Safari, as the browser engine running PWAs have access to the data of multiple PWAs?
If so, and Apple has good security - that's not a problem.
However, if Safari does have that access to multiple PWAs local data, and a different browser engine is used and also needs access to multiple PWAs data stores in order to be able to run them, what can Apple do to ensure that one PWA can't break out of its sandbox within the (as an example) Firefox PWA runner and access the data for another PWA?
If Apple cannot ensure that all browser engines have the rigorous design and/or history of security design and promptness of rolling out fixes when 0 days are discovered ... should Apple grant the additional security access for a 3rd party browser engine to be able to access the data of multiple PWAs?
If Apple should not grant that access because the other browser engines may not be as secure, then Apple (according to the law) must not grant its browser engine any favored position within the system.
The way to fill that requirement is to either figure out how to create additional sandboxes within 3rd party code so that PWAs running within FireFox cannot break out of their sandbox to access other PWAs ... or remove the ability for Safari to run PWAs all together.
And you pointed out yourself ... "If Apple wanted to implement PWAs correctly," - they apparently didn't implement PWAs correctly and are using sandboxing within Safari rather than sandboxing the PWAs and Safari combination at the OS level.
Should Apple invest the time to fix Safari and PWAs and 3rd party browser engines? Or given the low adoption of PWAs, is it less work and better security, and only a marginal loss of functionality to remove PWAs from Safari?
Why wouldn't Safari remove all its PWA icons when I uninstall it, considering that it anyway cannot transfer the data to another browser...?
If I was not I can choose to leave.
I know this is a divisive comment. Please see my further extrapolation in a child comment.
In this case they have to change the integration and sandbox model to allow the security policy to remain intact for people who want and need it. That breaks a few things but it stops the integration from being used for exfiltration among other things.
Note that they're not completely breaking it, just ensuring that the security model stays intact when browser engines have to coexist on the same device. That means sacrificing some convenience for security.
If this prevention is by OS security, then your complaint is about the OS.
If it us by store guards, then yiu complaint is about the store.
So sorry, but I don't see how your complaint is properly about the browser engines.
Not everything is a conspiracy.
Equally fair to conclude that one team here is not.
And if PWAs from chrome are the problem, then it would also be possible to not allow chrome PWA's but still allow webkit PWA's.
If the browser engine can't be trusted to segregate camera access through a PWA then why is it trusted to segregate it in-app?
But a legislator forced their hand so now they gotta cry about it.
>Browsers also could install web apps on the system without a user’s awareness and consent.
Couldn't this be entirely solved with an OS permission-like prompt "are you sure you want [progressive web app name] added to home screen?"
Why would this be exploited on the relatively small marketshare platform that is iOS, when in all those years this year not been a problem on the dominant platform?
Because it's not a real problem.
This stuff is part of the reason people commit to the Apple ecosystem despite its shortcomings.
While Android dominates globally, iOS has nearly 60% market share in the US and some other countries.
What we are talking about is specifically targeted at the EU where iOS represents about 30% of users, and doesn't apply to the US. So it's unlikely that scammers would just hold off from exploiting Android and wait for the EU to force iOS to allow different browsers, and only then exploit this class of vulnerability.
Android was also infamous for causing users to develop permission-blindness and just accept everything, later replaced by every app havinf an extensive permission list that everyone just shrugs and accepts as normal.
iOS has been doing something very similar and it's arguably worked pretty well.
3 trillion company can implement this without breaking a sweat properly if they cared, what are they trying to say here - 'we are incompetent'? Not buying that for a second, we know they can deliver.
Apple does not.
And if they don't, they have at least a chance of circling back and catching them later.
They want that.
With apps that they cannot review such as PWA apps, they have no such ability.
I have the feeling Apple is betting on Google not caring enough about the PWA platform to try to compete. Maybe they're right, but if they're not, they're only making the browser wars worse for themselves.
I don't think it's about Google, I think they assume consumers won't care, and they're probably right.
Looking at these things as sides is a mistake. Instead of just being tribal, it's better to look positions on their merits.
Because it seems to be that way on MacOS. On Mac, the App Store is absolutely useless and exclusively something people do not want. It does not distribute the software users want, it charges them extra fees, and limits the type of app you distribute.
Judging by every single professional Mac user I've met, circumventing the App Store is a functional necessity for some. Most of them absolutely "put up with" the limitations and issues of MacOS.
> What about the pre-app store world made it the one preferred by consumers in your mind?
The freedom? The cheaper software? The stronger OS security models and lack of social-manipulation-as-a-security-feature?
If the post-App Store world is so great, people will keep living in it even when alternative stores exist. I suspect that most users will not give a rats ass about convenience if there's a 30% cheaper subscription elsewhere.
Bear in mind I'm replying to someone who's saying app stores aren't necessary in general:
> Well shit, what user needs an app store to begin with
Apple could sign software the same way they do on Mac and effectively turn the App Store into an IPA-downloading PWA.
How do you do this when any value a "merit" could have is based in this dichotomy of vendor/user?
You might say that that's not true, and browsers are easy to secure, but that would be arguing the point on its merits. Not on the tribalist lens you're seeing this situation through.
I agree. English is not my main language and maybe I should have used a different word than "side".
Above someone said that this seems to be an OS problem, which should be fixed by Apple. The person I replied to said "Or they could just not."
And that's why I asked why they were siding with Apple here. What's the benefit for users if iOS doesn't work as expected when a different rendering engine is used for a web app? How is this good for EU users? I don't get it.
I wish Apple'd held a hard line on the "no apps that should be a web site" rule(s) for similar reasons. Alas, they did not.
Instead of siding with Apple, why would I side with anonymous and random internet commentators who have never made devices I want to buy?
I’m talking about toys and gadgets. The ability to view memes.
My iPhone connects me to my government, my bank, my school, my family on the other side of the world, my portfolio, and perhaps most importantly; critical safety services (local avalanche forecasts in my case).
You can be damn well sure I'll be passionate about how it's controlled, and what capabilities the manufacturer is derailing in the interest of record profits.
(For clarity - I'm not the person you responded to, but this is HN so I thought I'd chime in on why some people are so passionate about this so called "toy")
The comment you were replying to, correctly, pointed out that there is no benefit to the user to side with Apple's anti-user stance. This story, and comments about the story are having to do with a users right to install a browser of their choice, choose a payment method of their choice, etc - which is collectively under the DMA that the EU passed into law - democratically. Apple has repeatedly tried their best to spin this, but it is easy to see past the spin.
You're free to make up your own mind.
BTW, My morals, despite my personal failings, are superior to Apple's on this particular issue. Its an interlinked economy with interlinked dependencies on various entities that you may or may not agree with. That doesn't mean you're not allowed to protest them. Otherwise nobody can protest climate change if they drive a car - which is ridiculous.
I'm writing this on a Macbook Pro which I really like, but this decision has downsides for me as user and I'm not convinced by Apple's justification.
At the end of the day, Apple has earned my trust to make choices that maybe aren’t the most “open” choices, because usually they end up being the best experience for me as an end consumer.
In this case, iOS isn't capable of handling different rending engines well. So instead of asking them to improve iOS so this isn't a problem (like it isn't on Android and even other iOS apps), you side with their decision of breaking/removing a feature, even though it doesn't benefit you in any way.
I'm sure you can see the problem with this.
And lest I be dismissed as a hater, I currently own five Apple computers, an iPhone I've upgraded every year since they came out, an iPad, a watch, and a virtu^wspatial computing heads^wdevice. But that's because of the transactional value they provide, not because I believe Apple loves me and has my best interests at heart. They love my money and that's where it ends.
I use several PWAs and I will be very disappointed if this is the stick Apple uses to close the window on this short period of time where we had a reasonably interoperable standard for making "apps" using web technologies. I can run Elk in a browser, but it's suboptimal.
From my point of view, I don't benefit if 1) Apple removes this option in my region and 2) there's no good reason for me to be against iOS handling better permissions of web apps and other rendering engines, like it already does for all other apps (and something that Android handles without problems).
How surprising.
This is essentially saying no-one can build a secure browser.
[1] On iOS.
- No App Store review
- Full control of distribution channel
- Instant deployment from CI/CD
- Single codebase
- Easy to source developers, even in-house
- No administrative burden from having to maintain accounts at Apple/Google.
Adding to home screen is important for non-technical end-users to recognize it as an "app" and not a "website".
They simply could ask browser vendor to follow strict rules, that they can check themselves. This is not like they would have to verify dozens of browsers every day. Only a few per months, top.
Translation from Apple talk to real talk: allowing competing browser engines will undermine our grip on the market through lock-in to the engine we fully control. We don't want to lose power. As control freaks, we'll do all we can to sabotage it.
How is this even possible? It's shocking that these APIs even exist for any browser to use.
Apple could add a bunch of new APIs to support this case for third-party browsers. Presumably there's something equivalent that's being done for said web apps currently in Safari. But they're not wrong to say that there's not an existing system in place that said third-party browsers are already written to use. (And, you know, they're clearly not invested in trying to make this law succeed.)
Like I said, Apple could totally make APIs so that Chrome could know it was being launched in a container with data isolation and should behave as a web app. Google could then adopt those APIs, with the alacrity that it's famous for showing with new iOS system APIs. But the behavior Apple is implementing here is probably how any default-browser that hadn't yet opted into those new APIs would have to behave.
(To be clear: I think Apple is being petty here by not having those APIs announced. But "we're going to regress everything to bookmarks" is probably more DMA-compliant than "things are better when you use Safari, and we promise we'll extend that to other browsers someday".)
This strikes me as the way to go, there’s no good reason for anything else to be copied and it reduces the amount of data that integrated privacy-compromising ad and analytics services can readily glean from users.
Other browsers would have to be trusted, Apple doesn’t have a mechanism to ensure that they do what they’re supposed to.
So until they have time to add one (remember they already had to create all the API‘s for third-party browsers to use), they’re not allowed to give Safari preferential treatment. So they had to remove the feature.
https://www.theverge.com/24054329/microsoft-edge-automatic-c...
Ask MS, they already did it.
They say themselves it would be possible to be compliant with the DMA without removing what is obviously competition they don't like. But they try to take the road which - just by chance, obviously, the security is the real reason - helps them to keep more people away from competition. I don't buy it.
This doesn't sound at all the same as allowing other engines for use inside browsers, based on both apples defense and the take-downs on them.
Is there some flaw in iOS that makes it harder to secure than the desktop?
So... yes, there is apparently a lack of security there, but that's because the layer in question was never intended to be anything but proprietary until this ruling.
They built their PWA support in an anticompetitive manner assuming App Store & WebKit would be a monopoly forever, and now as a result the baby is going out with the bathwater.
> They built their PWA support in an anticompetitive manner assuming App Store & WebKit would be a monopoly forever, and now as a result the baby is going out with the bathwater.
They built it in such a way that it was sustainable and sensible for the time it was made (iOS 2.0). That's a really long time ago in the software world. More than a dozen versions of the OS have been built on top of this. Saying "they should have just figured it out back then" is completely ignoring the reality of what was offered by the OS and the mobile space entirely at the time.
Now laws have been passed that say "you must provide alternatives." OK. They can choose to spend an ungodly amount of time refactoring the OS to undo 16 revisions of the OS of assumptions for zero benefit for the company, or they can say "Sorry we can't comply with that for your market."
It sucks. But it's a result of reasonable business decisions and their evolutions from a significantly different era.
> They built it in such a way that it was sustainable and sensible for the time it was made (iOS 2.0).
Support for installing progressive web apps was added in iOS 11 [1], released in 2017. This is decade(s) after Microsoft was dragged to court in the US and EU for similar behavior with Internet Explorer. Of course being the authoritarian company they are, Apple would rather dig their heels until the bitter end instead of just doing the right thing.
> Saying "they should have just figured it out back then" is completely ignoring the reality of what was offered by the OS and the mobile space entirely at the time.
Sorry, but the rest of the mobile space did figure it out at the same time. All of the things being debated in this thread simply just work on any Android phone and Google Chrome or Mozilla Firefox in a secure manner. I'm so tired of this reality distortion field.
[1] https://developer.apple.com/library/archive/releasenotes/Gen...
And it probably took the space a non trivial amount of time to figure it out whilst apple allocated their time on other features.
Now a regulation says that Apple should figure it out and Apple says they'd prefer to continue to allocate their time on other features.
Apple is not government company, they do not make decision on what makes all users happy, regardless of how small the feature they are building is. They make decision based on how much profit they're expected to make. Apple probably calculated the efforts and possible profits on this and profits would probably be negative on both options to either build pwa support on arbitrary browsers vs remove pwa support on all browsers altogether. Removing support was probably the option that showed lower profit loss across the short term.
In the end, I still think it's a bad move, but why should Apple care about what I think?
I don't use pwas, I don't even use apple products.
They are being rightfully forced to open all their gatekeeping features, in this case, they simply chose to remove the feature as a whole instead of opening it up to everyone. They will take a loss here, but it might be a smaller loss when compared with the effort that they'd have to do if they were to open the feature in the limited time the EU has given them.
Maybe in the future they'll do it, but not now.
I don't see why everyone is getting so worked up about this, apple is in it for the profit, even if it mean losing some in the short term. Why is this so surprising?
I cannot see this as anticompetitive. If you want open, you have that choice in Android.
Also, Safari is a non-Chromium-based (though still related) browser which developers are forced to support because it's the only thing allowed on iPhones. Most users aren't going to install Firefox on their iPhone, they're going to install Chrome, which is just going to make Chromium's market dominance worse.
If Apple doesn’t support PWAs then PWAs stop being a viable method of app deployment - killing the platform outright. That’s anticompetitive.
"Hey PWA, don't let the door hit you on the backside, on your way out".
The browser is just about the most vulnerable attack surface on any computer. Using it as a general-purpose application host is nuts, IMHO.
I know it's used as an intensifier, but this feels like a particularly bad place to use "literally" that way.
> They acknowledge that 1) Safari already has all the integrations required to support PWA securely
Not really sure how to respond to this. An airliner already has all the controls required for being piloted. Why am I not allowed to pilot my next commercial flight?
But my more serious point:
> 2) they can't be bothered to provide the same API's for third party browsers because it's not "practical".
Why are you glossing over "practical" there and putting it in sarcastic quotes?
This sounds like a huge change in the security model given how tightly Safari is integrated with the rest of iOS. Heavily restricting permissions and sometimes functionality to prevent security threats is very consistent with what I've seen from Apple in the past (and is one of the reasons I prefer them).
Even if they intended to open this stuff up, I can't imagine this is a change which wouldn't require massive changes to iOS and a long review and testing process.
> They built their PWA support in an anticompetitive manner assuming App Store & WebKit would be a monopoly forever, and now as a result the baby is going out with the bathwater.
They built their PWA support for the architecture they've had since the iPhone's release. Why should they have wasted time building affordances for a world in which they were forced to support other browsers?
What kind of ridiculous "argument" is this? Am I putting hundreds of other people in risk by installing Firefox on my iPhone? The fact remains that the EU in fact does intend to put you in front the airliner's controls. You can of course choose to turn on autopilot and keep using Safari.
> Why should they have wasted time building affordances for a world in which they were forced to support other browsers?
Guess what, "tight integration" of Internet Explorer into Windows for whatever technical reasons was not a favorable argument for Microsoft in front of the European Commission either. Lack of foresight to design open systems is not an excuse in front of the law.
Certainly it’s an extreme example, but yes, giving people the ability to install other browsers and app stores is increasing their risk. This ruling makes it possible for some companies to decide to only allow their app to be installed through an alternate app store, which won’t necessarily restrict malicious code in the same way.
But it is increasing _their_ risk. That's the massive difference from your example. Installing other browsers and app stores is increasing _your_ risk
Flying a plane badly risks the lives of your passengers, the lives of people on other planes, and people in the nearby area.
Doing whatever you want with your phone doesn't risk other people's phones.
I asked because the thing this company said in this particular instance aligned with what I’d heard from other (independent) parties and I wanted to know why this person seemed so sure about that being wrong.
I'm a little confused. So that long list of requirements is useless for PWAs?
Some people will actually believe this. I'm utterly disgusted by Apple and their arrogance regarding the DMA, and the way they've managed all of this. My perception of them has completely changed. However, they seem very obedient when China asks them to censor apps or, for example, limit AirDrop when there's a protest going on.
Claiming that it doesn't exist is misinformation
In context 99% of the users I meet don't even know what USB-C is.
It's off balance, and it shows now that the tech has to be removed since it wasn't actually at parity despite it being an argument for it unfortunately.
The worst part? This has been the case for 15 years. It's not like there wasn't enough time to fix it. That's plenty of time to hire and develop solutions, yet now look at the reasons for it being taken away.
I think a lot of the time people give an excuse, or perhaps even a justification to themselves, when they really just want the excitement of new phone. I often catch myself inventing reasons why I should replace my perfectly fine phone.
Literally many people do not care enough to understand it. It's just a modern necessity, a tool.
USB-c PD is such a dumpster fire of a standard. Even with supposedly high end cables like Anker you often can't charge a Macbook Pro faster than it can drain it's own battery under load. We can't expect normal people to understand why there are a dozen different cable types that all have the same tip but charge at vastly different rates...
Every conforming cable supports 3 amps and 20 volts.
If you think something's incorrect with that, be specific. But the spec is pretty clear.
The exact details of the faster cables are murky because there's old and new versions of that section of the spec, but very few devices use enough power to care about that.
The problem is all the non-conforming cables that people have, that look exactly the same as conforming cables.
Is the part of the GP comment I was responding to. The connectors form part of the standard. There’s no way to identify a standards-conforming cable from a non-standards-conforming cable by looking at it. They all look the same.
You plug in a USB-C cable, you might get a quick charge. You might not. Unless you have a USB-C power meter, you have no way to tell unless you know how quickly your device should charge in 5, 10 or 15 minutes, and hang around to wait and see if it does or not.
I think there’s a meaningful difference there!
Really, we're talking about physically broken cables here. As long as there's electrical connection, there's no other way for a cable to not work at 3A/60W with USB PD. Its cable requirements only start when you want to go higher than that - and 60W is plenty of power already.
If something breaks that, it doesn't make sense to blame USB. Whatever the manufacturer was doing, it was such a mess that it would fail with any other standard.
Supporting data and PD is just three tiny wires, it's not hard.
Higher power levels beyond 60W are optional. The newest PD spec goes up to 240W (5A @ 48V).
Anyway the GP post is referring to a USB A to C cable and an old-fashioned USB A wall charger, many of which barely output a single watt. My family members have had similar problems due to similar confusion.
If it doesn't have the wires inside, you've been scammed into buying a piece of junk that merely looks like a USB cable.
When using a USB-A charger, you're guaranteed* at least 2.5W, and the charging standard (BC 1.2) goes up to 7.5W (though usually you can go higher with proprietary protocols, such as QC, or even PD 1.0, although it's very rare for something to support PD 1.0 and pretty common to support QC or Apple signaling). Sure, you won't be able to charge a laptop from a USB-A port, but it's not a hard thing to grasp.
I don't think you know what you're talking about.
* You could probably find some chargers that do less than 500mA, but you'd have to search among 20 years old ones at this point and they wouldn't really work with anything modern anyway, PD or not. The hard requirement is that a port has to provide at least 100mA, but that's only relevant to data ports that can do USB enumeration - for charging-only ports, everything assumes at least 500mA, and it would be really hard to find something with less than 1A or even 1.5A (7.5W) these days. Of course, if you try hard you can find any kind of weird stuff out there - I've got a water fountain for cats with power adapter that has a USB-A port providing 9V, so connecting anything else to it may make it release its magic smoke - but that's hardly a problem with USB itself.
Having power wires isn't optional. The ohm limits aren't optional. And they can handle 20 volts by virtue of using normal insulation.
The 60 watt limit is for completely passive cables that don't implement anything PD-specific.
Buy stuff that's up to spec, and it'll be fine.
The only case where you may need a different (non-passive, "e-marked") cable is when going above 60W (3A).
For one thing, if Apple is complying with the EU’s alternative App Store and browser engine mandate, they’re even less useful than before. Why do I as a user want a PWA when I could have a native app?
On iOS you need to use the Share > Add to Home Screen which normies have no clue about. You’ll find out if the site supports PWA features AFTER you add it to your Home Screen. This of course is done entirely on purpose to make them harder to find and less appealing than the revenue generating App Store.
For me, I use iPhone entirely because pixel doesn’t support cardav and caldav out of the box…if I can’t use PWA’s on my phone then I’m going back to android cause I can solve the email problem easier than I can solve the productivity tools not being available via PWA’s.
That to me is a bit of an indicator that Apple just doesn’t believe in the merits of the technology. I think they might be asking the same question in asking: what problem is this solving?
Every platform with a web browser has a better way to run applications, which is to just run an application. A web site that is masquerading as an installed application is basically just a less capable application.
As a side note, I’m also not really sure how an app store can be considered scammier than the entire web. The web is a Wild West with far fewer “rules” than the Play Store.
We run 3 SaaS apps. One is strictly native, and the other two are strictly web. Writing for 4 platforms on the native app is an extremely expensive exercise and then we are also subject to the insanity that is the App Store. Long story here, everything from App Store review times on mission critical software to the fact that their billing mechanism simply doesn’t work for B2B SaaS…and by the way, we get zero traffic from the App Store as that’s simply not where our customers are looking for the solution we provide. Fortunately, bulk of our customers start on desktop where we self distribute (code signing on windows and notarization on mac) with ev ssl on marketing sites. Why is the App Store scammy over the open web…search for any number of popular apps and look at how many have been cloned. Sure, you can do this on the web with paid ads and enough SEO effort but it’s much harder.
To this day, Apple continue to allow keyword stuffing, advertising on trademarked names, and blatant copyright infringement in app descriptions and even I (fairly tech savvy) accidentally purchased a clone of poly bridge for my kid cause they’ll list the clone above the real one on an exact term search. What was apples response when I said I purchased the wrong app? Tough cookies!
This is the same reason I hate shopping on Amazon. I simply prefer to have a direct relationship with the companies I buy things from, and from what I can tell, our customers prefer have a direct relationship with us.
But back to why PWA’s are awesome…simply put, iteration time. We can publish dozens of improvements every day and roll back instantly when an issue arises. We simply can’t do that with native as long as the Apple / Google act as a gate keepers. When we allow proper sideloading without the scare tactics and dirty tricks, we’ll take the time to build native again.
You've described some advantages to you as a developer. For the average user, apps that change all the time and effectively make them a tester aren't such a no brainer!
Re benefit for who. We will invest our time where it makes the most sense. If you’re familiar with platform risk, you’ll understand that we’re not exactly eager for our existence to be subject to the whims of Apple and Google.
Google in theory has a financial motivation to make their competitor Apple look like the bad actor.
For one, the actual PWA packaging process gets shunted off to a Google server; I think you can make a "thin client" APK from a manifest using a tool they wrote some time ago[0] (Twitter Lite is one of these), but I've not really looked into it. It's not quite the extension to Chrome you'd really want it to be; if you use a non-Chrome browser on Android, it means you can't really ditch the Chrome dependency if you want to use a PWA. (Further not really helped by the fact that Google is basically the only PWA implementer on Android, since Firefox does not consider PWAs a priority whatsoever.) Similarly, Google's servers need to be able to read out the manifest declaration, which makes them unfeasible for intranet software unless you want to punch a temporary hole and expose it to the internet for a bit.
The other kinda annoying thing Google does is really aggressive degradation between PWA and homescreen shortcut. If the manifest isn't entirely up to snuff in terms of what's listed, there's no attempt at trying to resolve the issue, it just instantly degrades to a homescreen shortcut. A basic example of this is the requirement to use a service worker (even if the service workers entire job is to do nothing); it's not really stated in the manifest spec that it's required, but if you don't have one, the PWA straight up refuses to install as a PWA.
Google's strength with the play store really mostly comes from their bundling advantage; Play Services and the attached Store and Google Apps are required for OEMs to add to their devices (might change with the DMA?). That's the kinda odd reality that makes Apples desire for control seem so extreme - we know what an open platform looks like on Android. It works pretty well for the most part and the incumbents advantage for a store is large enough that almost every app developer submits to the Play Store regardless.
[0]: It's called Bubblewrap - https://github.com/GoogleChromeLabs/bubblewrap
Would be interesting to see how the play store changes in the event of Android honoring code signing for side loading like windows. Eg..no scare screen on side loaded apk’s as long as they’re code signed.
I suspect the App Store would live on as a consumer focused App Store and the enterprise apps would direct distribute which makes sense anyhow cause IAP does t understand account based pricing.
The only thing actually needed for feature parity with the Play Store is mostly just that F-Droid can't auto-update; the Play Store can skip the update/install prompt screen, F-Droid can't. They added install origins to APK files last year iirc, so there's a likely chance they're allowing it though.
Does it live up to that? YMMV. It's probably fine for very simple apps, probably comes apart at the seams for anything trying to look modern or have fancier functionality.
The only two things I've ever missed from native functionality are:
- background geolocation
- push notifications on ios
The second one was fixed recently.
In contrast, from what I've seen 90+ percent of apps I see in the app stores would be better as a web page / PWA.
I’d take a decent wager that most of your users are most familiar with apps and would prefer installing full apps.
Doesn’t matter that most apps would be better suited to being a web page or PWA if that’s not where the users are. That’s kind of like saying that PCs are better at gaming than consoles. Yes, that’s true, but that’s not where the majority of users are.
To use the gaming console example, it's not unlike using an emulator to launch your game on PC (if you could somehow monetize an emulated rom). It's not the ideal experience, but it requires very little extra work.
Well, they "live" on their phone. I would just put a button on my website to install the app, users would find that easily.
One of the small conveniences is indeed that you didn't need to develop the same thing twice, which made the barrier to entry much lower. The functionality that you were exposing to users did not need to pass a review at one of two US tech giant companies, which could reject publishing it for any or no sensible reason at all. You were not forced to pay 30% of your revenue to the gatekeepers of the platform. You were not banned to invite users to buy your product in any way that works for them, even if it meant sending you checks over carrier pigeons. There was no _chokepoints_ that a single company could squeeze to further its own interests (after the collapse of IE).
Google Chrome would like a word...
In some regards yes. In practical regards they're a threat to app store margins (on all app stores, not just Apple), so there's no incentive to truly support them other than developers being loud about it.
>I don’t even know where to find one.
Because Apple has crippled the ability for you to use them, so developers can't really spend time working on them. Chicken and egg problem.
>if Apple is complying
They're not really, they're twisting and turning as much as possible to look like complying but make the desired outcomes even more difficult to achieve.
If a regulator enforces a ban on dihydrogen monoxide in a misguided attempt to reduce global warming, should companies comply with the regulation or the presumed intent?
The EU is demonstrating the folly of legislation tech product design at this level of detail.
Heh! Also known as hydroxyl acid. It’s the major component of acid rain.
;)
I agree that's not as good as a native install prompt but I don't think it's a strange incantation/utterly unintuitive. I know that icon originally meant 'share' but these days it means a wider range of things - basically "take this thing somewhere else".
It’s also a very inconsistent experience: some sites have set themselves up as fully featured PWAs, others have made no efforts at all. Both get the same button.
OH (frequently):
- hey I need to to up, do you have a phone charger?
- yup, which kind?
- not "an Apple"
- oh, so USB?
- yeah the "standard" one, not the "new usb"
That said, I'm surprised many do know about the literal "usb-c" term. Micro USB A though flies over their head, it's "small usb" or "standard usb" every time.
Of note: EU here, and while they by and large don't know about the EU standardising stuff they did notice the effect. I've seen a few refer to USB-C as "universal one" (largely coz it works the same for both phones and laptops)
The more important context is the legal one, not what laypeople think.
Apple is presenting PWAs as viable alternatives to the app store in a legal context: https://www.accc.gov.au/system/files/Apple%20Pty%20Limited%2...
In a similar vein, a startup will be very happy to talk about how valuable it is, except when it comes to talking to tax authorities, whereupon suddenly their shares are borderline worthless.
The kind of deep user information you can gather by installing a full blown app compared to a more sandboxed web app is worth way more than the 30% royalty cut.
>The kind of deep user information you can gather by installing a full blown app compared to a more sandboxed web app is worth way more than the 30% royalty cut.
What kind of information is that?
That's just a few of many advantages.
100+ times faster to start using: are they? I can type in the name of an app into my OS-wide search and tap “get” and that’s it. Swipe down, type “candy crush,” tap “get.”
Easier to market? What’s easier than saying “download the [name] app?” Arguably more complicated to say “go to example.com”
Much cheaper services? What is cheaper than TikTok or WhatsApp? Those companies make more money on the apps because they have more user data collection. Companies like Netflix go around the App Store cut entirely.
With installed apps the desires of the corporations and users pretty much align.
It's functionality to add an arbitrary webpage. What exactly are you expecting them to "provide"?
I don’t know if this ironic given that apple originally didn’t want to support native apps and gave in due to developer demand.
Apple both did and didn’t want web apps
This is a trite argument that hasn’t been true ever since Jen Simmons joined Apple in 2020 and changed the course of Safari significantly to the point that PWAs not only are viable, they have been given feature parity with native apps on many fronts.
Simultaneously, the argument completely bypasses the fact that install rates of PWAs are abysmal on any platform. Whether it be iOS, Android or Windows.
Contrary to what PWA developers, industry organizations and other stakeholders proselytize, PWAs aren’t the second coming and the next best thing since sliced bread. At least not when it comes to install rates.
Edit:
Don’t get me wrong, I’m sure they’re great as “websites”.
Lord knows people who sell PWAs[0] love to brag about bounce rates and conversion rates and what not. But there’s a reason why you can find barely anything about install rates other than some vague statistics about individual unnamed PWAs[1] or PWA sellers[2] talking about obviously bogus 10x and 3-5x install rates, and it’s not because the PWA crowd is too shy to brag.
1: https://developer.chrome.com/blog/pwa-install-features
2: https://mobsted.com/pwa_vs_native_mobile_apps_install_rates_...
What people want isn't PWAs, they just want the kind of capabilities that computers have had for decades, including many of Apple's current computers for sale today. To be able to install an application and run it.
That’s not true, nor what I posited. PWAs have almost all the native features, if not all, depending on the platform. Plenty of “pro-PWA” people go out of their way to demonstrate this[0].
I’m talking about install rates and usage by end users in a way similar to using a native app.
Whether you agree on parity or not, you seem to concede that PWAs aren’t wildly adopted the way native apps are.
As such, it makes sense that Apple wouldn’t want to waste engineering resources on it by rewriting the underlying architecture, which is the topic at hand.
That in and of itself ends the debate.
You then go on, OT, about whether Apple should or shouldn’t position websites and PWAs as legitimate alternatives.
Saying:
> but Apple's platforms are the only ones where it is being positioned as a legitimate alternative
Specifically, Apple states[1]:
> If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too.
An alternative isn’t, as you seem to imply, an identical option; instead, it is simply understood to mean a different choice, usually a choice different from what is usual.
One might say, "In the absence of a better alternative, we’ll have to proceed with our original plan.” This use in and of itself implies that one option is better than another, thus not identical.
Whether something is “legitimate” or, more specifically, a “legitimate alternative” entirely depends on the person making the consideration and the value judgment they make based on their needs and wants.
I might consider soda a “legitimate alternative” to coffee because I’m just looking for a beverage, whereas a different person might not deem it a legitimate alternative. After all, they are solely interested in a warm beverage.
With that in mind, I consider web pages, particularly PWAs, a legitimate alternative to native apps because most native functions are available to PWAs on iOS. You might not because your need might be one of the few things PWAs can’t provide.
That doesn’t make it a bad-faith argument on Apple’s part; they never claimed that PWAs are an identical option to native apps via their App Store. They offered up an alternative that can provide some, if not most, of what a native app can provide.
You continue with your OT by presenting a false equivalence
> Android has "sideloading", Windows has REGULAR loading.
It’s a false equivalence because neither Google nor OEMs present sideloading as a legitimate alternative; it simply exists, but it’s not promoted as an alternative option.
Google specifically likes to write copious amounts of words in blog posts[1] and whatnot, talking about how great PWAs are while wearing their Chrome hat. Meanwhile, the PWA experience on Android is marginally better than that on iOS, provided you use Google’s browser. Where is your indignation for that? They’re promoting PWAs harder than Apple will ever do.
For that matter, Microsoft also doesn’t call “regular loading” a legitimate alternative, so again, your equivalence makes no sense.
> It doesn't matter who joined Apple when and did what
Of course it does; if you don’t go OT, that is. Whether Safari is or isn’t suitable for PWAs is essential to assess if PWAs are used in meaningful quantities.
If someone posits that Safari doesn’t properly support PWAs when that isn’t true, like GP did, then it’s important to point that out and provide context on when that changed.
It doesn’t matter to you because you’re having an entirely separate discussion.
> PWAs on iPhone are not like native apps
Yes, they are.
As stated above, they’re not identical, but they are similar to, or if you prefer, “like” native apps.
> it's not even really close
This is a value judgment because it requires that you and I agree on the definition of “close.” I argue that they’re pretty close because they can do about 90% of what native apps can do.
> It's good that this pathetic line of argument wasn't much of a deterrence for the EU.
Let’s keep it classy and within HN guidelines.
> What people want isn't PWAs
Hence, the low install rate of PWAs and why it’s not weird that Apple didn’t decide to spend engineering resources on rewriting the underlying architecture for PWA installs.
Again, that, in and of itself, ends the debate.
> they just want the kind of capabilities that computers have had for decades, including many of Apple's current computers for sale today. To be able to install an application and run it.
I’m not sure what you base this on.
From here, it looks like you’re projecting your own wants onto the average iPhone user base at large. Do you have anything that expands on how many iPhone users share your vision?
The commercial success of iPhones suggests that not many seem to care for this.
I suppose alternatively, you could argue that the fact that Android dominates globally indicates there is a demand for this in the smartphone market[2]. Still, the obvious question then becomes why those iPhone users wouldn’t just join in Android’s dominance and switch over, particularly those who feel so strongly about this that they’d spend their time online lamenting its absence.
1: https://developer.apple.com/app-store/review/guidelines/#int...
2: This is simplified, of course; one feature wouldn’t be the sole driver of Android’s dominance
the name "install" is bad and the wording is NOT a web standard, NOTHING is installed
the question is web capabilities
one core capability is caching and offline via service workers
no need for "install" for this
"installing" a web app does not even need anything anymore, not even offline or service workers... it is ONLY switch to standalone and get a launch button or be integrated into app launchers on OS
behind "install" is a bad and immature web app manifest api, it is a draft... the wording install must go
it is one of MANY possible web capabilities for a web domain to be able run standalone and get a button
apple cannot ban this since a shortcut to chrome cannot be deemed unsafe, where then CHROME decides to run standalone or not
the real problem is NOT that safari kills standalone
they try to kill a lot of web capability, like service workers, and NOT JUST FOR SAFARI
I mean this will not stand, you CAN stay apple-level-safe (whether it is more or less than other platforms) by CHOOSING safari
it is an obvious CHOICE to be granted to trust google, mozilla or microsoft and their web security model to stay safe with THEM on the web
no argument why this should not be allowed if other native apps are allowed
and come on, even mac os is safe with service workers in chromium
Apple’s decision is going to kill businesses and break apps used by hundreds of thousands of people in Europe, many of whom are healthcare workers delivering patient care.
Couldn’t they allow you open PWAs in Safari, or fall back to opening a URL in another browser?
Is there some part of the DMA which demands full feature parity?
Very likely the EU wouldn't like them prioritizing their own browser for a feature
As the governments demand more and more, I predict we will see several monkey paw moments.
Does the rule not allow that? If so... yeah, as a user deep in their ecosystem and once-developer for the platform, hard agree on this. Whatever their other motivations (and Apple are masters at arranging things so that their interests happen to coincide with legitimate concerns about UX) the user-facing issues expressed are worth worrying about.
1. WebKit has access to special OS-level APIs that allow it to install and power web apps. 2. The DMA requires support for alternative browser engines with the same abilities as WebKit. 3. It is reasonable to assume this requirement extends to PWAs. 4. By taking away WebKit's ability to power PWAs, all browser engines are now on a level playing field.
_Could_ they have done it differently? Maybe, maybe not: software development always takes longer than you think, and throwing more engineers at a problem doesn't always make it go faster. Do I think they saw another chance to be petulant and took it? Yes.
So yeah, I'm disappointed, but no more here than with the rest of Apple's DMA response.
They're likely not lying when they say that it's more difficult to maintain their security standards while at the same time allowing any browser engine to run PWAs. But this is a problem they absolutely could solve, and a company with Apple's size and skill absolutely has the resources to make this work. But they've chosen not to.
Another option would be to actually engage with EU regulators on the issue, and see if they could carve out an exception -- temporary or otherwise -- to allow them to require PWAs to run under their existing WebKit-based framework, regardless of the default browser. But they've again chosen not to do that.
PWA adoption is likely as low as Apple claims. I think they're toeing a line here: because Home Screen Apps are a bit of a niche feature, they can break it without pissing off too many users, but also give a subtle middle finger to the EU. "Poor Apple users, Apple just has to disable a feature some people like because of the evil, overreaching EU and its burdensome DMA!"
This is a shame in that I personally think we all should be relying less on mostly-closed-source, proprietary apps for everything. While the web platform is a bit of a mess, it actually does (or could) offer the same functionality that native apps do, especially if Apple and Google had worked on that sort of thing over the past 15+ years rather than pushing native apps so hard. We'd be in a much better place if that were the case: consider the savings in time and money if every company out there could just write a single PWA and not have to build two completely separate apps for iOS and Android. (Yes, I know there'd be some extra people dedicated to fixing issues caused minor but significant-enough differences between the platforms, but it'd still be a ton less work than two apps for two different platforms.)
Also consider how much easier it would be for other smartphone platforms to break into the space, if all existing apps (as PWAs in my imaginary smartphone-utopia) would run on their platforms without much work. A big reason I will likely never adopt an alternative smartphone platform is because none of the apps I rely on day-to-day exist on them. Even though I'd absolutely love to ditch Android, but don't consider iOS any more palatable.
Anyway, that ship sailed a long time ago. I'm still bitter about it, though.
Ultimately this won't matter much. The number of people using PWAs on iOS is probably a rounding error. Restrict that to only people in the EU and it's even smaller. But Apple still gets in a jab at the EU over this, and most affected users will likely side with Apple on this one.
I beg people making these claims to look outside their web bubble for at least a nanosecond.
> especially if Apple and Google had worked on that sort of thing over the past 15+ years rather than pushing native apps so hard.
Google couldn't care less about "as good as native". If they did, this project wouldn't have been started by devs from Microsoft (of all companies) in 2020: https://open-ui.org
> consider the savings in time and money if every company out there could just write a single PWA and not have to build two completely separate apps for iOS and Android.
Yes, you should be building native apps for each platform unless your "app" is a barely functioning text-only page.
Does this "minimal impact to their functionality" mean, the app will loose its local data after 7 days of not using the app, like it is for normal websites? That is a pretty heavy impact.
Sounds like Apple is saying webkit is insecure and to not use safari or iOS webviews because if they can't be trusted to run a PWA then they can't be trusted for anything ;3
1. The DMA is striking at the heart of their revenue model by targeting the app store. Tim Cook testified before Congress and said that Apple would be "giving up our total return" on their intellectual property if they did not monetize the app store aggressively. So my read is that this move is intended to prevent a shift to PWAs as a way to get around the new policies.
2. Legislation like the DMA, if successful, could spread to other countries, much in the same way the link tax spread from Australia to Canada. I think Apple has an explicit goal to make this legislation as painful as possible, for both the legislators and the citizens, so that other countries do not attempt to pass similar laws.
There was a time between 2007 and 2011 where I bought Apple computers and was a big fan. These days, despite the very cool new processors Apple has released, it's very hard for me to see them as anything other than antagonistic. What a fall from grace.
Clearly, they're just making a point here, hurting developers and users just to spite a regulator.
What they are signalling to me as a developer is that mobile devices are just not a reliable platform. Better do as much as possible on the server.
However, I'm on their side in this case. I run a business. If having a feature comply with some regulation meant implementing a whole infrastructure I don't have to serve a minority of customers, I would also abandon the feature.
They could have implemented this feature securely, but they chose to use the opportunity to make a point instead.
All other OSes support web app installation from any browser, including macOS. This is a lot more secure than installing any native app.
This is just Apple spreading FUD as an excuse to keep preventing web apps from competing with native apps.
That's always how they spin their FUD. They already have an app sandbox in place for all fo their apps. Sideloaded, PWA, or not.
Evil does indeed lead to real security and privacy concerns.
The "community note" of HN.
In a previous comment [1], I considered abandoning Apple. With this official statement, I'll actually switch to Android. I'll welcome the F-Droid store very much.
Apple, I've been your customer since 2006. I started with the iPod. During this time I had a significant fraction of your lineup. I'm not affected by your changes but I'm using some PWAs. With this erratic behavior, I'm afraid you kill features that I'm using.
Apple cannot simply invoke DMA (50) as a free pass. For its arguments to align with the intent of the legislation, here's a roadmap of what they need to do to justify their security-based restrictions on iOS:
Apple must be transparent about the exact security issues posed by alternative browser engines with concrete instances (not merely speculative risks). They need to prove that these are unique to iOS, given the successful use of unrestricted browser engines on macOS (and every other OS).
Before opting for the extreme step of removing functionality, Apple needs to offer documentation of all the methods for managing and mitigating specific threats that were considered and subsequently ruled out as infeasible (sandboxing, enhanced APIs, etc.). This emphasizes that their actions are indeed the last resort and not merely a way to suppress competition.
The company needs to demonstrate how they would proactively work with browser engine developers to establish strong security controls and threat monitoring on par with or exceeding their current practices for native-only experiences. This shifts the focus to building a safe environment rather than merely limiting the scope of capabilities.
Apple must guarantee that if and when these security challenges are met, it will progressively expand support for unrestricted use of web standards for third-party browser engines. This creates the long-term perspective the DMA is designed to protect and gives confidence to developers investing in advanced web app solutions.
Without taking action in these key areas, Apple's reliance on this DMA portion won't hold up to regulatory scrutiny. They cannot cite generic security dangers then fall back on "practicality" arguments without robust, evidence-backed reasoning.
== Begin quote ==
The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.
Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA’s requirements, we had to remove the Home Screen web apps feature in the EU.
EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.
== End quote ==
Source: https://developer.apple.com/support/dma-and-apps-in-the-eu/#...