Apple's intentional crippling of Mobile Safari • Hacker News Board

Re: Apple's intentional crippling of Mobile Safari

#331

Post by leptons » Tue, Mar 24, 2026, 3:48 PM UTC

ymolodtsov wrote: post #271

leptons wrote: post #103

Earlier quoted context omitted.

>Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous. You missed the point completely. Apple >forbids any browser engine on iOS other than their own Safari. So you can't just install Chrome on iOS, because when you do you get Safari instead.…

You can still build a PWA and get most of the benefits (I use a few PWAs on my iPhone daily). Or you can package it through Expo and rely on the Reader app exception without letting users sign up on iOS (although the rules around that are changing and you might be able to). I get the gist of the article but what specific features do you need to let people just use your app as a PWA on iOS? Do you need access to the N…

I need web bluetooth to give users the full experience. They can use most of my platform currently on Safari, but not the really cool stuff that web bluetooth enables.

Re: Apple's intentional crippling of Mobile Safari

#332

Post by slashdave » Tue, Mar 24, 2026, 11:09 PM UTC

rejhgadellaa wrote: post #127

slashdave wrote: post #95

Earlier quoted context omitted.

This is clearly for reasons of security. I don't think Apple is terribly interested in market share for Safari. What they are interested is preserving their competitive advantage in privacy.

> I don't think Apple is terribly interested in market share for Safari Google pays Apple $20B a year because of the market share Safari has on iOS. I'd call that "interest" That's 10% of their turnover (and likely mostly pure profit, as they seem to spend a fraction of that on Safari)

Try again. Anyone can write a browser that uses the existing web engine and connect it to any search engine they want. Make it popular enough, and they can made a deal with Google.

Having Safari is a default browser is another (valid) issue, but that is a separate concern from the web engine.

Re: Apple's intentional crippling of Mobile Safari

#333

Post by slashdave » Tue, Mar 24, 2026, 11:11 PM UTC

hasanhaja wrote: post #312

slashdave wrote: post #95

Earlier quoted context omitted.

This is clearly for reasons of security. I don't think Apple is terribly interested in market share for Safari. What they are interested is preserving their competitive advantage in privacy.

If it's about security and privacy, why push more people away from the Web to native apps that they know is less secure [1][2]? > WebKit’s sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps. [1] https://assets.publishing.service.gov.uk/media/62277271d3bf7... [2] https://open-web-advocacy.org/apple-dma-review

Native iOS apps are sandboxed and even more secure. The reason the web engine is tied down is because web engines are insecure by nature. And now you want Apple to allow anyone to write one?

Re: Apple's intentional crippling of Mobile Safari

#334

Post by shuckles » Wed, Mar 25, 2026, 3:58 PM UTC

hasanhaja wrote: post #307

SllX wrote: post #247

Earlier quoted context omitted.

Because it’s essentially propaganda. By conflating “Not Implementing something Google did” with “Intentionally Crippling”, they hope to pressure Apple by through either the general public (the PR game) or through Government mandates (the lobbying game). This has been going for at least as long as Blink was forked off WebKit. And why Apple? Because Apple’s the only other browser giant, and they do have motivation to n…

They don't need to implement it though. They just need to unban browser vendors from shipping their own engines.

Browser vendors have been able to ship their own engines in the EU for almost 2 years now. What great benefit to consumers has that enabled?

Re: Apple's intentional crippling of Mobile Safari

#335

Post by shuckles » Wed, Mar 25, 2026, 4:02 PM UTC

xd1936 wrote: post #207

pjmlp wrote: post #21

The advocates of ChromeOS Platform keep pushing their agenda. Chrome APIs and Electron crap, and then everyone complains about Microsoft.

Author here. I have no affiliation with Chrome, and use Zen and Firefox Mobile pretty much exclusively. I recently made an ESP32 hardware side project that I can configure entirely in the web browser via Web Bluetooth, got hyped, then immediately sad that my page was never going to work on iOS / iPad OS. So I threw together this webpage from caniuse.com data.

No average person cares about your side project, and most people prefer Apple’s product decisions over the ones you’d like them to make. Based on your history with technology, you are a Windows developer who would like to distribute apps on Apple’s platform without learning about what makes for a great app on that platform.

Re: Apple's intentional crippling of Mobile Safari

#336

Post by shuckles » Wed, Mar 25, 2026, 4:03 PM UTC

xd1936 wrote: post #211

raw_anon_1111 wrote: post #113

Yes I want more shitty web apps. Also you can’t imagine how much I love cross platform Electron apps. I have no desire for random websites to have that much access to my phone.

