[HN Gopher] Apple reverses course on death of Progressive Web Ap...
___________________________________________________________________
Apple reverses course on death of Progressive Web Apps in EU
Author : astlouis44
Score : 735 points
Date : 2024-03-01 16:48 UTC (1 days ago)
(HTM) web link (appleinsider.com)
(TXT) w3m dump (appleinsider.com)
| brycewray wrote:
| > For support, the Progressive Web Apps will still need to be
| built on WebKit, with all that entails.
|
| Here we go...
| jagged-chisel wrote:
| 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.
| jansan wrote:
| What does that even mean? Isn't a PWA just a webpage with some
| Javascript? How can that be built on WebKit only?
| the_mungler wrote:
| 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.
| jansan wrote:
| Ok, thanks. But aren't all browsers webkit based on iOS
| anyway? Is this about other browsers or also about Chrome
| on MacOS?
| the_mungler wrote:
| 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.
| elevatedastalt wrote:
| 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.
| dagmx wrote:
| 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
| RicoElectrico wrote:
| Steve Jobs was legendarily spiteful and petty. They just
| carry over the tradition.
| arccy wrote:
| 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
| dmitrygr wrote:
| 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.
| dwaite wrote:
| 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.
| elevatedastalt wrote:
| 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.
| dagmx wrote:
| 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?
| latexr wrote:
| > 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.
| smoldesu wrote:
| 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.
| lolinder wrote:
| 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.
| elevatedastalt wrote:
| That's a good point
| masklinn wrote:
| > 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.
| TheGlav wrote:
| > So easily reversed
|
| Yeah. It is easy to reverse committing an "if" statement.
| ankit219 wrote:
| 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.
| smoldesu wrote:
| > 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.
| bevekspldnw wrote:
| Exactly, the Safari team has been openly hostile to PWA for
| a decade.
| bevekspldnw wrote:
| 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.
| dwaite wrote:
| MacOS and iOS have different security architectures and
| different UX.
| sircastor wrote:
| 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.
| fsflover wrote:
| So why can't I benefit from a strong, secure
| virtualization on my phone, like I do with Qubes OS?
| fsflover wrote:
| Why downvotes?
| bevekspldnw wrote:
| 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.
| whywhywhywhy wrote:
| Let's stop pretending any of it makes sense. Why are Mac
| app devs not charged the "Technology Fee".
| latexr wrote:
| 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.
| Twisell wrote:
| 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.
| bevekspldnw wrote:
| It's NextSTEP all the way down
| graftak wrote:
| MacBook has 100wh battery, iPhone has 12wh. Chrome is
| notoriously inefficient, easy 2x more battery drain over
| Safari.
| mpweiher wrote:
| Running an inefficient app is the user's choice, not
| Apple's.
| Terretta wrote:
| 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.
| seszett wrote:
| > _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.
| bevekspldnw wrote:
| 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.
| smoldesu wrote:
| > 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.
| Terretta wrote:
| > _Nobody cares that MacOS renders half its content using
| WebKit on Mac. Same goes for iOS - people do care that
| they can 't use a PWA in their browser of choice._
|
| What does it mean to "use a PWA _in their browser_ "?
| That's the opposite of what the PWA experience is
| supposed to be. You're not supposed to be aware you're in
| a browser -- and "people" defined as normals, not HN
| users, do are not.
|
| The "reasonability" of my view about what consumers care
| about is informed by building both enterprise and mass
| market web, and later app, products since the 90s,
| helping countless clients study their users' actual
| preferences in depth.
|
| Our, and well known, studies show the "man on the street"
| has zero comprehension of what a browser engine is much
| less how a PWA or even Electron works. In general, their
| priority is everything just working and tech being out of
| their way.
|
| HN is among the least representative forums for
| recognizing "normal" user interests I've seen, almost to
| the point of parody.
|
| > _Get the strawmen out of here_
|
| Avast and Google debacles are first party software
| provider exploitations of user trust, not targeted
| surveillance or dragnet by a government. Lockdown mode
| shows the length to which Apple takes this class of
| problem seriously as well.
| Terretta wrote:
| On MacOS, there are sandboxed apps, and not-sandboxed apps.
|
| iOS never had a not-sandboxed option.
| seszett wrote:
| 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.
| mort96 wrote:
| 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".
| freedomben wrote:
| 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.
| treffer wrote:
| 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.
| bevekspldnw wrote:
| 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.
| xyst wrote:
| 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.
| bee_rider wrote:
| 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.
| Apreche wrote:
| Apple: You can have it our way, or you can have it our way.
| smoldesu wrote:
| I hope the commissioners write Apple another scary letter.
| turquoisevar wrote:
| Who do you think gave their blessing for PWAs to run on
| WebKit only?
|
| https://9to5mac.com/2024/02/26/apple-blocking-web-apps/
| smoldesu wrote:
| Beats me, it's their funeral.
| albert180 wrote:
| 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
| granzymes wrote:
| > 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.
| smoldesu wrote:
| 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.
| Zak wrote:
| 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.
| smoldesu wrote:
| 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.
| Zak wrote:
| I'm surprised the EU appears to be letting them get away
| with charging a fee for apps installed outside the app
| store.
| disgruntledphd2 wrote:
| They haven't hit the deadline yet, lobby your national
| and EU representatives if you want rid of this.
| threeseed wrote:
| 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.
| Zak wrote:
| 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).
| threeseed wrote:
| CLI apps are not supported on iOS.
|
| So at some point you have to interact with Apple SDKs.
| Zak wrote:
| 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.
| justinclift wrote:
| 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.
| threeseed wrote:
| Non-profit organisations are exempt from the core
| technology fee.
| justinclift wrote:
| Cool, that _might_ make it workable then. :)
| kmeisthax wrote:
| 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.
| albert180 wrote:
| 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
| roamerz wrote:
| >The fear of low-profitability is what drives that
| behavior
|
| Are you sure about that? Seems like a pretty bold
| statement where you would have to have some kind of
| inside information.
|
| I don't have anything to substantiate this but I would
| like to believe that Apple still has the best interest of
| it's customers and security in mind when fighting these
| kinds of legislation. I switched from Android to Apple
| BECAUSE of those restrictions and the improved security
| the walled garden model provides. The other reason was
| the middle finger Apple gave to the cell providers about
| applying firmware updates to their phones. When I was
| using Android it was maddening to wait months for an
| update to be 'approved' and able to install. That led me
| to rooting and installing firmware that was outside of
| the manufactures control and who knows what might have
| been in that.
|
| So for me everything that Apple does to keep a walled
| garden is what actually keeps me as a customer and helps
| their bottom line.
| Zak wrote:
| 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.
| albert180 wrote:
| 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?
| smoldesu wrote:
| > Are you sure about that?
|
| Certain as I can be, without having seen the cards. Apple
| is a company about margins; you see it in their hardware
| profitability, but also in Tim Cook's service initiative.
| They fought Dutch regulators over this for months
| preceding the regulation, and it's not a stretch to say
| the DMA and DSA is a direct legislative response to
| Apple's wanton behavior.
|
| Apple can move literal mountains, when it aligns with
| their incentive of increasing profit margins. Anything
| that falls outside that purview ends up sidelined or
| worse-yet, lobbied against.
|
| > So for me everything that Apple does to keep a walled
| garden is what actually keeps me as a customer and helps
| their bottom line.
|
| That's great, and Apple has every right to provide you a
| differentiated experience. I've been a historical Apple
| customer, and I still keep a Magic Trackpad around
| because it's mostly quite good.
|
| But you and I aren't entitled to a sustained monopoly
| because it benefits us. Happy IE users or Bell Telephone
| customers aren't an argument against antitrust action,
| and it's ultimately entirely tangential to how legal they
| are.
|
| Consider how Apple behaves in hardware, sponsoring
| dubious Chinese labor to make shareholders happy. They
| set industry-leading profit margins by sparing no expense
| in their exploitation of labor and parts manufacturing.
| Is it legal? They say so. But of course Apple would, and
| they have no incentive to ever stop the squeeze if
| shareholders cheer them on. They will behave _just as
| insidiously_ with software, and if you do not treat their
| every action with that scrutiny then you 'll pave the
| road to hell with good intentions.
|
| I _want_ businesses to be good people. I want God to run
| a killer froyo stand. But men are fickle, and Apple has
| been a swindling bastard of a company ever since Jobs
| cheated Woz out of $4,500 over an Atari contract.
| roamerz wrote:
| > But you and I aren't entitled to a sustained monopoly
| because it benefits us.
|
| Does 20.1 percent market share constitute a
| monopoly?(2023 Forbes) Seems like people have plenty of
| choices of what kind of cell phone to purchase.
|
| >treat their every action with scrutiny
|
| Is that not what the free market does? When companies
| make poor choices customers punish them. (Budweiser 2023)
| kmeisthax wrote:
| 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.
| simondotau wrote:
| > if you choose to buy their [device], you also are
| locked into their [software ecosystem].
|
| Other than desktop computing, this describes nearly
| everything sold to consumers. For people in the Hacker
| News audience, desktop computing would feel like a
| gargantuan exception, but for most other people it isn't.
| Android is a partial exception, but one gets the sense
| from Google's recent behaviour that openness is an
| unwelcome vestige of its open source beginnings.
| smoldesu wrote:
| 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.
| simondotau wrote:
| If your life revolves around desktop computers, I can see
| why you would think it's the norm.
| smoldesu wrote:
| Apple themselves distributed software as a binary before
| they had an App Store in the first place. If there was
| some other "norm" to speak of, it didn't exist when the
| Apple IIc hit shelves.
| smoldesu wrote:
| > Does 20.1 percent market share constitute a monopoly?
|
| Depends how it's used. _Wabash v. Illinois_ set the
| precedent that a far-minority can be a monopoly if they
| block a government-designated common carrier. Europe 's
| DMA doesn't even mention monopolies at all, and instead
| sets a new compliance bar for large tech-related
| companies. Japan's legislation is headed in the same
| direction.
|
| Seems entirely feasible to me that the App Store or
| Safari policies could be seen as obstruction of a common
| service. Apple's de-facto tax hasn't been explicitly
| blocked in the US yet, but it also has never been
| explicitly sanctioned. Without guidelines like the DMA in
| place, Apple is flying blind against US regulators.
| Microsoft got trapped _deep_ in that hall of mirrors, and
| nearly paid the ultimate price.
|
| > Is that not what the free market does?
|
| The free market is supplanted by a government that
| ensures that only a non-lethal portion of rat feces is
| processed into your container of SPAM or McDonalds meal.
| They prevent you from exposure to what businesses call,
| "profit maximization".
|
| If you have a _good_ government, they treat you a little
| better. They punish the companies that violate consumer
| rights and scrutinize anticompetitive behavior when it
| shows up. The free market chooses between regulated
| competitors; if you think that 's unfair, you can move to
| a country without the rat-feces regulators and see how
| your breakfast tastes over there. Then we can all be
| happy.
|
| > When companies make poor choices customers punish them.
| (Budweiser 2023)
|
| Your evidence is proof to the contrary of your claim.
| Budweiser wasn't "punished" for making an anticompetitive
| move, they were boycott because insecure Budweiser
| customers had a slow news cycle. If Apple had customers
| protesting for the same reasons, they'd never even know.
|
| "Poor choices" notwithstanding, Apple customers couldn't
| be assed _if_ they were angry. Suicide nets go up at
| Foxconn and the harshest words HN or MacRumors can muster
| is 'poor choice of manufacturing partner'. Conscientious
| startups and their Macbooks, nary separated any easier
| than protesting trailer parks and Budweiser.
| fh9302 wrote:
| 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.
| duskwuff wrote:
| 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.)
| threeseed wrote:
| > when they threatened to use MFi on USB-C, up until an EU
| Comissioner threatened to boot them from the market
|
| Except this never happened.
|
| And it doesn't even make any sense because MFi is when there
| is proprietary Apple technology involved which isn't the case
| for USB-C nor 3.5mm, Bluetooth etc.
| whywhywhywhy wrote:
| You need MFI to use Bluetooth unless it's audio through the
| system UI or BTLE
| threeseed wrote:
| Bluetooth is not part of MFI for any of the standard
| profiles.
|
| https://mfi.apple.com/en/faqs
| troupo wrote:
| > I wonder if there was some sort of back channeling with the
| EU
|
| 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_
| bevekspldnw wrote:
| There's always back channel that's how these things always
| work. One team of lawyers hashing it out with another.
| agust wrote:
| 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.
| masklinn wrote:
| 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.
| agust wrote:
| 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.
| turquoisevar wrote:
| Nope, that's not what iA says, and it would be a gross
| misrepresentation of the DMA to be honest.
|
| The section they're referring to is clause 64 in the lead of
| the DMA[0] and it is not only limited to cases of
| interoperability, unlike what iA implies it doesn't follow
| with a suggestion that gatekeepers can just ask if they're
| unsure. Instead it states:
|
| > In all cases, the gatekeeper and the requesting provider
| should ensure that interoperability does not undermine a high
| level of security and data protection in line with their
| obligations laid down in this Regulation and applicable Union
| law, in particular Regulation (EU) 2016/679 and Directive
| 2002/58/EC. The obligation related to interoperability should
| be without prejudice to the information and choices to be
| made available to end users of the number-independent
| interpersonal communication services of the gatekeeper and
| the requesting provider under this Regulation and other Union
| law, in particular Regulation (EU) 2016/679.
|
| That's why one of the main criticisms of the DMA is that
| gatekeepers generally can't present proposals for approval
| and have to wait until _after_ implementing to see if it is
| to the EC's liking.
|
| That said, the EU has inquired about the PWA stuff[1] and it
| seems that the outcome of that has been that Home Screen
| install doesn't need to be provided for other browsers.
| Allowing Apple to back down from their careful
| interpretation.
|
| 0: https://eur-lex.europa.eu/legal-
| content/EN/TXT/PDF/?uri=CELE...
|
| 1: https://9to5mac.com/2024/02/26/apple-blocking-web-apps/
| troupo wrote:
| 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
| jsnell wrote:
| 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.
| troupo wrote:
| > That's not true. The section the blog post is quoting
|
| That's the beauty of reading: you can read more than just
| the quote, and read the paragraph immediately after. Or the
| referenced section in the law:
| https://news.ycombinator.com/item?id=39565987
| jsnell wrote:
| 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.
| M2Ys4U wrote:
| I hope that the UK CMA enforcement action will smack Apple over
| the head for this one.
| dwaite wrote:
| ...to what end? Removal of the feature from iOS in the UK?
| turquoisevar wrote:
| 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/
| refulgentis wrote:
| 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.
| turquoisevar wrote:
| > The histrionical descriptions of other people's takes are
| like nails on chalkboard and kinda gross. (bloody murder?)
|
| Claiming that Apple is trying to "kill" PWAs is in and of
| itself histrionic. Especially when behavioral evidence that
| clearly points to the opposite is completely ignored and
| the bad faith intents are attributed wholly based on
| "vibes". My categorizing that as screaming bloody murder
| isn't an escalation in rhetoric[0] in the slightest.
|
| > Jen Simmons isn't a "rock star." It's a figure of speech
| within the industry, granted, it typically also implies big
| ego issues, so perhaps the term isn't so suitable when it
| comes to Simmons.
|
| > Hiring someone with a lot of Twitter followers
|
| Trying to diminish someone's accomplishments and relevance
| within an industry by pretending they "just have a lot of
| Twitter followers" does nothing to refute my arguments.
| She's one of 82 web developers with a Wiki bio and one of
| 177 programmers, that alone signifies notability.
|
| Point is that that she's a high profile programmer and web
| developer and those come at a premium. That, plus the
| significant efforts made in the last four years to not only
| support PWAs but also improve standards, runs counter to
| the notion that Apple has ill will towards PWAs.
|
| While she has spearheaded a lot of the investment in PWAs,
| for the purposes of this debate I only brought her up to
| emphasize Apple's investments in making improvements.
|
| Even with Simmons out of the equation there's still four
| years of significant engineering efforts to reconcile.
|
| > doesn't preclude the company from stopping doing
| something. You're begging the question here. Without you
| substantiating the implication that Apple has stopped
| improving PWAs, you're just throwing around empty words.
|
| Nevertheless, it's clear Apple hasn't stopped their efforts
| on PWAs, given that the next Safari update will, again,
| include a slew of improvements to the benefit of PWAs as
| can be seen in the Safari Technology Preview release
| notes[1].
|
| I'm amenable to debate this further, provided you put in
| some effort into make a credible case with substantiated
| arguments and you can keep the tone policing to yourself.
|
| 0: https://www.merriam-
| webster.com/dictionary/scream%20bloody%2...
|
| 1: https://developer.apple.com/documentation/safari-
| technology-...
| nemo8551 wrote:
| Gene Simmons however is a rock star.
| vundercind wrote:
| > The histrionical descriptions of other people's takes are
| like nails on chalkboard and kinda gross. (bloody murder?)
|
| Just shows the poster read the relevant threads on this
| very site.
| afavour wrote:
| > in light of their significant investment in supporting PWAs
| over the last four years
|
| Investing in PWAs for four years is only going to get you so
| far when you're eight years behind the competition.
|
| Obviously I'm making numbers up here but to my perspective
| Apple's recent investments (bringing them to a level still
| behind competitors) has a lot more to do with staving off
| legal threats to their 30% cut on native apps (e.g. the Epic
| lawsuit) than any benevolence towards the web platform.
| turquoisevar wrote:
| > Investing in PWAs for four years is only going to get you
| so far when you're eight years behind the competition.
|
| I don't think this speaks to intention, the investments
| that have been made and are still being made bring with
| them a cost, both in a monetary sense and in other ways.
| Regardless of the separate question with regards to them
| having been able to catch up with the competition.
|
| A generous interpretation, with the presupposed premise
| that they haven't been able to catch up, could say that it
| warrants a more favorable interpretation of their
| intentions if they were willing to invest after having
| lagged behind for so long, because the required investment
| would be greater and the pay off less clear.
|
| > (bringing them to a level still behind competitors)
|
| Let's be honest here. When people say something like this,
| they're mainly thinking of Chrome/Chromium-based browsers.
|
| Google is known to have no qualms supporting certain things
| that both Mozilla and Apple are uncomfortable with, while
| at the same time implementing a bunch of stuff that isn't
| standardized.
|
| On the whole, Safari/WebKit has roughly met Mozilla's level
| of support for frameworks and APIs and even surpassed
| Mozilla on certain things (especially desktop). Of course
| if the benchmark is just Chromium, then none of it will
| ever be enough, then again, Mozilla doesn't seem to catch a
| lot of flack for drawing a line in the sand in terms of
| support.
|
| Other than that, Safari seems to be doing great on test
| suites/benchmarks that focus on progress such as the annual
| Interop. Consistently[0] keeping up[1] over the years[2],
| and sometimes coming out on top[3].
|
| > has a lot more to do with staving off legal threats to
| their 30% cut on native apps (e.g. the Epic lawsuit) than
| any benevolence towards the web platform.
|
| I tend to stay clear with attributing maleficence or less
| than generous intentions without something substantial to
| back it up. Especially when behavior seems to contradict
| such attributions.
|
| For example, if that where the main motivator then I'd
| expect a bare minimum approach and Apple dragging their
| feet, like we see with DMA implementations (e.g., only
| allowing what must be allowed in the EU instead of
| globally), instead we not only see improvement of PWA
| support, in part beyond what Mozilla supports, but also
| direct contributions of standards that PWAs rely on in the
| form of improvements..
|
| 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
| lubujackson wrote:
| 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.
| scarface_74 wrote:
| 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%?
| afavour wrote:
| > 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.
|
| ...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.
| scarface_74 wrote:
| 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.
| int_19h wrote:
| 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.
| scarface_74 wrote:
| 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?
| afavour wrote:
| 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.
| scarface_74 wrote:
| 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?
| afavour wrote:
| 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.
| scarface_74 wrote:
| 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?
| afavour wrote:
| 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?
| scarface_74 wrote:
| > Because Candy Crush relies upon being an impulse
| purchase. If people had to go through five steps to buy
| it a ton of people would abandon it.
|
| But this does apply to apps that make up 90% of the
| revenue on the App Store. These aren't numbers I'm making
| up - it came out in the Epic trial.
|
| But even if that's not the case for the other 10%, the
| same would apply for the App Store that applies for
| Amazon in the real world. Smaller merchants still choose
| Amazon for the conversion and that's where the customers
| are when literally anyone can sell from a Squarespace
| website.
|
| > Again: my argument here is choice. Let developers
| decide. Your counter is "but one of them is better".
| You're entitled to your opinion but that isn't a counter
| argument to letting developers choose what type of
| payment system
|
| And that's the issue - everyone wants to use Apple's App
| Store and have their own payment system not avoid the
| exposure they get from the App Store.
|
| Once again, on Android where you can in fact tell users
| to go outside of the Google ay Store - hardly anyone
| does.
|
| Every Indy developer thinks their little app will be
| special and they would be okay outside of the App Store.
| If they can't even gain traction within the App Store
| what chances do they have of gaining traction outside of
| it? It's not the 15% cut that's keeping them from
| succeeding - small developers aren't paying 30%
| danShumway wrote:
| As a reminder, both Android and Amazon are being
| investigated for antitrust, and part of that complaint
| for Amazon is that they utilized an algorithm called
| Project Nessie to raise prices across the web for
| consumer goods even on 3rd-party storefronts:
| https://fortune.com/2023/11/02/amazon-algorithm-raise-
| prices...
|
| These are maybe not the shining corporate examples you
| want to compare Apple to.
| scarface_74 wrote:
| Google is being sued because they sold the idea of
| "freeduhm" and then changed the terms. There is plenty of
| precedence for this. This is why they loss thr Epic case
| and Apple won a similar lawsuit.
|
| But how is what Amazon doing any different than what the
| corner store does when it raises and lowers gas prices
| based on competition?
|
| And before you accuse me of being an Amazon apologist,
| I've mentioned plenty of times that I got Amazoned last
| year. I have no love loss for the company.
| danShumway wrote:
| > But how is what Amazon doing any different than what
| the corner store does when it raises and lowers gas
| prices based on competition?
|
| The FTC put out a blog post going into more detail about
| their complaints, which go beyond price adjustment to
| match competitors: https://www.ftc.gov/news-
| events/news/press-releases/2023/09/.... Their full
| complaint is at https://www.ftc.gov/system/files/ftc_gov/
| pdf/1910134amazonec...
|
| In particular, the FTC is interested in Amazon's pricing
| requirements which prohibit sellers from offering
| products at lower prices through other storefronts, its
| bundling of services which require sellers to buy
| unwanted fulfillment services in order to obtain
| unrelated placements in the Amazon store, and its
| privileging of discoverability to Amazon's own products
| and to paid advertisements over products that the FTC
| alleges Amazon knew were higher quality and better rated
| than the results it surfaced to customers
|
| The FTC's complaint describes this as a self-reinforcing
| feedback loop:
|
| > Because Amazon suppresses meaningful competition on
| price and product selection, shoppers lack viable
| alternatives, further forcing sellers to submit to
| Amazon's exclusionary tactics to reach those customers,
| and further allowing Amazon to accelerate and expand its
| dominance. Together, Amazon's conduct blocks off
| competition, shopper traffic, and seller business in the
| interrelated relevant markets.
|
| In other words, the more that sellers become dependent on
| Amazon, the more that shoppers become dependent on Amazon
| since goods and services are not available on other
| storefronts. This in turn makes sellers more reliant on
| Amazon since buyers become even harder to find off-site.
| Which in turn makes sellers more reliant on Amazon, and
| on and on.
|
| This has the effect of killing off 3rd-party storefronts
| since they are faced with a chicken-and-egg problem of
| trying to attract both sellers and buyers at the same
| time, and neither group can move off of Amazon
| individually without suffering financial penalties.
| afavour wrote:
| > And that's the issue - everyone wants to use Apple's
| App Store and have their own payment system not avoid the
| exposure they get from the App Store.
|
| But why would it be an issue to be in the App Store and
| provide your own payment option? Why not just let
| developers do that and let the market decide? I've asked
| that about four times now and you still haven't actually
| explained why.
| scarface_74 wrote:
| So you want to use Apple's marketplace and still not pay
| Apple? Can you put your goods in any other marketplace
| and not pay the market place owner in the real world or
| digital?
|
| If you want the "market to decide" force Apple to allow
| other app stores and you can let other app stores compete
| on price like the DMA demands.
|
| Can you distribute on Steam and not pay Steam? Can you do
| that in any physical store?
| danShumway wrote:
| Not to mention that "the app store is a better ecosystem
| because it's easier for kids to impulse-buy in-app
| purchases from scammy games" is a heck of a take.
|
| If mobile games are sticking to the app store purely
| because the purchase model on the web discourages impulse
| buys, that is a strong argument for investing more time
| and resources into the web as a platform and pushing more
| apps in that direction.
|
| "It's easier to monetize children" is not an argument in
| the app store's favor, it's an indictment on Apple's
| payment UX and parental controls. Presumably in this
| theoretical world, the only thing keeping Candy Crush off
| of the web is that he web isn't exploitative enough.
| Which... again, just a weird argument for anyone to make
| if they're arguing that the app store is the best
| solution for everyone. Everyone except users apparently.
| scarface_74 wrote:
| I'm saying that it isn't logically that Apple is keeping
| PWAs from becoming more popular because _today_ most of
| the revenue wouldn't leave the App Store because it comes
| from pay to win games.
|
| On the other hand I'm saying _today_ Android developers
| could move from Google Play and not have to pay the
| "Google tax". But they don't. Why not?
|
| Also if it is only Apple holding PWAs back, then why
| aren't PWAs a popular way to escape the "Google tax"?
|
| It must be that Android developers think 30% is worth it.
| ToucanLoucan wrote:
| If we ever reach a point where compiled code is equally
| as performant as web apps, I'll eat a shoe.
| danShumway wrote:
| 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?
| scarface_74 wrote:
| 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.
| danShumway wrote:
| > In that case, if PWAs were good enough on Android and
| they could avoid the 30% cut, why bother making native
| Android apps at all?
|
| I don't want to skirt too close to HN guidelines here,
| but I'm genuinely curious if you actually read my comment
| or not.
|
| This is exactly what I asked you. If PWAs are (as Apple
| _claims_ ) good enough alternatives to the app store, why
| isn't anyone using them?
|
| You can complain about Electron, but developers build
| Electron apps. They don't build PWAs. Because Electron
| apps are actually a feasible alternative to more native
| GUIs, and PWAs are not. The question you and I are asking
| (why isn't anyone using PWAs) reveals exactly how
| bullcrap Apple's legal arguments about PWAs are. They are
| not reasonable alternatives to the app store.
|
| > All of the HN commenters blame mean old Apple for
| holding the web back
|
| I don't blame Apple _exclusively_ for holding the web
| back. They 're a part of it, but so is Google. I don't
| think I've ever had much good to say about Google on
| here, and as the US and EU are actively proving right
| now, it is possible to pursue regulation for multiple
| companies at the same time.
|
| > You have much better ways to track on the we[b] then
| through native apps - at least on iOS with a much better
| permission model.
|
| This is not true by any metric. Native apps have more
| access to fingerprinting vectors than web apps do, are
| capable of requesting deeper levels of user information
| like contacts. Native Facebook on iOS got called out for
| injecting custom code into the in-app web view when users
| clicked on links within Facebook for 3rd-party sites.
| That's something that's not possible to do in any modern
| web browser.
|
| Native apps are indisputably easier to use to fingerprint
| and track users on both iOS and Android.
|
| Even if you're unfamiliar with the technical side of
| this, you can still think of it this way: if apps like
| Facebook had an easier time tracking you on the web than
| on mobile devices, they wouldn't try to get you to
| install mobile apps. They would force you to use the
| website. The reason why Facebook ships an iOS app is
| because it is easier to track you via iOS than through
| the Facebook website.
| scarface_74 wrote:
| 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?
| danShumway wrote:
| > of course Facebook could do that from the web.
|
| Facebook could insert custom code into 3rd-party domains
| that have no relationship with it?
|
| No, it can't. If Facebook could perform arbitrary XSS on
| 3rd-party websites it had no relationship with when you
| clicked on links on the Facebook website, that would be
| rightly treated as critical zero-day security flaw in any
| web browser.
|
| I mean, you're saying you're familiar with this stuff,
| but you're also saying that Facebook can do arbitrary XSS
| via links, so forgive me for doubting you. Of course
| fingerprinting is possible on the web. It's easier with
| native apps. The web at least tries to shut down
| fingerprinting vectors; native platforms like iOS largely
| don't. Far from shutting down fingerprinting vectors,
| both Android and iOS have platform-supported device-
| specific advertising IDs that don't even require
| fingerprinting. At least Apple (eventually) started
| clearing the low, low bar of forcing applications to ask
| permission to access it, but that's a far cry from the
| kind of sandboxing and site/app isolation that happens in
| Safari.
|
| > And what do you think is going to happen if there are
| more native APIs exposed in browsers?
|
| I'm sorry, your defense for privileging native apps over
| browser apps is "if browsers could do everything native
| apps could do, it would be a nightmare for privacy"?
|
| What do you think that says about the privacy and
| security of native apps?
| scarface_74 wrote:
| > No, it can't. If Facebook could perform arbitrary XSS
| on 3rd-party websites it had no relationship with when
| you clicked on links on the Facebook website,
|
| If you click on a link from Facebook on the web - the
| only reason you would view a page in a web view on the
| app - you don't think FB could know that you clicked on
| the link?
|
| I also see that you ignored the dozen or so well known
| ways that you can track someone across the web.
|
| Are you really saying you've never searched for something
| on one site and seen ads follow you around on other
| sites?
|
| > At least Apple (eventually) started clearing the low,
| low bar of forcing applications to ask permission to
| access it, but that's a far cry from the kind of
| sandboxing and site/app isolation that happens in Safari.
|
| I just cited a list of ways that apps can't track you
| across the web that you keep ignoring.
| danShumway wrote:
| > If you click on a link from Facebook on the web - the
| only reason you would view a page in a web view on the
| app - you don't think FB could know that you clicked on
| the link?
|
| If you click on a link from Facebook on the web Facebook
| _cannot perform arbitrary 3rd-party XSS on that page._ On
| iOS, they could. You are misunderstanding what the native
| vulnerability was. I still feel like you do not
| understand what the vulnerability here is.
|
| Facebook was allowed to insert arbitrary code into the
| system web view. That is not the same thing as knowing
| when you click on a link, it is the ability to
| arbitrarily execute code on 3rd-party domains regardless
| of whether or not those domains have any relationship
| with Facebook and regardless of whether they are fetching
| any Facebook resources/scripts. It is the ability to run
| custom Facebook code on sites like HN that do not
| normally insert Facebook pixels or tracking code.
|
| It is not the same thing as a link ID or tracking what
| link you clicked on.
|
| ----
|
| > I just cited a list of ways that apps can't track you
| across the web that you keep ignoring.
|
| I'm not ignoring any tracking vectors on the web, I'm
| pointing out (correctly) that every single tracking
| vector on that list and then some is available for native
| apps. Which... obviously, of course native apps can do
| graphics fingerprinting. They have access to the same
| system libraries.
|
| You've never searched for something in a mobile app and
| then seen an add for it elsewhere? You don't think that
| tracking networks exist for mobile apps? They do. I hate
| to be the one to break this to you, but native apps can
| also run low-level graphics code to fingerprint you. They
| can also look at connected media devices. They can also
| do audio fingerprinting.
|
| None of this is unique to the web.
|
| The big difference is details like the fact that those
| mobile apps can't be used with adblockers or anti-
| tracking protections, and of course that the embedded web
| views for apps like Instagram/Facebook allow for
| _arbitrary 3rd-party XSS_ , and that the native platforms
| expose device-specific tracking IDs and additional
| fingerprinting vectors in addition to all of the
| fingerprinting APIs that exist on the web.
|
| You're not citing anything that's unique to the web.
|
| And you keep ignoring the fact that _native Facebook on
| iOS could do arbitrary XSS attacks on 3rd-party sites!_
| Something that is not possible on the web and that is a
| much bigger deal than canvas fingerprinting. I don 't
| understand what part of this is tripping you up. This
| really is not something that is debatable; fingerprinting
| is not unique to the web, every tracking vector you're
| bringing up exists for native apps, and in general native
| platforms do a worse job at allowing users to block them.
|
| This really genuinely is not a subjective take -- it is
| an objective fact that mobile platforms expose more
| fingerprinting and tracking vectors than browsers do.
| This is not just an opinion, the device capabilities for
| native apps are higher than the capabilities exposed to
| websites and all of those capabilities are tracking
| vectors. In addition, native platforms like iOS allow
| nested content and inspection of nested content in a way
| that is not possible on the web, and allow for persistent
| storage and identifiers that are more difficult to
| construct on the web. And native platforms do not provide
| user-controller mechanisms like adblockers to reduce or
| eliminate trackers within apps. That is true of both iOS
| and Android.
|
| And native mobile platforms do all that _in addition_ to
| supporting all of the fingerprinting vectors that the web
| supports.
|
| ----
|
| > Are you really saying you've never searched for
| something on one site and seen ads follow you around on
| other sites?
|
| Generally no, on the web I use an adblocker so I don't
| see ads at all, let alone ads that follow me around.
| Notably, adblocking is not possible for native iOS
| applications to the same degree as it is even in browsers
| like Safari. That is yet another reason why native apps
| are worse for privacy and security than webapps are.
| scarface_74 wrote:
| > You've never searched for something in a mobile app and
| then seen an add for it elsewhere? You don't think that
| tracking networks exist for mobile apps?
|
| Well Apple decimated that ability with ATT. Facebook even
| admitted for instance they projected losing billions when
| Apple made cross app tracking opt in.
|
| > The big difference is details like the fact that those
| mobile apps can't be used with adblockers or anti-
| tracking protections
|
| https://cybernews.com/best-vpn/vpn-for-ad-blocking/
|
| > This really genuinely is not a subjective take -- it is
| an objective fact that mobile platforms expose more
| fingerprinting and tracking vectors than browsers do.
|
| You named _one_ additional way that you can track on an
| app if a user uses a web view.
|
| There are dozens of ways that websites can track you
| without your permission that aren't available in apps.
|
| > and allow for persistent storage and identifiers that
| are more difficult to construct on the web
|
| Really? You can't do persistent storage on the web that's
| available cross site?
|
| > And native platforms do not provide user-controller
| mechanisms like adblockers to reduce or eliminate
| trackers within apps. That is true of both iOS and
| Android.
|
| In fact they do, I just cited a list of VPNs you can
| install.
|
| > Generally no, on the web I use an adblocker so I don't
| see ads at all, let alone ads that follow me around.
| Notably, adblocking is not possible for native iOS
| applications
|
| Good thing that every single person or even the majority
| of people use ad blockers...
| danShumway wrote:
| > Well Apple decimated that ability with ATT.
|
| No, wrong again, please look this stuff up before you say
| things with this much confidence. The concerns I'm
| talking about popped up after ATT
| (https://www.theguardian.com/technology/2022/aug/11/meta-
| inje... and
| https://www.itechpost.com/articles/113985/20220923/meta-
| sued...).
|
| It is unclear to me that this vulnerability has ever been
| patched, though of course Facebook denies that they use
| it for tracking (but of course they do). In the interest
| of being diplomatic to Apple I am operating under the
| assumption that they eventually patched it, but I have
| never been able to find a source verifying that they did.
|
| As far as I know, Facebook is still doing this today in
| iOS.
|
| It is of course also notable that when Apple discovered
| that Facebook was essentially performing malware attacks
| on 3rd-party sites, they didn't remove Facebook from the
| app store or punish Facebook in any way. So let's also
| get rid of the idea that moderation is a solution here,
| because Apple has repeatedly proven that they are not
| willing to remove apps like Facebook that violate privacy
| rules. 3rd-party XSS was not a big enough deal to Apple
| to remove the Facebook app.
|
| ----
|
| > [censored VPN advertising site]
|
| VPNs are not a suitable alternative to native adblockers
| for a myriad of reasons that get discussed to death
| whenever VPNs come up in these conversations. Also,
| please do not link to a recommendation site that
| recommends NordVPN as the best VPN for privacy. NordVPN
| should be avoided.
|
| In general, while I take a much more positive view on
| VPNs than many other HN commenters and while I do think
| they can enhance privacy, I still agree with the advice
| of many security professionals that VPNs can open up
| users to substantial privacy risks and should not be
| lightly used without a good reason or without a lot of
| research into their privacy policies and management.
|
| > You named one additional way that you can track on an
| app if a user uses a web view.
|
| No, many. Low-level graphics, contacts, device IDs,
| webview injection, long-term storage, precise location,
| bluetooth connections, etc, etc... the list goes on and
| on.
|
| > There are dozens of ways that websites can track you
| without your permission that aren't available in apps.
|
| Such as? I can't think of a single one.
|
| ----
|
| > Really? You can't do persistent storage on the web
| that's available cross site?
|
| No, you can't! How is this a surprise to you?
|
| The lack of persistent cross-site storage and the fact
| that any available cross-site storage is strictly opt-in
| is one of the biggest things that the web does. It used
| to be a little bit worse with 3rd-party cookies, but not
| only was that still subject to cross-origin restrictions
| and still required opt-in from every participating site,
| but also every major browser is now restricting 3rd-party
| cookies (even Chrome).
|
| Even with PWAs on iOS, you can't access cross-site
| storage. In fact, Apple's entire justification for
| shutting down PWAs was that they wanted to ensure that
| cross-site storage restrictions continued to be respected
| (which is a bullcrap reason since every other browser
| already does this, but whatever).
|
| Seriously, I'm trying to be diplomatic and respectful
| about this, but you need to look up how security models
| on the web work before you spout nonsense like this. 3rd-
| party site isolation is a big deal on the web, as is
| easily cleared storage that is treated like a temporary
| container. Safari goes a step further and auto-clears
| some of that storage. It was a big deal with PWAs when
| they announced a single way to get just 1st-party storage
| to reliably persist long-term.
|
| There is no shared storage pool for the web that every
| site is subjected to, that is the entire point of cross-
| origin restrictions.
|
| ----
|
| > In fact they do, I just cited a list of VPNs you can
| install.
|
| See above.
|
| > Good thing that every single person or even the
| majority of people use ad blockers...
|
| More than the people using adblockers for iOS. Like
| seriously, do you think the number of people who pay for
| a VPN adblocker is higher than the number of people who
| install for free ublock origin or a similar Safari-
| compatible adblocker?
|
| This is absurd, you're looking at a tangible way in which
| native privacy is worse and you're saying, "but nobody
| uses the better solution." That's not exactly a
| convincing argument. I use adblockers online. My whole
| family does. Having at least the ability to protect
| oneself to some degree is important. You're not denying
| that for anyone that actually cares about privacy, the
| web is easier to secure -- you're just arguing that
| nobody cares about privacy. But some of us do.
|
| And if you're talking about what the average user does,
| the average user A) doesn't pay for VPNs (even if VPNs
| were a substitute for adblockers, which they're not), and
| B) doesn't turn down invasive data requests from native
| apps, of which there are far more available to make on
| native platforms than on the web.
|
| Objectively, factually, native app privacy is worse. It
| just is; you can either accept that or you can keep
| pretending that reality is something that it's not. But
| your lack of acceptance doesn't change anything about the
| reality that native platforms expose more fingerprinting
| vectors, have fewer ways for users to protect themselves,
| and are generally capable of much more invasive and
| malicious behavior.
| afavour wrote:
| > It is unclear to me that this vulnerability has ever
| been patched
|
| To my understanding Apple has provided a solution in the
| form of a new type of webview available to apps that
| protects privacy. Last I checked (I don't have the FB app
| installed for this exact reason so I'm not up to date) FB
| have not switched to using this new webview. It would be
| difficult to remove the functionality from the original
| API (WKWebView) because app developers like myself use it
| for legitimate reasons with internal web content. There
| have been some moves to lock advanced features behind an
| app-defined list of domains but it's far from
| comprehensive. Maybe in iOS 18 (he said skeptically).
|
| The answer is simple: Apple just needs to deny FB App
| Store approval until they switch APIs. Of course they
| haven't done that, and they won't.
| danShumway wrote:
| Thanks for the details, I've been curious for a while how
| this would shape up and I'm glad to get some information
| about the current state of things. Cross-origin
| privileges for inserting code would be my naive guess
| about how to lock that down, so it's good to hear that
| there's at least some dialog about it, even if it
| unfortunately seems to have not gone beyond the dialog.
|
| > The answer is simple: Apple just needs to deny FB App
| Store approval until they switch APIs. Of course they
| haven't done that, and they won't.
|
| Right, I guess to be a bit more fair to Apple, there are
| things they could do here that would make me more
| sympathetic to their arguments about moderation. The
| reason I'm generally unsympathetic to arguments that
| Apple moderation keeps the app store safe is because they
| don't moderate enough. I feel like I have a lot stricter
| standards about what apps should be able to get away with
| than Apple does.
|
| If Apple had when this story broke literally removed
| Facebook from the app store and forced them to disable
| that code, that would have been decent evidence to me
| that their moderation of the app store could have a
| substantial impact on privacy.
|
| I do think there are things Apple could do that would
| better justify their hold over the app store.
| DANmode wrote:
| In, at minimum, any way you agreed to on the permission
| screen when installing.
| saagarjha wrote:
| 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, ...
| scarface_74 wrote:
| 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...
| danShumway wrote:
| > The Safari version is exposed and the Safari version is
| tied to the OS version for iOS.
|
| User agents can be changed by users in Safari. I wouldn't
| recommend doing so, but it is possible to tell Safari to
| stop reporting the version number to websites. I'm
| unaware of any way to do the same for native apps.
|
| > There is also a battery level API that is not supported
| by Safari.
|
| Note that native iOS apps do have access to battery
| level, which is another fingerprinting vector that can be
| avoided by using websites through Safari or Firefox.
| scarface_74 wrote:
| 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...
| danShumway wrote:
| > Yes, I'm sure all of the people who are going to
| download an extension to change the user agent version in
| iOS are really going to mess with analytics
|
| Mechanisms to protect ourselves are not less valuable
| just because they're not universal. In any case, you
| shouldn't mess with your user agent primarily because a
| fake user agent on Safari is likely a bigger tracking
| vector than reporting the version -- but that's a
| separate conversation. The point being, you can do so if
| you have a need, unlike on native platforms.
|
| Apple could also of course de-bundle Safari from OS
| updates, which would be a large security/privacy benefit,
| but that would get in the way of the all-too-convenient
| coupling of Safari to iOS's security model. It might
| force them to actually build security layers into their
| OS rather than relying on privileged applications.
|
| And notably, this is likely to get better on the web,
| there is an ongoing conversation about how to handle user
| agent strings and how to reduce the information they leak
| without breaking capability tests. It's a complicated
| issue, but there are some interesting ideas that are
| being proposed for the web. As far as I know, I don't
| really see that conversation happening for native
| platforms, which seem to have an expectation that running
| an app should just privilege the app to know everything
| about the hardware.
|
| ----
|
| > You can't have it both ways. Either you want the
| wonderful world of PWAs where random websites have more
| access to your hardware and more parity with native apps
| and less privacy and security or you want it to remain
| more restrictive.
|
| You can in fact have it both ways, you can implement
| native APIs via sensible changes that push those
| capabilities behind permissions. Notably, the battery
| life API does not currently require a permission in
| Chrome; it should.
|
| Apple also had a good idea where PWA permissions were
| restricted to "installed" webapps. This shouldn't get rid
| of permission requirements, but it does significantly
| discourage webapps from requiring those permissions. The
| web is generally pretty good about this, but certain
| Google-proposed changes like the battery API are lagging.
| It would be good for the web and for users for Apple to
| be more involved in the standards process.
|
| And as I've advocated for a while, you can take things
| even one step further than the web currently does and you
| can refuse to tell applications when permissions are
| denied, instead faking data. For the battery API, rather
| than reporting that a permission is disabled, browsers
| should instead report fake numbers.
|
| But the idea that the web can't handle more advanced
| capabilities is false. Permissions are a complicated UX
| problem, but we have mechanisms to deal with them, and
| generally speaking the web has led the way on those
| mechanisms, with native platforms benefiting to a huge
| degree by imitating and building on web permission models
| and lessons.
|
| People tend to forget how bad mobile permissions used to
| be. I would argue that the mainstream adoption of native
| platforms for runtime permissions, required optional
| permissions -- these are ideas that were popularized on
| the web and I would argue the web still often does a
| better job of handling that UX. Not that the web couldn't
| do better, but it is in comparison to other platforms
| doing a noticeably better job.
|
| ----
|
| > These and more are all APIs that Apple has refused to
| implement that HN users are clamoring for. Which side do
| you fall on?
|
| I agree with Apple that the majority of the APIs on this
| list (with a few exceptions) are unnecessary for web apps
| and should be approached with caution. In particular Web
| USB is extremely reckless, does not (as far as I can
| tell) have sufficient sandboxing to prevent device
| tampering or side-channel attacks through USB devices
| onto other parts of the OS, and at the very least it
| probably requires more safeguarding than just a
| permission prompt. Chrome is reckless in implementing
| those APIs, Apple is right to defer them.
|
| That's not to say that they shouldn't be researched; NFC,
| Bluetooth, and MIDI input would be extremely important
| capabilities for the web if Google was proposing better
| privacy and security controls for them. Apple's policy
| around powerful web capabilities is often to stand to the
| side doing and saying nothing while Google develops bad
| specs, so that Apple has an excuse not to implement them.
| Needless to say, I don't give Apple credit for that. The
| world of notifications online would look very different
| if other stakeholders beyond Google had taken on bigger
| roles in shaping the API.
|
| Of course, there are also plenty of APIs that Safari
| hasn't implemented that are not privacy risks. App badges
| are a good example, there's no privacy or security risk
| from being able to notify users that an app's state has
| changed. And of course it's been talked about to death,
| but the entire web notifications API as implemented by
| both Google and Apple actively encourages apps to be less
| private and to be looser with data. That didn't need to
| happen, Apple's negligence is part of the reason why web
| notifications are primarily only useful for
| advertisements and interaction reminders. Apple could
| easily lead the way on doing something better.
|
| There is a lot of room for improvement here that doesn't
| require touching contentious or dangerous APIs. Typically
| when we talk about PWA capabilities on iOS, we're not
| talking about the ability to read device memory. What
| we're talking about is the ability to do much more
| innocuous things like schedule offline notifications
| without relying on a 3rd-party web server to trigger the
| notification -- something that would not only make PWAs
| more capable but would also make them more private and
| more secure.
| DANmode wrote:
| Facebook and Twitter webapps are awesome, by the way.
| danShumway wrote:
| 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.
| marcosdumay wrote:
| Software created by user-hostile organization is normally
| best on the environments where they have the least
| permissions.
| brookst wrote:
| 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.
| kelthuzad wrote:
| >I think it was saying that if Apple wanted to kill PWA
| it would have made more sense to just not make those
| investments over the past four years.
|
| wrong, Apple only started implementing the bare minimum
| because they felt the heat from devs & feared the legal
| consequences for their anti-competitive behavior.
|
| Apple still has the unquenchable desire to kill PWAs,
| they will just keep sabotaging them more subtly. Apple
| will keep up their shenanigans until the bitter end, but
| I hope that the EU will have none of it.
| afavour wrote:
| 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.
| nox101 wrote:
| 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)
| agust wrote:
| 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.
| mdhb wrote:
| 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.
| jajko wrote:
| 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.
| agust wrote:
| 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 ;)
| davidcbc wrote:
| > This is an important server
|
| It's really not. Self important maybe
| egberts1 wrote:
| Nowadays, using push notification, users can be exposed
| from behind VPN.
|
| Perhaps this is why Apple dragged their feet.
| agust wrote:
| Lol, good one. And they just forgot to remove them for
| native apps, right?
| danlugo92 wrote:
| 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.
| int_19h wrote:
| 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 ...
| ihateolives wrote:
| https://ladybird.dev/
| dwaite wrote:
| > Investing in PWAs for four years is only going to get you
| so far when you're eight years behind the competition.
|
| Which non-Chromium competitors are you speaking to here?
| What are some examples of standards-track features that
| they implement that Apple doesn't?
| afavour wrote:
| > 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.
| wolfendin wrote:
| "The competition" is just Google/Chrome.
|
| Unless there's someone else?
| afavour wrote:
| I don't understand the relevance of that, why would it
| invalidate the point?
| temac wrote:
| 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"
| brookst wrote:
| Business is hard enough operating directly. Triple bank
| shots that require business and legal to coordinate are too
| complicated to attempt.
| wraptile wrote:
| 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".
| ranguna wrote:
| They already did that with iMessages though.
| jrochkind1 wrote:
| From the bottom of OP:
|
| > Apple's move also comes after a threat to look into the
| issue by European Commission authorities.
|
| > "We are indeed looking at the compliance packages of all
| gatekeepers, including Apple," the European Commission said
| in a statement on February 26. "In that context, we're in
| particular looking into the issue of progressive web apps,
| and can confirm sending the requests for information to Apple
| and to app developers, who can provide useful information for
| our assessment."
| danShumway wrote:
| 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.
| shuckles wrote:
| 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.
| danShumway wrote:
| > The DMA was passed many years ago (January 2022),
| before the cited investments in PWAs. So if Apple was
| acting to proactively stave off regulation, you have a
| big hole in your theory of causality.
|
| I'm not sure I do? The DMA was passed in January 2022. In
| that entire span of time when Apple was actively arguing
| in court that PWAs were an alternative to the app store,
| at no point did they ever consider building out a proper
| security model for PWAs that didn't rely on the
| assumption that Safari would be the only supported
| browser.
|
| You're saying that Apple learned about the DMA before
| they started looking at PWAs seriously, then we got to
| February 2024 and suddenly Apple was caught flat-footed
| about browser requirements? That doesn't make sense:
| either they knew about the DMA and their current lack of
| PWA security models are an active decision that
| purposefully complicated compliance with the DMA, or
| Apple somehow wasn't thinking about the DMA in which case
| it's kind of silly to say that it disproves anything
| about their apparent web strategies.
|
| This is a situation where the excuse makes Apple seem
| _more_ suspicious, not less. Apple knows in 2022 that the
| DMA is coming. In _February 2024_ out of the blue they
| announce that they 're shutting down PWA support. If
| that's not strategic, it's at least wildly incompetent.
| And I don't think that Apple is wildly incompetent -- I
| think that announcement was strategic.
|
| > So if Apple was acting to proactively stave off
| regulation
|
| I'll also note that this is not a theory, Apple is
| actively arguing in the US that PWAs mean that it
| shouldn't be regulated. I don't really understand the
| contention here, the way I see it _Apple_ is saying that
| PWAs are a proactive strategy to stave off regulation.
|
| We can disagree about their motivations beyond that
| regulation, about whether they would consider dropping
| support in the absence of regulation, but it is just a
| fact that Apple started investing more heavily in Safari
| around the same time that regulation arguments started
| popping up in both Europe and the US, and it is just a
| fact that Apple has proactively put forward PWAs as an
| argument in court cases as to why it shouldn't be
| regulated.
|
| Is it really that weird to connect those dots?
|
| ----
|
| > Apple's interest in the web cannot be gauged by how
| much they support technology funded and evangelized by a
| bunch of current and ex-Googlers
|
| Apple's support and advocacy for PWAs is pathetic even
| ignoring Chrome's support. It's not like Chrome has good
| PWA support, the entire notifications API is obviously
| designed by an advertising company with zero real input
| from any stakeholders other than advertisers.
|
| Ideally, investment from Apple into the PWA ecosystem
| would mean not leaving the entire PWA specification to be
| written entirely by an advertising company, it would mean
| proactively getting involved in the process. It would
| mean asking questions like, "aside from Google, who on
| earth does it benefit that notifications have to be
| triggered by a remote server and can't be scheduled
| locally?"
|
| The state of PWAs is as much a story about the apathy of
| every other company besides Google as it is a story about
| Apple holding back on basic support for extremely needed
| features like reliable offline storage. I'm not giving
| Apple credit for sitting back and twiddling its thumbs
| while Google ruins the spec, and then turning around and
| saying, "you can't expect us to implement these features,
| the proposed specs are terrible."
|
| Yeah, of course they're terrible, where were you while
| Google was ruining them? I'm surrounded by people arguing
| that Safari is some kind of final bastion against Chrome
| hegemony, but in practice Apple does _nothing_ with that
| bastion. They let Google make all the decisions, and then
| use that as an excuse to offer middling browser support.
| I 'm not giving them credit for that. I'm not talking
| about exposing web usb support, I'm talking about things
| like: is it possible build an alarm clock as a PWA?
|
| I'm not asking Apple to bow to Google's every demand, I'm
| asking them to act like they're a stakeholder in the web
| and to give even one single damn about whether it's
| possible to build privacy-respecting offline webapps.
| Apple's apathy towards influencing or pushing the PWA web
| standards process in a productive direction is just as
| much a problem as their apathy towards supporting
| obviously beneficial capabilities like icon badges. Apple
| defers power to Google and then uses that as an excuse
| for further inaction.
| nox101 wrote:
| 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.
| latexr wrote:
| > AFAIK, iOS Webkit doesn't support fullscreen mode and
| orientation
|
| I just opened a web app saved to the Home Screen, and it's
| both full screen and rotates orientation.
| jwells89 wrote:
| 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.
| nox101 wrote:
| 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
| nox101 wrote:
| "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.
| mvdtnz wrote:
| > The notion that Apple was purposefully trying to kill PWAs
| never made sense in light of their significant investment in
| supporting PWAs over the last four years, down to recruiting
| industry rockstars such as Jen Simmons.
|
| Apple's investment into PWA support can charitably be
| characterised as "begrudging". You don't need to defend this
| company. They have been behaving badly for a long time.
| NicoJuicy wrote:
| Significant investment... For apple or app store profits it's
| just a rounding error ( to put things in perspective).
|
| What is the end result?
| ruszki wrote:
| 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.
| quitit wrote:
| 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.
| nguyenkien wrote:
| 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.
| nickthegreek wrote:
| 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.
| brookst wrote:
| 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.
| dwaite wrote:
| Myself, I'll use PWA to mean "promoted web app" - since it
| is closer in this context, and 99% of the market gets
| "progressive" wrong anyway.
|
| I believe that third party browser engines will have the
| same privileges as WebKit (in the EU, on iOS only).
|
| PWAs do not run directly on WebKit; they run on Web.app
| which is a WebKit-based application. Think something like
| Cordova, provided by the OS, but which does not require
| each PWA to be a separate wrapped app listed in the App
| Store.
|
| There is a recently-added interface to create one of these
| Web.app PWAs by third party browsers, as well as to create
| home screen bookmarks (which I believe open in the default
| browser not the running browser, but I am not a browser
| implementer).
|
| There is not however not a way for a browser vendor to ship
| their own Web.app-equivalent using their browser engine.
|
| Simulating some of the behaviors of a PWA on iOS outside of
| Web.app is also difficult. For instance - the multi-window
| functionality of iPadOS is not present, so a fullscreen web
| app would block usage of other tabs.
| pier25 wrote:
| 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?
| wintermutestwin wrote:
| Great question. Orion is built on WebKit and works with
| firefox extensions (uBlock)
| lxgr wrote:
| 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.
| lilyball wrote:
| 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.
| robertoandred wrote:
| Yes there does, other browsers already use it.
| robertoandred wrote:
| Other browsers can already add PWAs. Presumably they'd just
| continue using WebKit to matter what engine the browser in
| question uses.
| pier25 wrote:
| > _This means that all Home Screen web apps will still be
| powered by WebKit, regardless of whether the web app is added
| using Safari or not - exactly as it works today and has for
| years._
| Despegar wrote:
| 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.
| lxgr wrote:
| > 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.
| hananova wrote:
| 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.
| lxgr wrote:
| 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.
| Despegar wrote:
| 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.
| Muromec wrote:
| 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.
| shaky-carrousel wrote:
| 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.
| ginko wrote:
| >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.
| paulmd wrote:
| 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.
| dwaite wrote:
| > If you can't win in the marketplace of ideas, just ban
| walled gardens entirely. Flip the table and ban your
| competitors' business model, bioshock style.
|
| But the DMA doesn't ban walled gardens. It requires the
| availability of competitive alternative marketplaces,
| which can certainly just lead to multiple walled gardens.
| shortsunblack wrote:
| 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.
| d1sxeyes wrote:
| 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.
| Despegar wrote:
| 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.
| rejhgadellaa wrote:
| 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
| lxgr wrote:
| 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).
|
| > open up anything that Safari can do (like run PWAs).
|
| I think it would be just as valid a viewpoint to consider
| them an OS feature (as opposed to a browser feature). The
| question then is whether that OS feature would be considered
| protected under the DMA.
|
| For example, it's also impossible to provide your own kernel
| extensions (e.g. to facilitate hardware device drivers) for
| iOS - but that's completely fine (as far as I understand)
| under the DMA, since it's not one of the covered areas like
| app stores, NFC payments etc.
|
| I'm not very certain of the last point, FWIW - maybe the DMA
| does actually require Apple to provide, on demand, access to
| hardware interfaces available to their own product offerings!
| For example, wireless (Qi) outbound charging is supported by
| recent iPhones, but only works with Apple's own Magsafe power
| bank, and other power banks can only do inbound wireless
| charging and need to be charged via USB - maybe that's
| actually noncompliant too? That would likely kill, or at
| least strongly impact, Apple's MFI program in the EU - or
| maybe just expand it to cover all first-party hardware
| interfaces too?
| summerlight wrote:
| > For all we know, the EU might be considering PWAs a thing
| completely orthogonal to DMA compliance, since they neither
| provide feature parity with native apps, nor are they
| widely used (at least according to Apple's measurements).
|
| DMA wording made it very clear that it's about browser
| engine, not the browser product. And Safari is designated
| as a core platform service.
|
| > The gatekeeper shall not require end users to use, or
| business users to use, to offer, or to interoperate with,
| an identification service, a web browser engine or a
| payment service, or technical services that support the
| provision of payment services, such as payment systems for
| in-app purchases, of that gatekeeper in the context of
| services provided by the business users using that
| gatekeeper's core platform services.
| lxgr wrote:
| > DMA wording made it very clear that it's about browser
| engine, not the browser product.
|
| Yes, but nowhere does it say explicitly that that third-
| party browser engine has to also be capable of hosting
| PWAs. It's definitely a possible read of the DMA, but not
| the only plausible one, in my view.
| EMIRELADERO wrote:
| It does:
|
| Clause 7 Article 6 of the DMA states:
|
| > _The gatekeeper shall allow providers of services and
| providers of hardware, free of charge, effective
| interoperability with, and access for the purposes of
| interoperability to, the same hardware and software
| features accessed or controlled via the operating system
| or virtual assistant listed in the designation decision
| pursuant to Article 3(9) as are available to services or
| hardware provided by the gatekeeper._
|
| > _Furthermore, the gatekeeper shall allow business users
| and alternative providers of services provided together
| with, or in support of, core platform services, free of
| charge, effective interoperability with, and access for
| the purposes of interoperability to, the same operating
| system, hardware or software features, regardless of
| whether those features are part of the operating system,
| as are available to, or used by, that gatekeeper when
| providing such services._
| robertoandred wrote:
| Are PWAs browsers?
| worksonmine wrote:
| 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.
| robertoandred wrote:
| What happens to those PWAs when you uninstall Firefox?
| dylan604 wrote:
| 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.
| worksonmine wrote:
| > having to create a shortcut based on which browser
| would be ridiculous
|
| Depends how you look at it, Chromecast is only available
| from Chrome. If I want a specific page to open in Chrome
| because I use it mainly to cast videos should I have to
| switch my main browser to Chrome?
|
| Probably not how it works today and my initial comment
| didn't imply always open in Firefox even if not default
| browser, but thinking about it maybe that's how it should
| work, or the option to choose should be available?
| int_19h wrote:
| From the casual user's perspective, it does not "open in
| Firefox", though. It opens in a separate window with very
| different chrome, and you have to poke around to even
| determine which browser is actually hosting it.
|
| Furthermore, on macOS specifically, PWAs are fairly well
| decoupled from browsers. For example, if you install a
| PWA in Safari, and then click on an external link in said
| PWA, it will not open that link in Safari, but rather in
| whatever your default browser is.
| shaky-carrousel wrote:
| Hopefully they'll respond with huge fines.
| layer8 wrote:
| 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.
| mastazi wrote:
| 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.
| arlort wrote:
| The authority of the courts is the same, it's precedent
| which has less relevance in civil law systems
| Nemo_bis wrote:
| 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...
| summerlight wrote:
| No, DMA wording made it very clear that it's about web browser
| engine.
|
| > The gatekeeper shall not require end users to use, or
| business users to use, to offer, or to interoperate with, an
| identification service, a web browser engine or a payment
| service, or technical services that support the provision of
| payment services, such as payment systems for in-app purchases,
| of that gatekeeper in the context of services provided by the
| business users using that gatekeeper's core platform services.
|
| And they cannot make self-preferencing on their products.
|
| > The gatekeeper shall not treat more favourably, in ranking
| and related indexing and crawling, services and products
| offered by the gatekeeper itself than similar services or
| products of a third party. The gatekeeper shall apply
| transparent, fair and non-discriminatory conditions to such
| ranking.
|
| > The gatekeeper shall not restrict technically or otherwise
| the ability of end users to switch between, and subscribe to,
| different software applications and services that are accessed
| using the core platform services of the gatekeeper, including
| as regards the choice of Internet access services for end
| users.
|
| And Safari has been explicitly designated as a separate core
| platform service. There's no room for this kind of
| interpretation in the view of enforcement entity. Apple is just
| trying to buy time by pretending ignorance.
| layer8 wrote:
| 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.
| summerlight wrote:
| 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.
| layer8 wrote:
| 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.
| smoldesu wrote:
| > The argument can be made that this is not Safari, but a
| PWA runtime environment that happens to use WebKit
| internally.
|
| This is a silly and thin technicality, and not at all the
| same as what people are mad about. Nobody cares that
| WebKit is used to render certain windows on iOS and MacOS
| - it's Apple's choice to implement first-party programs
| that way. They can defend their usage of it internally,
| the problem is the limitations they impose on
| competitors.
|
| > I've read the DMA
|
| You're certainly taking some elements in liberty. It
| remains unclear how defining WebKit as a "PWA runtime
| environment" exempts it from the terms of the DMA or DSA.
| layer8 wrote:
| 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.
| smoldesu wrote:
| > provide a compelling explanation of how the way iOS
| runs PWAs constitutes a use of Safari, or of web
| browsing.
|
| Oh, this is easy.
|
| First-party software is distributed by Apple. They choose
| how that software is presented because they are the
| operator of the software.
|
| PWAs and websites are distributed by third-parties. They
| are websites, not curated by Apple, that load in your
| browser. It's only after you use your browser's "PWA"
| function (something everyone should have) that we change
| into this "WebView" scenario. It's arbitary, and not at
| all the same as Apple rendering Apple Music or Settings
| using WebKit.
|
| > how a PWA runtime environment differs in principle from
| the regular iOS app runtime environment
|
| A PWA is packaged by the user. If Apple's "solution" is
| forcing all apps to display PWAs in a Safari WebView,
| then yes, the DMA will target it as a core service. I
| don't see why the EU would roll over when they made
| specific carveouts for browser control in the DMA.
| summerlight wrote:
| I'm not sure if you've only read some digests but not the
| full text including other supporting materials (it
| matters since this defines how the laws will be applied)
| since all you mentioned are already addressed in the
| designation decision doc. To be specific, in DMA.100027,
| EU clearly stated that it doesn't matter whether it's
| embedded in other apps or standalone: >
| "... the Commision concludes that Safari, including all
| the elements that allow for the display and access to web
| content, either standalone, integrated or embedded in
| other software applications or similar, constitutes a web
| browser CPS ..."
|
| If you've seriously worked on hashing out all the details
| of CPS and clearing up the ambiguities, you cannot be
| unaware of this decision since this will impact
| everything on your daily works. Yeah I did that because
| the precise definition of CPS was critical for my work in
| the last year.
|
| EU is not that dumb, to my understanding they've been
| pretty serious in respecting the spirit of this specific
| legislation. You cannot say that some part of it can be
| simply opted out by adjusting the definition of your
| product. What they care about is how business is done and
| make the market control out of it.
| ajross wrote:
| 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.
| insidepitch wrote:
| 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.
| turquoisevar wrote:
| You're misreading pretty much everything you've quoted from
| the DMA.
|
| > No, DMA wording made it very clear that it's about web
| browser engine.
|
| You follow this up by quoting a clause that manages core
| platform services.
|
| What it says is:
|
| > The gatekeeper shall not require [people] to use, to offer
| or interoperate with [stuff] of that gatekeeper in the
| context of services provided by [third party devs] who use
| the gatekeeper's core platform services.
|
| A good example where this is applicable is the App Store,
| which is designated as a core platform service. PWAs aren't
| designated as core platform service and there's also an
| argument to be made that web developers aren't considered
| "third party devs" (or as the DMA calls them "business users"
| due to a lack of agreement between Apple and them.
|
| > And they cannot make self-preferencing on their products.
|
| Same here. This one is even narrower because it's only
| limited to preferential treatment in the sense of "ranking
| and related indexing and crawling"
|
| > The gatekeeper shall not treat more favourably [in ranking
| and related stuff] [their own products and services] than
| [similar products and services by others]
|
| This applies to ranking apps in the App Store. It has no
| bearing whatsoever on PWAs unless somehow Apple starts
| ranking PWAs in a list and then chooses to rank their own
| PWAs higher.
|
| The other one is also much narrower than you're reading it.
|
| > The gatekeeper [shall not prevent users from switching to
| and subscribing to different apps including browsers]
|
| This mainly pertains to setting default apps and switching
| default apps. This tangentially relates to PWAs, but
| installed PWAs are technically not run in Safari and instead
| in their own app that uses WebKit under the hood, so it's not
| so clear if this would apply to PWAs.
|
| > There's no room for this kind of interpretation in the view
| of enforcement entity. Apple is just trying to buy time by
| pretending ignorance.
|
| I can't distill a lifetime worth of legal experience into a
| tangible piece of evidence nor are there readily available
| authoritative sources on compliance with government
| regulation narrow and simple enough that I can just present
| them without much worry of you understanding them, especially
| since you're already struggling with, what is considered in
| European legal standards, rather straightforward legal text.
|
| So all I have is a trust me bro, and perhaps an appeal to
| common sense: Apple's lawyers didn't just wake up today and
| said to themselves "You know what, we were too cautious with
| interpreting the DMA a couple of weeks ago, I'm sure it'll be
| fine if we keep PWA installs without implementing a way for
| other browsers to install them as well", much less a
| variation in which they are trying to buy time by feigning
| ignorance.
|
| We already know that the EU reached out to Apple about
| disabling PWA installs. So with that in mind, do you think
| the lawyers woke up one day and said "fuck it" or do you
| think it's more likely the lawyers gave the go ahead after
| the EU told them that PWA installs as implemented in iOS are
| beyond the scope of the DMA?
| EMIRELADERO wrote:
| > A good example where this is applicable is the App Store,
| which is designated as a core platform service. PWAs aren't
| designated as core platform service and there's also an
| argument to be made that web developers aren't considered
| "third party devs" (or as the DMA calls them "business
| users" due to a lack of agreement between Apple and them.
|
| The core platform service in this case would be iOS itself.
|
| Also, nowhere in the DMA does it say that there must be a
| contractual relationship between an entity and the
| gatekeeper in order for the former to be considered a
| business user. Windows is a designated CPS under the DMA
| and no contract with MS is required in order for you to
| make, distribute, and have your users run your software on
| their Windows PCs.
| cogman10 wrote:
| Who else even does PWAs? Firefox removed them which leaves
| chrome, edge, and now maybe safari.
| lxgr wrote:
| 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!
| Andrex wrote:
| 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.)
| bastawhiz wrote:
| 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.
| andix wrote:
| 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.
| xiaomai wrote:
| > After all I think Android also has a Chrome-only
| implementation for PWAs, exactly like Windows, that runs PWAs
| 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).
| littlecranky67 wrote:
| 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.
| archerx wrote:
| 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.
| MattBearman wrote:
| 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.
| aeurielesn wrote:
| I also wonder what's point of PWAs _only_ supported in WebKit.
|
| It feels like they trying to keep playing cat and mouse.
| readams wrote:
| 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.
| kemayo wrote:
| 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.
| jamesgeck0 wrote:
| 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.
| dunham wrote:
| 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.
| albert180 wrote:
| Because they are their go to excuse why the limitation to
| the App Store isn't a monopoly with the regulators.
| burnerthrow008 wrote:
| 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?
| albert180 wrote:
| No, but they are obviously not equivalent in capabilities
| on iOS
| realusername wrote:
| 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.
| graftak wrote:
| 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.
| agust wrote:
| 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...
| robin_reala wrote:
| These black and white takes are boring. It can be all of
| the above.
| Sammi wrote:
| 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.
| robin_reala wrote:
| Then why would they have bothered adding any support in
| the first place? There are market incentives in at least
| appearing to be modern.
| Sammi wrote:
| 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.
| lloeki wrote:
| > 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.
| mthoms wrote:
| >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.
| agust wrote:
| 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.
| Someone wrote:
| 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."_ )
| mthoms wrote:
| 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.
| brookst wrote:
| 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.
| evilduck wrote:
| 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.
| leptons wrote:
| 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.
| isleyaardvark wrote:
| 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?
| d1sxeyes wrote:
| Not all EU countries use the euro.
| leptons wrote:
| 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.
| rchaud wrote:
| 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.
| dnissley wrote:
| My take is that it's more about control of the
| experience, which is something baked into Apple's DNA.
| danaris wrote:
| 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?
| isleyaardvark wrote:
| They're somehow only concerned with profit, but only
| concerned with profit in the EU, since their PWA changes
| only affected that region.
| realusername wrote:
| > 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.
| rejhgadellaa wrote:
| 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.
| Nemo_bis wrote:
| Don't "installable PWAs" require service workers?
| scarface_74 wrote:
| Like they have emerged as a viable option on Android?
| sangnoir wrote:
| 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?
| ryandrake wrote:
| 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.
| Tteriffic wrote:
| AppClip would be best
| scarface_74 wrote:
| Well, and that all works on Safari...
|
| And that's not what most people consider a PWA.
| sangnoir wrote:
| 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.
| scarface_74 wrote:
| Or you know, go to the agenda before you leave your hotel
| and convert it to a PDF....
| zer00eyz wrote:
| 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.
| kmeisthax wrote:
| 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.
| fredoralive wrote:
| 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.
| rezonant wrote:
| 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.
| mmis1000 wrote:
| 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)
| adrr wrote:
| 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.
|
| https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
| yurishimo wrote:
| 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.
| adrr wrote:
| 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.
| monocularvision wrote:
| 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.
| Nemo_bis wrote:
| 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>>.
| brookst wrote:
| 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.
| ingen0s wrote:
| This is a good news <3
| charcircuit wrote:
| 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.
| troupo wrote:
| > 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.
| charcircuit wrote:
| >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.
| troupo wrote:
| > 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.
| charcircuit wrote:
| >Meanwhile you're defending a company that made 93
| billion dollars in net profit last year.
|
| Yes
| jsnell wrote:
| 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.
| charcircuit wrote:
| >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.
| jsnell wrote:
| 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.
| charcircuit wrote:
| >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.
| mort96 wrote:
| No part of their communication up until now had indicated that
| PWA removal was a temporary thing.
| charcircuit wrote:
| 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.
| mort96 wrote:
| 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.
| charcircuit wrote:
| They are taking on legal risk instead of investing
| resources.
| nchmy wrote:
| 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.
| seanabrahams wrote:
| OWA[0]
|
| 0: https://open-web-advocacy.org/
| robertoandred wrote:
| I think people were laughing at the tactics OWA uses. For
| example, saying "web apps" are being killed is intentionally
| misleading.
| rezonant wrote:
| Fantastic. That's one giant step backwards not taken for the web
| platform.
| insin wrote:
| Is there any chance they'll ever allow Safari web extensions to
| run in PWAs?
| ajross wrote:
| 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.
| dwaite wrote:
| 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.
| jespertheend wrote:
| 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.
| nchmy wrote:
| 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!
| lakpan wrote:
| 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.
| brimstedt wrote:
| Would you mind elaborating?
|
| I still find Firefox superior to safari.
| nottorp wrote:
| 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.
| ezfe wrote:
| Wipr on my iPhone blocks all my ads, INCLUDING YouTube
| nottorp wrote:
| 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.
| lotsofpulp wrote:
| With a content blocker, you don't have to trust it, no
| data is being sent. It's like a hosts file.
| jespertheend wrote:
| 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.
| burnerthrow008 wrote:
| 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.
| hu3 wrote:
| 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?
| burnerthrow008 wrote:
| > 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.
| smoldesu wrote:
| > 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.
| mthoms wrote:
| >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:Br
| ows...
|
| Maybe you should have done some research before throwing
| out all that seething condescension?
| ascagnel_ wrote:
| 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.
| danShumway wrote:
| > 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.
| Someone1234 wrote:
| 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.
| nottorp wrote:
| 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.
| agust wrote:
| 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.
| tsbinz wrote:
| 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.
| sircastor wrote:
| > 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.
| agust wrote:
| 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.
| asadotzler wrote:
| 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.
| palmfacehn wrote:
| 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.
| agust wrote:
| 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.
| tsbinz wrote:
| 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.
| scarface_74 wrote:
| 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"...
| Nemo_bis wrote:
| 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?
| robertoandred wrote:
| 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.
| fsflover wrote:
| Related discussion:
| https://news.ycombinator.com/item?id=39563982
| pjmlp wrote:
| 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.
| sylware wrote:
| 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.
| laserlight wrote:
| 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...
| rejhgadellaa wrote:
| 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.
| judge2020 wrote:
| 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.
| disgruntledphd2 wrote:
| 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.
| unglaublich wrote:
| 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.
| pquki4 wrote:
| 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.
| aptgetrekt wrote:
| 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.
| zamadatix wrote:
| 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.
| MatthiasPortzel wrote:
| 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.
| monero-xmr wrote:
| 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.
| orev wrote:
| 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.
| amelius wrote:
| 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.
| danShumway wrote:
| 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.
| aptgetrekt wrote:
| 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.
| TrianguloY wrote:
| 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...
| zarzavat wrote:
| 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 celebre and brought the
| issue to the attention of the EU.
|
| Hanlon's razor should be applied.
| Nemo_bis wrote:
| 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.
| Squarex wrote:
| Thanks god! I've already started porting my personal app from
| sveltekit pwa to react native...
| YetAnotherNick wrote:
| Why not just use WebView?
| Squarex wrote:
| I've had problems with getting service workers to work.
| megaman821 wrote:
| 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.
| nickthegreek wrote:
| > 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.
| megaman821 wrote:
| 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.
| rejhgadellaa wrote:
| 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.
| ivanjermakov wrote:
| You've posted your comment twice.
| dang wrote:
| Might have been a mistake? I've killed the other one as a
| dupe now (https://news.ycombinator.com/item?id=39565557).
| rejhgadellaa wrote:
| Yep that was a mistake. Thank you!
| Aissen wrote:
| 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.
| whywhywhywhy wrote:
| 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.
| kevingadd wrote:
| 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?
| andy_ppp wrote:
| I might try an Android if Apple keep being dicks.
| jamwil wrote:
| See ya in six months.
| eklavya wrote:
| 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.
| eknkc wrote:
| 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.
| redox99 wrote:
| I find Android OS (Samsung in particular) to be vastly
| superior to iOS. I only like iPhone's hardware. But to each
| their own.
| rvba wrote:
| 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.
| nozzlegear wrote:
| > 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.
| the_gipsy wrote:
| 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.
| urbandw311er wrote:
| 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.
| disgruntledphd2 wrote:
| 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.
| ikekkdcjkfke wrote:
| 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
| amelius wrote:
| 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.
| jamwil wrote:
| 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.
| ENGNR wrote:
| iOS and the web accomplishes that
|
| (not that I've ever had a virus on a mac)
| amelius wrote:
| 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?
| jamwil wrote:
| Non-technical people do seem to show a strong preference
| for their phones and iPads, yes.
| endisneigh wrote:
| why not get pinephone?
| t00 wrote:
| Just. Stop. Using. Their. Products.
|
| Apologies but it had to be said.
| willi59549879 wrote:
| 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.
| badrabbit wrote:
| 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?
| shrimp_emoji wrote:
| 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.
| MiddleEndian wrote:
| 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.
| postalrat wrote:
| You get to run an app without worrying its tracking your
| location, contacts, who knows what else.
| danShumway wrote:
| 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.
| cageface wrote:
| 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.
| badrabbit wrote:
| What stops devs from making PWAs anyways even when people
| want to pay for a native app? Cheaper that way.
| asadotzler wrote:
| When I already have a PS4, why would I want a Steamdeck.
| Because it opens up more opportunity, more things to do.
| willi59549879 wrote:
| 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.
| below43 wrote:
| It's an excellent distribution mechanism for apps that you
| don't want listed on the app store, or ones that won't be
| approved, or can't be distributed eg. Company/Internal apps
| (that are installed on employee's personal devices)
| andix wrote:
| 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.
| j45 wrote:
| The real reversal is committing to not trying this again
| jfoster wrote:
| 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?
| Rohansi wrote:
| 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.
| jfoster wrote:
| 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.
| simondotau wrote:
| 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.
| redox99 wrote:
| 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.
| stefanlindbohm wrote:
| 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.
| jfoster wrote:
| 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.
| sylware wrote:
| 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).
| miramba wrote:
| 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.
| tempodox wrote:
| I'll believe it when I see it. I'm sure they'll find new ways to
| drag their feet.
| egberts1 wrote:
| This Web App support needs to die, until Apple finds a way to
| prevent 3rd party from digging into our personal info.
___________________________________________________________________
(page generated 2024-03-02 23:02 UTC)