Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's intentional crippling of Mobile Safari

pwa.gripe

Post reply on HN
Print view View original

121–130 of 343 posts

Re: Apple's intentional crippling of Mobile Safari

#121

Post by mort96 »

leptons wrote: post #103
mort96 wrote: post #81

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. Going through some of the list from the top: * Shortcuts in the manifest: This seems to be standard. Would be nice if mobile Safari supported it. * Protocol Handling: This is non-standard.…

>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.…

Mobile safari is arguably the only thing standing between Google and total browser dominance. It's the reason why Google "only" has roughly 75% of the mobile browser market even though it has a 90% market share in desktop. I'm principally against the idea that Apple can prevent users from installing the software they want on their own devices, but we can't deny that it's better for the health of the web.

Anyway, if you want to exclusively argue "Users should be able to install the browser they want", that's fine. But you're not; both your comment and the pwa.gripe page brings up how Apple is "crippling" their own web browser. Since you use the same wording as pwa.gripe, I assume you too view the lack of non-standard Google-only features as "crippling mobile Safari". I disagree.

Re: Apple's intentional crippling of Mobile Safari

#122

Post by mvanbaak »

notatoad wrote: post #39
hx8 wrote: post #2

I'm writing this in Safari now, I'm a huge fan. There are several "features" that I actively dislike and disable in other browsers. I wonder if not being implemented in mobile safari is preventing them from being required in some webpages. * Vibration * Background Sync * Bluetooth * NFC * Notifications * Web Push

I can understand notifications and vibration. But why not Bluetooth or NFC? I can’t imagine any way those could be annoyances, or even why websites would want them outside of some extremely specialized applications.

BT and (although very very limited) NFC can be used for tracking and location detection.

Re: Apple's intentional crippling of Mobile Safari

#123

Post by rejhgadellaa »

troupo wrote: post #106
FormularSumo wrote: post #97

It's a cool page, although somewhat limited in scope. If you want a more complete picture of all the web progress Apple is holding back, not "just" PWA and more advanced capabilities, this is probably a better site for comparison: https://ios404.com It includes dates for when these things were first shipped, explanations for that they do, and what kind of standards (or not) they are.

Note how it doesn't list which of these are Chrome-only non-standard APIs that Firefox doesn't support either. Oh wait. You don't care about small details like that. None of these Chrome shilling websites do.

First of all, features can be a standard without (full) FF and/or Safari support.

Second, Safari has a monopoly on iOS and controls what other browsers can support on the platform (that also usually means "less than Safari", because SF gets to support things first). They are in a unique position to hold back the entire web, even on other platforms. They're holding the standards hostage by not allowing the market to decide which features are important to them (and put pressure on Safari and FF to implement them)

Re: Apple's intentional crippling of Mobile Safari

#124

Post by mort96 »

JimDabell wrote: post #120
leptons wrote: post #105

Earlier quoted context omitted.

Which browser engine are you getting on iOS when you install Firefox? If you answered Firefox, you are WRONG. You get Safari , because Apple forces all browsers on iOS to use their own crippled browser engine. Apple also is part of the W3C board that gets to decide which APIs get to become standards, so they also influence what other browser makers do. This would be a non-issue if Apple didn't force all browsers on i…

No, you get Firefox. There is much more to a web browser than just its rendering engine. When you install Firefox on iOS, you get Firefox. It uses the WebKit rendering engine, but it’s still the Firefox browser. To be frank, it’s pretty insulting and dismissive to all the people putting huge amounts of work into building browsers only to for you go around telling people that all their work is really just a mirage.

You may wish to re-read the comment you respond to. To quote:

> Which browser engine are you getting on iOS when you install Firefox?

Emphasis mine.

Re: Apple's intentional crippling of Mobile Safari

#125

Post by JimDabell »

leptons wrote: post #119
JimDabell wrote: post #84

Earlier quoted context omitted.

Here’s what Mozilla has to say about Web NFC, for example: > We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for…

>The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea. Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards. They have an interest to forbid Web Bluetooth and NFC from becoming standards, because they profit…

> Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards.

They are not. You have this almost entirely backwards. To become a standard, you only need two independent interoperable implementations. This means Apple cannot block something from becoming a standard. The only thing Google needs to do is convince anybody else to implement their proposals. So far they have managed to convince precisely zero other rendering engines to do so.

> I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them".

All of these are Chromium / Blink users, not independent implementations.

Re: Apple's intentional crippling of Mobile Safari

#126

Post by cyberrock »

nerdjon wrote: post #53

I am curious why Safari in particular is getting a lot of the hate here when firefox supports even less of the features which leads me to believe that the reason many of these features have not been accepted is because they have not been accepted by the larger ecosystem and is just google pushing their own things as standard (Feels like IE days in many ways). That being said, I am not sure why I would actually want m…