People like you could turn off these features and continue installing and updating native binaries for the Starbucks app or random hardware companion apps all you want. I'd like first-class PWAs please.

Average people don’t want to spend their lives managing permissions. You could go ahead and use Android or ChromeOS.

Re: Apple's intentional crippling of Mobile Safari

#337

Post by archerx » Thu, Mar 26, 2026, 2:03 PM UTC

raw_anon_1111 wrote: post #265

archerx wrote: post #264

Earlier quoted context omitted.

Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game. I will eventually test it on android but I don’t see why it would not work with out any issues. I wouldn’t use Facebook as a reference, I have an inside joke that they have the worst programmers. They managed to make a site that shows text and images make my computers fans spin wh…

You really don’t see how inefficient it is running a game on a web browser compared to a game engine running native code for the platform? And you think you are going to write a better performing game engine in a web browser? > Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game. Everything is there to serve your game except the ent…

I don’t know what you’re on about, my game runs at 60fps while using 10% of the cpu and some GPU.

Re: Apple's intentional crippling of Mobile Safari

#338

Post by rejhgadellaa » Sat, Mar 28, 2026, 7:42 AM UTC

troupo wrote: post #263

rejhgadellaa wrote: post #153

Earlier quoted context omitted.

I compiled a "short" list of why amd how Safari is crippled. Not entirely on topic for the post, but seems appropriate as a reply on this particular comment ;) https://webventures.rejh.nl/blog/2024/history-of-safari-show...

This article is quite literally the only one that actually discusses actual Safari problems. And even this article falls prey to "failures in web platform tests" which are a very poor indicator. E.g. Safari passing all accessibility tests is much more important than Safari failing most accelerometer tests that only Chrome passes (because this is Chrome-only API).

The WPT graph shows failures for tests that fail in only one browser. So the accelerometer tests, for example, would need to pass in both Blink and Gecko for it to count as a failure on Safari's part.

Re: Apple's intentional crippling of Mobile Safari

#339

Post by rejhgadellaa » Sat, Mar 28, 2026, 7:54 AM UTC

troupo wrote: post #260

rejhgadellaa wrote: post #252

Earlier quoted context omitted.

> business hires three teams? Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile. > they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't wo…

> Yes. > If your app doesn't work for the wealthiest 50% of users, why go that route? Why doesn't business hire two teams? One for the amazing native-like PWA, and one for iOS? > Making a desktop web app work on mobile, just for Android, is a lot of work. More work than hiring a separate Android team? More work than hiring a team to create a PWA which we've heard continuously for the past 10 years is amazingly easy a…

>> If your app doesn't work for the wealthiest 50% of users, why go that route?

> Why doesn't business hire two teams? One for the amazing native-like PWA, and one for iOS?

You quote me, but missed the exact part where I already answered that question (I presume by accident ;)), so I'll just repeat myself:

> Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile.

For background, this piece by Alex Russell is worth reading:

Platform Adjacency Theory

https://infrequently.org/2020/06/platform-adjacency-theory/

Re: Apple's intentional crippling of Mobile Safari

#340

Post by rejhgadellaa » Sat, Mar 28, 2026, 8:11 AM UTC

otterley wrote: post #300

rejhgadellaa wrote: post #254

Earlier quoted context omitted.

Building the same app for iOS, Android and desktop: up to 2-5 times the costs (for businesses, how they cover those costs depends) App tax: 15-30%, which can drive the price for consumers up by up to 44% https://open-web-advocacy.org/walled-gardens-report/#negativ...

What I’m looking for is an answer from you as it relates to your specific business, not speculation from an advocacy org that can gin up any hypothetical numbers they want. I asked in the start of the thread: how does it impact you , or your customers?

Right. So I don't know the costs of the hoops we need to jump through for our app to be granted a place on the app store. I'm not the guy who does the spreadsheets :). I do know that we've spent considerable time to make changes to pass app store review.

For example, our platform requires a subscription, but we can't link to the page where you subscribe anywhere. That means that if our FAQ page links to the subscribe page, and we have a link to the FAQ anywhere, we have to block that from happening. This isn't just extra work (to prevent users from ending up on that subscription page), it actually prevents us from offering users a way to subscribe or even change their subscription from within the app. This directly hurts our business model (subscriptions) and UX (users have to change their subscription by manually visiting our site in a browser).

All of this work means we either have to charge the user extra money (increased costs for consumers) or do less with the money we have (decreased value for the consumers).

I know this doesn't fully answer your question, but I hope it sheds a bit of light on what these extra costs are and how consumers end up paying for it.