5 ms·

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

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

saagarjha 4y ago
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.
- miohtama 4y ago
  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.
  - cjbgkagh 4y ago
    Microsoft is only ‘getting it’ because they are losing ground and they know it. I figure that’s what you mean by external pressure.
    - miohtama 4y ago
      Even a worm can learn to navigate thru a maze if you give it enough electric shocks
- jefftk 4y ago
  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 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.
  - AshleysBrain 4y ago
    That Chromium dashboard is amazing for planning and exactly the kind of thing we need for Safari.
    - cpeterso 4y ago
      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/ https://whattrainisitnow.com/calendar/ https://whattrainisitnow.com/calendar/
  - saagarjha 4y ago
    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.
    - hnfong 4y ago
      Mostly? They're definitely true.
    - rob74 4y ago
      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...
bob1029 4y ago
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.
Etheryte 4y ago
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.
- vially 4y ago
  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.
  - Etheryte 4y ago
    I mean third-party apps that are native, not web wrappers such as Cordova etc.
depressedpanda 4y ago
> 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.
- musicale 4y ago
  > 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.
  - noahtallen 4y ago
    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.

saagarjha 4y ago

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.

miohtama 4y ago
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.
- cjbgkagh 4y ago
  Microsoft is only ‘getting it’ because they are losing ground and they know it. I figure that’s what you mean by external pressure.
  - miohtama 4y ago
    Even a worm can learn to navigate thru a maze if you give it enough electric shocks
jefftk 4y ago
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 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.
- AshleysBrain 4y ago
  That Chromium dashboard is amazing for planning and exactly the kind of thing we need for Safari.
  - cpeterso 4y ago
    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/ https://whattrainisitnow.com/calendar/ https://whattrainisitnow.com/calendar/
- saagarjha 4y ago
  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.
  - hnfong 4y ago
    Mostly? They're definitely true.
  - rob74 4y ago
    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...

bob1029 4y ago

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.

Etheryte 4y ago

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.

vially 4y ago
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.
- Etheryte 4y ago
  I mean third-party apps that are native, not web wrappers such as Cordova etc.

depressedpanda 4y ago

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

musicale 4y ago
> 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.
- noahtallen 4y ago
  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.