Some of Mozilla's positions are based on Apple's, such as the refusal to implement Web NFC [0].

Since Webkit has been the only engine allowed on iOS, ultimately this is a disagreement on app distribution. I can see Apple and Mozilla's argument regarding Web NFC, but I also don't want to write a whole app so my friends and I can play around with NFC tags. I find it irresistible to draw comparisons to the new Android situation regarding non-Play Store apps. If there was a developer registration list for websites (that was better than DNS registrar records and TLS certificates), would Apple and Mozilla find that acceptable? After all, I need to give my real name and payment details to Apple just to write an app.

But for good measure I will add one for Mozilla too. Firefox Android still doesn't support the Web Codecs API [1], so I need to use the "jpeg" codec on Selkies remote desktop sites, which I assume is rather poor for my bandwidth and battery.

[0] https://github.com/mozilla/standards-positions/issues/238 [1] https://caniuse.com/webcodecs

Re: Apple's intentional crippling of Mobile Safari

#127

Post by rejhgadellaa »

slashdave wrote: post #95
agust wrote: post #25

Worth noting that Apple doesn't just cripple iOS Safari, it cripples all iOS browsers because it also forces them to use WebKit, the crippled browser engine underneath Safari. It would be fine if they just made Safari bad, that's their choice. But they don't stop there: they make the entire web bad on iOS purposely to promote the native apps they can tax.

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)

Re: Apple's intentional crippling of Mobile Safari

#128

Post by Arainach »

JimDabell wrote: post #120
leptons wrote: post #105

Earlier quoted context omitted.

Which browser engine are you getting on iOS when you install Firefox? If you answered Firefox, you are WRONG. You get Safari , because Apple forces all browsers on iOS to use their own crippled browser engine. Apple also is part of the W3C board that gets to decide which APIs get to become standards, so they also influence what other browser makers do. This would be a non-issue if Apple didn't force all browsers on i…

No, you get Firefox. There is much more to a web browser than just its rendering engine. When you install Firefox on iOS, you get Firefox. It uses the WebKit rendering engine, but it’s still the Firefox browser. To be frank, it’s pretty insulting and dismissive to all the people putting huge amounts of work into building browsers only to for you go around telling people that all their work is really just a mirage.

You are a responding to a comment asking what browser engine you get, and the answer is Safari/Webkit.

Re: Apple's intentional crippling of Mobile Safari

#129

Post by leptons »

nerdjon wrote: post #99
rejhgadellaa wrote: post #89

Earlier quoted context omitted.

The difference is that, on iOS, you can't switch to a different browser that does support these features. Om very other OS you can. A web app could ask you to use a different browser (not ideal, but if the web app requires a specific API, it's not an unreasonable). Safari is in a very special position because it controls what the web can do on iOS (all browsers on iOS have to use Apple's WebKit engine, they can't add…

True, but putting aside that limitation on iOS for a moment. The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda. Which is where whether or not any non chromium browser supports any of these on any platform. Which many of these features they don't. That completely changes the conversation here, from Apple purposefully igno…

>The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.

Apple is on the W3C board that gets to decide what APIs become standards, so Apple is definitely pushing their own agenda on the W3C.

So you can't really complain that Google is pushing their own agenda with these APIs when Apple is the one refusing to make them a standard. In this case, Apple is the one doing shady shit by holding back things like web bluetooth for no good reason. No, "security" is not a reason, this API has been in use on other platforms for a very long time with no real security issues.

There are lots of other standard APIs that have been implemented, but Apple refused to let the ones that eat into their app store go forward.

>we heavily criticized IE for exactly this and yet we celebrate Chrome for it?

I remember when IE implemented XMLHTTPRequest, and it did a lot of good for the web.

I also remember when Microsoft got an antitrust case for simply bundling IE with Windows, yet Apple seems to get a pass for forbidding all other browser engines on iOS? Well, fortunately Apple has its own antitrust case in the DOJ now for its own abusive business tactics.

https://www.justice.gov/archives/opa/media/1344546/dl?inline

Re: Apple's intentional crippling of Mobile Safari

#130

Post by rejhgadellaa »

otterley wrote: post #82

For those of you who believe support for PWAs is critically important: in what way does it impact you? What kind of solution are you providing (or, put another way, what problem are you solving) for customers, and why would a PWA app be better than a native one for them ? (As opposed to, say, convenience for you .)

Businesses tend to relay costs onto their customers (someone has to pay the bills).

- The app store tax

- The extra work of maintaining at least 2 separate apps (iOS, Android, optionally(?) desktop web app)

- Dealing with app store rules

Some of these are not just costs. I have experience with native apps that have to make things worse for users (compared to the web app) or risk getting booted off the app store.

Post reply on HN