Hacker News Reader

Comment by arilotter | Hacker News Reader

Aaaand they introduced WebGL bugs that broke our product, and iPhone users will experience these bugs until we can hack a workaround in, or until Apple acknowledges a bug report (that I have to make a minimal test case for and report, and haven't narrowed down yet), patches the issue in Safari, and decides if it's important enough to release as a 15.4.1 (which they probably won't, which means I'm stuck finding a workaround) - or if it comes out in iOS 16, then a good chunk of our users will never get the fix - so I'm stuck finding a workaround, still.

The bundling of Safari versions with iOS, combined with the draconian policy of "Safari is the only legal rendering engine on iOS", bites me every day as a developer that's working on a mobile site for iDevices.

View on HN

> decides if it's important enough to release as a 15.4.1 (which they probably won't, which means I'm stuck finding a workaround) - or if it comes out in iOS 16, then a good chunk of our users will never get the fix

I know people like to complain about Safari, but:

1. It’s absolutely common to ask developers for a minimal repro case in a bug report.

2. There are four major Safari releases under 15.x.

3. Apple OS upgrades, especially iOS, are as close to total as one could imagine. The overlap between people who buy iPhones and people who go out of their way to turn off OS upgrades is really small.

I want Apple to stop tying (some) Safari releases to OS upgrades, but this honestly feels like you’re tired and it’s been a long day, and you could use a break. Take the night off. Safari will still be imperfect but improving tomorrow, even if it’s not at the pace we’d prefer.

"you're holding it wrong" said as "you're too tired". OP's tiredness has nothing at all to do with Apple's abusive policy of forcing Safari on IOS. That's the whole entire problem, not OP not getting enough sleep.

My comment did have some clarifying points, but my observation that they may be tired wasn’t a dismissal or rejection of anything, it was just empathy. I’ve come back to respond to this several times and walked away confused each time, because I sincerely recognized that dealing with broken technology takes a toll, and I was surprised by this being interpreted as less sincere. But I did re-read my comment and I see how that could be misread along with those clarifying points.

1. I absolutely agree, and will be making one to get this bug fixed. 2. All of which have different bugs :^) 3. My product's usage data disagrees. We've got plenty of users on old iOS versions - a really big chunk on iOS 14, for example.

I want Apple to stop restricting third-party browsers on iOS. MacOS Safari has the same WebGL bugs, but our game's Desktop client uses a WebView under our control & versioning that isn't Safari, and so doesn't have the bug.

If iOS had the same capabilities, I wouldn't care at all if Safari introduced bugs, since it wouldn't break our product.

This isn't the first, or second, or third time that Apple has shipped broken stuff in Safari on iOS which broke our product. I've been dealing with this for years, and it's not getting any better. I'm absolutely frustrated about this, but when I spend time honing in patches for Safari regressions & Safari just ships more regressions, it's hard not to be frustrated.

Yep I get that it’s frustrating. I realize in hindsight my comment about being tired might have come off dismissive, but I mean sincerely that I recognize this is an exhausting thing to deal with, and I hope you get the rest and whatever care you need to keep going. Take care.

You can try replying to the tweet[1] asking developers to point to specific bugs in Safari and see if it gets their attention.

[1] https://twitter.com/jensimmons/status/1491064075987873792

Here's my thread of all the problems I actively have with Safari, and I got no acknowledgement :) https://twitter.com/shmerbgo/status/1491442969370820610

15.4 broke my PWA also. Did not have these problems in 15.3.x.

Random rendering glitches/disappearing-reappearing dom elements.

Impossible to debug without Mac and no problems in any other browser.

Seriously frustrating.

Out of curiosity, what are the WebGL bugs you ran into?

I haven't made a minimal viable repro yet, but - our game renders perfectly on any iOS lower than 15.4, but on 15.4, this happens: https://cdn.discordapp.com/attachments/913446741154611250/95...

Happens on latest Safari on MacOS, too: https://cdn.discordapp.com/attachments/476502698066182179/95...

It could be an ANGLE change responsible. I know Apple's been working on the Metal rendering backend. Maybe something in that is breaking for you.

I'm not sure if the video represents what's going on perfectly, but it appears like maybe it's reading old data from an improperly cleared framebuffer or something?

We are in similar situation but it is a WASM bug for us when building with Unity. Some part of the our app no longer works on iOS.

>or until Apple acknowledges a bug report

a side question, how do you make a bug report on Safari? I've found FF and Chrome easy enough, but when I went to look for making one on Safari about a year ago I decided screw it, it seemed hard to find where to start (by googling at any rate)

https://bugs.webkit.org or https://developer.apple.com/bug-reporting/

Thanks!

I am sorry you have to go through this painful exercise. But, how would an alternative rendering engine fix this problem?

"Our product doesn't work in safari, use chrome or firefox instead"

Unfortunately, Apple have a policy that the inbuilt webkit is the only browser engine that is allowed to be used on an iOS device. The iOS Chrome, Firefox, & Edge apps are just thin wrappers around the same Safari engine included in iOS.

We all know. @ben-schaaf was answering the question "how would an alternative rendering engine fix this problem".

The web is built on the foundation I can use any browser. You are going to break the fundamental promise just to avoid working around a bug?

Sometimes browsers ship bugs of the "this API just does not work anymore" variety.

When people want to get their work done, opening another browser while the original one is being fixed (which might take a couple weeks), for certain applications, is extremely reasonable for business people just trying to get their work done.

that sounds like a good short term fix. I guess I was thinking about bigger things like stadia.google.com only working on Chrome browsers. It all seems arbitrary

> The web is built on the foundation I can use any browser.

This foundation is provided by browsers and is also broken by browsers. If safari's foundation is broken then safari is the one not fulfilling that fundamental promise, not the websites now broken. So yes, don't use a browser if it doesn't work.

I think this is a pretty harsh judgement for a webGL bug.

Apple have already intentionally broken that promise by refusing to implement parts of the HTML standard.

Which parts of HTML standard did they refuse to implement?

"Best viewed in IE" was the norm for years and years, supporting only the major browsers has pretty much always been the case.

Before Opera gave up and became another Chrome reskin, there were plenty of sites that didn't work for me until I set the user agent to match another browser.

Those WebGL bugs might not be present in other browser engines like Gecko or Blink.

Webkit would have to compete with other engines to retain its market share rather than abuse its monopoly power.

Their monopoly power is the only obstacle to the Web developers updating their CVs as ChromeOS developer.

Our app uses an embedded WebView. An alternative rendering engine would mean we could pin a specific rendering engine version in our app, and only update it for everyone after we work out any kinks with a new version. The current policies mean that we have zero control over Apple shipping new bugs in under our users' feet.

Reply on news.ycombinator.com