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

261–270 of 343 posts

Re: Apple's intentional crippling of Mobile Safari

#261

Post by troupo »

rejhgadellaa wrote: post #258
troupo wrote: post #192

Earlier quoted context omitted.

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

> A feature that is shipped in a single browser is just that: that browser's non-interoperable feature. AFAIK, the popover and/or anchor positioning APIs was standards before it shipped in more than one browser. (I will say that all three(?) of them agreed to build it) > "it's a napkin scribble, not on any standards track". Chromium/Blink have a process, and it's quite rigorous (precisely because they understand that…

> I will say that all three(?) of them agreed to build it

This is the key sentence

> Chromium/Blink have a process, and it's quite rigorous

It's Chrome's process, and Chrome's deadlines.

> they have a responsibility to make sure it's good)

Strange then that they routinely don't wait for and ignore any and all input from other browser vendors and ship their own APIs without any consensus or agreement because "their rigorous process is good" or something.

E.g. almost every single API marked as "experimental" on MDN docs [1] is already shipped in Chrome despite most specs being "not on any standards track", "has multiple issues", "no consensus and API is in flux" or "it is provided for discussion only and may change at any moment."

[1] https://developer.mozilla.org/en-US/docs/Web/API

Re: Apple's intentional crippling of Mobile Safari

#262

Post by troupo »

rrix2 wrote: post #242
cosmic_cheese wrote: post #223

Earlier quoted context omitted.

> 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. Exactly. Test and develop against Firefox and/or Safari first and Chrome afterwards. If it’s not a true web standard and isn’t widely implemented, don’t use it. The web worked fine for decades without smart fridge integra…

It's not easy, though. Most of my day job is spent trying to get html interactives on an e-learning platform to work reliably with iOS's ridiculous nonstandard interaction rules around when media is allowed to play. It's worse than working with the 20 year old jsp+servlet system that serves the interactives and business logic. no other browser behaves like iOS safari and to debug and develop against it you need an io…

> with iOS's ridiculous nonstandard interaction rules around when media is allowed to play.

Are there any standard interaction rules on when media is allowed to play? I thought everyone implements it differently based on their own ideas of security and user engagement

Re: Apple's intentional crippling of Mobile Safari

#263

Post by troupo »

rejhgadellaa wrote: post #153
mort96 wrote: post #147

Earlier quoted context omitted.

The argument which has been provided so far about why Safari is crippled is that it does not implement non-standard Chromium-only features. There are other problems with Safari, but they are not found in the page we are discussing.

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

Re: Apple's intentional crippling of Mobile Safari

#264

Post by archerx »

raw_anon_1111 wrote: post #246
archerx wrote: post #244

Earlier quoted context omitted.

Why isn’t it the best way to go? I’m not a fan of those web game engines so I made my own. I have various avenues of monitization; sponsored ads and letting players buy cosmetic items. I have yet to test it on android because my priorities are making it work on desktop and iOS first and then android after. Why? because of my past experiences with making games.

Monetization? But does making your own engine “make the beer taste better”? Does it lead to a better experience for the users? Does it give you an advantage in the market? You really don’t think you need to consider the hardware capabilities of the average Android phone? Hint: Facebook rewrite their apps years ago to not use web based technology because performance was horrible on the average Android phone.

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 which is honestly just embarrassing all things considered.

Re: Apple's intentional crippling of Mobile Safari

#265

Post by raw_anon_1111 »

archerx wrote: post #264
raw_anon_1111 wrote: post #246

Earlier quoted context omitted.

Monetization? But does making your own engine “make the beer taste better”? Does it lead to a better experience for the users? Does it give you an advantage in the market? You really don’t think you need to consider the hardware capabilities of the average Android phone? Hint: Facebook rewrite their apps years ago to not use web based technology because performance was horrible on the average Android phone.

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 entire web browser.

Re: Apple's intentional crippling of Mobile Safari

#266

Post by raw_anon_1111 »

leptons wrote: post #257
raw_anon_1111 wrote: post #227

Earlier quoted context omitted.

A web app has never in history been as performant as a native app.

Not everything needs to be at the highest high of "performant", and you're ridiculous to use that as a gotcha. I told you, this pointless internet interaction is over . You are not here to argue in good faith, so take it somewhere else.

So yet another shitty bloated web app…

Re: Apple's intentional crippling of Mobile Safari

#267

Post by jen20 »

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

As an iOS user, I’m quite happy you have to jump through these hoops instead of being able to force me to use a Google product.

Re: Apple's intentional crippling of Mobile Safari

#268

Post by cromka »

bspinner wrote: post #189
pilif wrote: 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.

Is any popular browser actually available with non-WebKit browser in EU? So far I wasn't able to confirm this.

Re: Apple's intentional crippling of Mobile Safari

#269

Post by Levitating »

boomskats wrote: post #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 p…

> PWAs are great. They were literally Steve Jobs' original vision for the iPhone.

Was it? I think one of IOSs strength is its operating system and proper native apps. PWAs are inaccessible, bloated, slow and awkward to use.

Re: Apple's intentional crippling of Mobile Safari

#270

Post by Levitating »

rejhgadellaa wrote: post #130
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.

Native app development needs work on all major platforms. But in the long term I don't think web apps are the way out.
Post reply on HN