Live data from Hacker News

Apple's intentional crippling of Mobile Safari

pwa.gripe

191–200 of 343 posts

Re: Apple's intentional crippling of Mobile Safari

#191
post #106

Earlier quoted context omitted.

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.

Hi! Creator here (of iOS404) - you can filter level of standard and compare to FF Android (or compare to Safari Desktop, or any mix) instead if you'd like.

It's called iOS404, not "FF" or "Chrome" and pushes the narrative that iOS is bad, and missing features.

There are 34 features listed (IIRC it did contain a bunch of Chrome-only crap once upon the time, hence my harsh reaction). All of them enabled by default. If we limit this only to actual, you know, standards, and not "scribbled on a napkin, awaits review", we get a grand total of 9 (yes, nine). And even there many are not "not implemented" but "missing some features (sometimes big, sometimes small and irrelevant)".

Re: Apple's intentional crippling of Mobile Safari

#192
post #106

Earlier quoted context omitted.

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

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

No. No they can't. A feature that is shipped in a single browser is just that: that browser's non-interoperable feature.

We literally lived through this with Internet Explorer.

The only reason the web is thriving now is because browser vendors agreed not to push this shit any longer. Well, until Google decided that whatever it does is the web, and until people who are not even paid by Google started unironically pushing the idea of "whatever Google spits out is the essential web standard now".

I mean, the status of multiple APIs on any of those "Safari is bad PWA is good" sites are literally in the "it's a napkin scribble, not on any standards track".

> 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)

Who puts the pressure on FF to not implement Chrome-only non-standard APIs? Even desktop Firefox doesn't want to touch that pile of garbage with a 10-yard stick. And yeah, let's not pretend that Chrome somehow got to where it is by "market deciding".

Re: Apple's intentional crippling of Mobile Safari

#193
post #157

Earlier quoted context omitted.

> A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact: 1. Google often doesn't bother even with a spec. Or it creates a semblance of a spec, throws it up on a googler's Github account, ships it and advertises it as "emergin standard" on web.dev I mean, the status of many (if not…

> Google often doesn't bother even with a spec. I'm sorry, but that doesn't seem to be right. They have a process: https://www.chromium.org/blink/launching-features/ > I wouldn't really quote Alex Russel on anything related to standards I disagree :) ...but it's getting late here, have to shut down :)

> I'm sorry, but that doesn't seem to be right. They have a process:

Yes, they do. It's their process, and their timelines. Many features on the page we're discussing are literally "drew on a napkin, not part of any standards process at all, shipped in Chrome"

Re: Apple's intentional crippling of Mobile Safari

#194

Earlier quoted context omitted.

Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well? We really need to stop putting google on a pedestal as if they are truelly on the side of an open web, like every company they are looking out for their own interests. Which is fine, they are allowed to do this. That doesn't change that many of these are in fact not a…

>Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well? How is Web Bluetooth an evil agenda of Google?? It's making web browsers more capable. It's not some evil conspiracy to enrich Google. If Apple wants to let the W3C move forward in making it a standard, then all browsers would benefit, and all users that would like t…

> How is Web Bluetooth an evil agenda of Google??

Never said it was, notice how in the thing you quoted I said "Topics API"? That is extremely evil and was only introduced to benefit a single company, Google.

I never made a claim that every single thing on this list that safari does not support is a negative.

> IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0".

Fantastic, that is an example of things working as they are supposed to work.

However IE also introduced things that were not made standard just as equally we celebrated that those things failed.

> If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.

Obviously that is true or the companies would not be involved in W3C. But that does not mean that every idea they introduce is necessary in a browser and deserves to be a standard feature. Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.

If everyone is in agreement instead of it benefiting a single company.

> The only one that benefits from not allowing it to become a standard is Apple

I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop. Your argument does not support why Mozilla has not implemented this feature. Which again, makes the "Apple bad" spin on this not as cut and dry.

Re: Apple's intentional crippling of Mobile Safari

#195
post #157

Earlier quoted context omitted.

