4 ms·

A more relaxed solution to the zip issue would be simply to patch zip.js to not use the Compression Streams API in Safari. After 16.4 came out you could check i

A more relaxed solution to the zip issue would be simply to patch zip.js to not use the Compression Streams API in Safari. After 16.4 came out you could check if it worked, and remove the patch at your own pace. Re: The release timing/schedule problem, I agree that more transparency on the release date would be nice, but since it is tied to an entire OS release, they probably can't do that. The way to go is to keep an eye out for the beta release cycle of iOS. They will typically release 5 or more betas, and then one or more RCs, and then a GM, and then will start rolling out the update to users. There are several websites like Mac Rumors, Apple Insider, 9to5Mac where you can get a good temperature of where in the cycle Apple currently is.

barkerja 4y ago
To piggyback off the beta release cycle, I really like Thinky Bits chart on iOS beta releases. Looking at it gives a pretty good idea of when the current beta will hit RC. http://www.thinkybits.com/blog/iOS-versions/ http://www.thinkybits.com/blog/iOS-versions/
afavour 4y ago
> A more relaxed solution to the zip issue would be simply to patch zip.js to not use the Compression Streams API in Safari. IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec. > After 16.4 came out you could check if it worked, and remove the patch at your own pace. Great for regularly updated web sites but if you're making a tool you don't want to maintain it'll forever be stuck in a state where Safari performs worse because it isn't using the correct API. And that sucks for users.
- jeroenhd 4y ago
  > IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec. In this case I would probably add an "if Safari >=16.4 then skip compression streams" check, but that check would probably still be there in a couple of years. Resolving the immediate issue of "the product doesn't work on Safari" gets priority but "let's see if Safari got their shit together" would be a low priority task for me. There bad (or seemingly incomplete) spec implementations are how you end up with "your browser is not supported" plastered all over web apps. When Blink will inevitably hit iOS, Apple will have to do a better job placating web dev concerns if it doesn't want to lose market share.
  - zamnos 4y ago
    Following the official instructions*, I'm able to run (on iDevices tied to my Apple developer account) a custom built Chromium binary that is supposed to be Blink on iOS. Unfortunately this doesn't seem to be the case, according to a JSFiddle for WebTransport **. Desktop prod Chrome is able to see the WebTransport variable, Desktop prod Safari is unable to, mobile prod Safari is also unable to, and my custom Chromium binary, with use_blink set to true is also unable to. My guess is that my build is not actually reading that flag, but someone more adept at this bespoke build system would easily be able to figure out what's going wrong. * https://chromium.googlesource.com/chromium/src/+/main/docs/ios/build_instructions.md https://chromium.googlesource.com/chromium/src/+/main/docs/i... ** https://jsfiddle.net/jib1/8gtd3s9v/10/ https://jsfiddle.net/jib1/8gtd3s9v/10/
    - deleted 4y ago
      [deleted]

barkerja 4y ago

To piggyback off the beta release cycle, I really like Thinky Bits chart on iOS beta releases. Looking at it gives a pretty good idea of when the current beta will hit RC. http://www.thinkybits.com/blog/iOS-versions/ http://www.thinkybits.com/blog/iOS-versions/

afavour 4y ago

> A more relaxed solution to the zip issue would be simply to patch zip.js to not use the Compression Streams API in Safari. IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec. > After 16.4 came out you could check if it worked, and remove the patch at your own pace. Great for regularly updated web sites but if you're making a tool you don't want to maintain it'll forever be stuck in a state where Safari performs worse because it isn't using the correct API. And that sucks for users.

jeroenhd 4y ago
> IMO absolutely any time you have to sniff a browser user agent there's a failure somewhere. If there's a spec the implementation should adhere to the spec. In this case I would probably add an "if Safari >=16.4 then skip compression streams" check, but that check would probably still be there in a couple of years. Resolving the immediate issue of "the product doesn't work on Safari" gets priority but "let's see if Safari got their shit together" would be a low priority task for me. There bad (or seemingly incomplete) spec implementations are how you end up with "your browser is not supported" plastered all over web apps. When Blink will inevitably hit iOS, Apple will have to do a better job placating web dev concerns if it doesn't want to lose market share.
- zamnos 4y ago
  Following the official instructions*, I'm able to run (on iDevices tied to my Apple developer account) a custom built Chromium binary that is supposed to be Blink on iOS. Unfortunately this doesn't seem to be the case, according to a JSFiddle for WebTransport **. Desktop prod Chrome is able to see the WebTransport variable, Desktop prod Safari is unable to, mobile prod Safari is also unable to, and my custom Chromium binary, with use_blink set to true is also unable to. My guess is that my build is not actually reading that flag, but someone more adept at this bespoke build system would easily be able to figure out what's going wrong. * https://chromium.googlesource.com/chromium/src/+/main/docs/ios/build_instructions.md https://chromium.googlesource.com/chromium/src/+/main/docs/i... ** https://jsfiddle.net/jib1/8gtd3s9v/10/ https://jsfiddle.net/jib1/8gtd3s9v/10/
  - deleted 4y ago
    [deleted]