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

201–210 of 343 posts

Re: Apple's intentional crippling of Mobile Safari

#201

Post by godelski »

archerx wrote: post #145
mort96 wrote: post #121

Earlier quoted context omitted.

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

You clearly haven’t tried to design anything complicated that has to run on safari iOS. Safari iOS is a massive piece of shit. I’ve been working on a web game for a while now using canvas and most of my pain comes from making it compatible with safari. So much stuff is broken on safari so you have to find work arounds. Like a simple but annoying one, CSS filters don’t work on canvas so you have to write all those fil…

As a non-web developer I'm interested if anyone can answer this question:

  If you're designing for  browser, how hard is it to make it work on  browser?
Answering with at least {Chromium,Safari,Firefox}

Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.

What I want to distinguish is the biases in being used to programming in one environment and actual ease of programming for an arbitrary browser. Regardless of what official standards are, there are "in practice" standards, what is used in practice.

What would be nefarious is if Google is promoting people to program in ways that are not compatible with other browsers, cementing its monopoly. (This may even be achieved without explicit direction. Achievable simply by Chromium devs building tools for devs but not carrying about compatibility with other browsers). After all, the web is for everyone, but just because it's open doesn't mean monopolies/oligopolies/collusion/ can't happen.

Tdlr: does developing on chromium encourage browser incompatibility?

Re: Apple's intentional crippling of Mobile Safari

#202

Post by _aavaa_ »

mort96 wrote: post #159
rejhgadellaa wrote: post #152

Earlier quoted context omitted.

> Mobile safari is arguably the only thing standing between Google and total browser dominance "Apple Is Not Defending Browser Engine Choice" https://infrequently.org/2022/06/apple-is-not-defending-brow...

You seem to be conflating my opinion of "iOS's lack of browser choice has the consequence of preventing Chromium from achieving total dominance" with some imaginary other person's opinion of "iOS's lack of browser choice is a benevolent act where good guy Apple valiantly defends the open web". I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't. (Not p…

Let Google dominate the web. If that’s a problem we can sort that out. But two wrongs don’t make a right.

Re: Apple's intentional crippling of Mobile Safari

#203

Post by xd1936 »

lachlan_gray wrote: post #96
8organicbits wrote: post #77

Earlier quoted context omitted.

Notifications struck me as odd. I aggressively disable notifications in my apps because they are often just ads or engagement focused. But as a developer, it would be cool to have a way to notify an iOS user other than building a native app and paying the iOS tax. There's a bunch of utility apps not getting built because of this limitation.

According to this, notifications are possible if you add the app to the home screen, which I didn't know. A feature more devs should use- I've been surprised how much websites behave like native apps if you just "add to homescreen" instead of downloading an official app, e.g. twitter, instagram. When you open the shortcut, it doesn't launch as a tab in safari, but appears independently in the app switcher. They are o…

This experience is exactly why PWAs could be great.

Re: Apple's intentional crippling of Mobile Safari

#204

Post by xd1936 »

strogonoff wrote: post #176
rejhgadellaa wrote: post #108

Earlier quoted context omitted.

Do you have a source link for this? I don't want to sound snarky, but this list doesn't make sense to me. Offline support has been available (and buggy, YMMV) for a long time. Web Push has been available since 16.4 (with a lot of caveats) I haven't heard anything about installation (but I may have missed something)

My source is TFA, as I stated. This is what I see in the table when I follow the link. For example, in the column for my current iOS version offline support is crossed out, and for the upcoming version it has a check mark. If the claim being made is that pwa.gripe is a bad source, I can only assure I have nothing to do with the site. If they misinform visitors about Safari’s capabilities with regard to PWAs, you shou…

The source is caniuse.com data. The build script for the page is open-source as well.

https://github.com/leoherzog/pwa.gripe

Re: Apple's intentional crippling of Mobile Safari

#205

Post by xd1936 »

shalanah wrote: post #161
troupo wrote: 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.

Amazing site. Thanks for making it.

Re: Apple's intentional crippling of Mobile Safari

#206

Post by leptons »

nerdjon wrote: post #194
leptons wrote: post #183

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

>Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.

They did not "dictate a standard". They saw a good use case for an API and made one for it (Web Bluetooth is what I'm really focused on). If the other W3C members want changes made, then they can make suggestions, and Google or someone else can implement the changes. They can even implement their own API and have a discussion about that. Then they can put their heads together and come up with a spec everyone agrees on. That is how it normally works. Nobody "dictates" as you suggest.

Apple is flat out refusing to let Web Bluetooth move forward based on "Security rEaSoNs", and they are just shutting down the entire feature set.

Where is the security risk when users have to explicitly opt-in to use the feature? I'm sorry if your grandma clicks yes to everything, but blocking my users from the entire feature because your grandma lost her mind years ago is asinine. There is no real security threat posed by Web Bluetooth and I'd love to see you argue how there is when plenty of other existing APIs already ask for permission before you can use them. Fingerprinting can be done in a lot of other ways.

But the real crux of the problem is Apple not allowing other browser engines on their iOS platform. If that changed, I wouldn't care what one company implements or blocks in the W3C.

>I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop.

I don't care at all what Firefox does or doesn't want. Neither do most people. Firefox also does not block other browser engines from running on iOS, so people are free not to use it. Unfortunately we're not free to use the browser engines we want on iOS.

Re: Apple's intentional crippling of Mobile Safari

#207

Post by xd1936 »

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.

Re: Apple's intentional crippling of Mobile Safari

#208

Post by leptons »

mort96 wrote: post #186
rejhgadellaa wrote: post #178

Earlier quoted context omitted.

> In other words, Apple has successfully prevented you from writing a web application ... by abusing their monopoly position on iOS (instead of competing). Good outcome?

From the perspective of avoiding a web that's wholly controlled by Google? Yeah, absolutely.

Letting my users have access to the Web Bluetooth API is not making Google somehow take control of the web. If Apple won't implement it, and they won't allow other browsers on their platform, that's plainly an abusive business tactic. It's far worse than what Microsoft did by simply include IE with Windows - Microsoft never forced every browser application to use Internet Explorer. Can you imagine the outrage if they did??

But somehow Apple gets a pass, and you think they're somehow saving the web? Just stop.

Apple is stifling progress in favor of profit.

Re: Apple's intentional crippling of Mobile Safari

#209

Post by xd1936 »

diebeforei485 wrote: post #137

I want location permissions for web apps installed to the home screen to be separate from Safari. I want to auto-deny websites asking me for location permissions. But I want to be able to grant location permissions to installed web apps on a case-by-case basis just like with regular apps.

Agreed. Very reasonable, very simple, and already possible on Android.
Post reply on HN