Comment by macguillicuddy | Hacker News Reader

Comment by macguillicuddy | Hacker News Reader

Parent Full thread

We encountered a relatively major regression during the iOS 16.4 beta which unfortunately went live with the release version of 16.4. Requesting an 'environment-facing' camera using getUserMedia now provides the ultra-wide camera (rather than the usual standard angle lens). The workaround is unfortunately rather gnarly - having to rely on an order in a list that's not guaranteed by the spec and indeed different on Android. https://bugs.webkit.org/show_bug.cgi?id=253186

While it's fixed in webkit, the webkit team were unable to tell us if the fix would be in the shipping version of 16.4 and, despite discovering and reporting the bug before it even hit a beta, the shipping 16.4 has the bug.

I really feel for the team who are maintaining the code. It's clear they do a great job in difficult circumstances and it's several high-level policy decisions at Apple make things really challenging for them: they're unable to talk about when bugs and their fixes will (or will not) be present in release software; and Safari updates are tied to OS releases.

It's the dumbest policy, and it's not limited to WebKit: you see this in other open source projects like Swift and LLVM too. As a general policy, Apple does not allow their engineers to talk about future products. When the commit that just landed into the main branch will ship on user's devices falls under "comments on future products" and thus they won't talk about it.

When I was working on open source at Google this was also something we had to be very careful with: you don't want to make promises you can't keep. But this wasn't as strict as what Apple does, and vague estimates were allowed.

For example, here's what Chrome does: https://chromiumdash.appspot.com/schedule. All the dates are tentative and sometimes slip, but an engineer can point people to it, say "fix X made the branch cutoff for release NNN", and you can get a pretty good prediction for when X will get to what sort of devices.

Yeah, to be clear, people make jokes about Apple being unable to confirm that there will ever be another iPhone. They're funny because they're mostly true.

Well, you have to understand: the current iPhone model is a perfect pinnacle of technology, so talking about someday releasing something even better would be blasphemy until they actually manage to pull it off...

Mostly? They're definitely true.

That Chromium dashboard is amazing for planning and exactly the kind of thing we need for Safari.

Mozilla has a similar dashboard for Firefox releases and announces (tentative) release dates for the next 9-12 months:

https://whattrainisitnow.com/

https://whattrainisitnow.com/calendar/

This is the backwards 80s and 90s corporate culture of a secrecy instead of community or customer oriented. Heck, even Microsoft is getting this right nowadays. Apple is one of the most developer hostile companies still standing.

But I guess they will stand until there is external pressure to force them to change e.g. in the form of regulation allowing to bundle alternative web browser engines and not giving preferential private APIs.

Microsoft is only ‘getting it’ because they are losing ground and they know it. I figure that’s what you mean by external pressure.

Even a worm can learn to navigate thru a maze if you give it enough electric shocks

We've had a similar constraint issue on getUserMedia where it will return the lowest possible resolution for video by default instead of something more pedestrian. Setting exact constraints never seems to work correctly either. Ideal gets closer.

It took us over a year to realize this was the root cause for 2D barcode scanning issues - we had an information-theoretic failure mode due to the low resolution.

> and Safari updates are tied to OS releases.

Safari is the last non-evergreen browser. As long as Apple insists on this policy it doesn't matter how good a job the WebKit team are doing; they're still hamstrung by the outdated release policy Apple enforces.

Luckily, soon Apple will be forced to allow alternative browsers. At that point, I hope Apple will spend some of its trillions on actually improving Safari, in order for it to stay relevant and competitive.

> actually improving Safari, in order for it to stay relevant and competitive

Safari seems to be the last bulwark against a Chrome-only web driven by features of the week.

Full Chrome/Chromium on iOS could very well end that, and I'm not thrilled at the prospect.

Personally I appreciate Safari's resistance to constant featurism in general, and conservative approach to features that are likely to compromise power usage or privacy. I have little desire for web apps to reach complete feature parity with native apps, or to have complete access to all hardware and OS features. Many developers may hate it and want to usher us into Google's PWA future, but I'm absolutely fine where things are right now. And I certainly don't want to have to use Chrome/Chromium for everything.

Lastly, as a developer, I don't like building on quicksand. And yet that's often what it feels like using web/JavaScript frameworks and browsers that change from week to week.

Nonetheless, OP's recommendation that Apple note which versions of Safari a certain bug is fixed in seems like a very good idea that should be adopted.

Frankly, I don’t think all that matters. Safari doesn’t keep up with web standards. It’s not like they’re failing to be competitive as with browser features — that’s a different question. As long as a web standard is specified, and Safari doesn’t implement it, it’s not doing their one job as a browser engine.

The pace of change in the frameworks world is completely independent of web and browser features. And the web is very backwards compatible — so new web platform features don’t rot the foundations of any existing web apps, assuming they use specified features.

> Safari doesn’t keep up with web standards (emphasis yours)

Just pause for a moment and think who's proposing these standards. The same groups pushing for browser "featurism" sit on the committees that define these "standards". It's not meaningful to say that they're different things when they're all part of the same effort in different disguises.

Fyi I don't think this issue is limited to Safari, I've seen the exact same problem in some third-party apps which, as far as I can tell, look and feel native.

Do you mean third-party apps on iOS? All web-based iOS apps are powered by Webkit/Safari so it makes sense that they all share the same bugs.

I mean third-party apps that are native, not web wrappers such as Cordova etc.

Reply on news.ycombinator.com