> A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact: 1. Google often doesn't bother even with a spec. Or it creates a semblance of a spec, throws it up on a googler's Github account, ships it and advertises it as "emergin standard" on web.dev I mean, the status of many (if not…

1. That's just your skewed take. 2. That's just your skewed take. 3. So what, bugs can be fixed. It's nowhere near as abusive as what Apple does by forcing Safari on every iOS browser. 4. You think the "browser wars" are over? Apple's actions clearly indicate the war is on, and they've selected the nuclear option of forbidding any other browser on their platform. >Internet Explorer in the 2000s: shits out a bunch of…

> That's just your skewed take.

When you deliberately ignore what Google is doing, every view that is not praising Google's take over of the web is skewed.

> So what, bugs can be fixed.

No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.

> Did people "boo" XMLHTTPRequest? Because it actually revolutionized the web, and people cheered it.

And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX

Re: Apple's intentional crippling of Mobile Safari

#196
post #191

Earlier quoted context omitted.

Hi! Creator here (of iOS404) - you can filter level of standard and compare to FF Android (or compare to Safari Desktop, or any mix) instead if you'd like.

It's called iOS 404, not "FF" or "Chrome" and pushes the narrative that iOS is bad, and missing features. There are 34 features listed (IIRC it did contain a bunch of Chrome-only crap once upon the time, hence my harsh reaction). All of them enabled by default. If we limit this only to actual, you know, standards, and not "scribbled on a napkin, awaits review", we get a grand total of 9 (yes, nine ). And even there m…

Yep - the site has a point of view but rooted in real data that you can filter as you'd like.

I've had real-world experiences where I develop something that works on my Mac and my Pixel phone but cannot work on iOS WebKit (basically kaputt on iPhones). It inspired the creation of the site - specifically not being able to allow users to have Audio at anything but 100% seemed extremely weird.

I'm not offended by sites that also point out issues with a slant against Google. Ie: killedbygoogle - I think these things are great, fun, and interesting.

Re: Apple's intentional crippling of Mobile Safari

#197
post #61

Earlier quoted context omitted.

Firefox is not in a position where it is the only browser allowed to run on a platform. On iOS, you’re either doing a native app, sharing 30% of your income with Apple, or you’re restricted to Safari’s feature set. No browser in iOS can use anything but WebKit

> No browser in iOS can use anything but WebKit Your statement is true only outside of EU countries.

Specifically due to regulations that Apple incited.

Re: Apple's intentional crippling of Mobile Safari

#198

Earlier quoted context omitted.

What outcomes are worse for users that arise out of you offering native apps?

I thought this was obvious, but higher costs for building and maintaining an app (vs a web app) means higher prices for users. I think people would love to pay less, and would hate to pay more.

How much is the incremental cost per user?

Re: Apple's intentional crippling of Mobile Safari

#199
This isn't about browsers, it's about Apple spending the last decade blocking PWAs on their platform by intentionally breaking something new with every new OS release, thus forcing people to build and ship bloated pointless 50meg webview packages through their aPp StOrE every time they update the width of their sidebar.

PWAs are great. They were literally Steve Jobs' original vision for the iPhone. I don't know why people are arguing about Firefox or the individual features - that's not the point, they're not the ones that matter. It's the decade of sabotage.

Re: Apple's intentional crippling of Mobile Safari

#200
post #195

Earlier quoted context omitted.

1. That's just your skewed take. 2. That's just your skewed take. 3. So what, bugs can be fixed. It's nowhere near as abusive as what Apple does by forcing Safari on every iOS browser. 4. You think the "browser wars" are over? Apple's actions clearly indicate the war is on, and they've selected the nuclear option of forbidding any other browser on their platform. >Internet Explorer in the 2000s: shits out a bunch of…

> That's just your skewed take. When you deliberately ignore what Google is doing, every view that is not praising Google's take over of the web is skewed. > So what, bugs can be fixed. No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform. > Did people "boo" XMLHTTPRequest? Because it actually revolutionized th…

>every view that is not praising Google's take over of the web is skewed

I am not praising Google. I'm simply pointing out that Apple is using abusive business tactics to prevent any competition. It's antitrust territory, and the DOJ agrees. I don't care which browser implements the APIs I need to access, so long as one of them does.

>No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.

Just more skewed nonsense. This can and have been fixed on the web. I've had to reimplement countless APIs for all kinds of services. There are new APIs that make old ones deprecated all the time. Maybe you should try to keep up instead of stagnate like Apple is.

>And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX

Just more bullshit from you. I'm tired of it. You aren't even attempting good faith arguments.

This pointless internet interaction is over.

Post reply on HN