1. 14
    1. 42

      This feels like someone who’s angry but not particularly justifiably angry.

      The three bugs they discuss are:

      1. Apparently genuine bug in Safari, which Safari fixed, and the complaint is that when they asked for details of Safari release dates they were told to look at the Safari Technology Preview releases. One of which did in fact ship the fix, and then the next proper public release of Safari shipped it as well. But the author does not feel this is sufficient for some reason.
      2. Buggy behavior in Chrome‘s implementation of a feature that the author was relying on in a widely-used application. The author is upset that Apple, after generously helping them debug and identify the real issue, did not give an exact date for the upcoming Safari release so that the author would know exactly how long they had to fix their own buggy “works in Chrome” code before Safari’s correct implementation was out in the wild.
      3. Safari shipping a partial implementation of a feature (offscreen canvas, but 2D only, with 3D/WebGL support to come later), when the author had assumed – because Chrome did it – that any browser which shipped the feature at all would ship 3D/WebGL as part of it. The author is upset at this happening, upset that Apple told the author their feature detection (which only checked for offscreen canvas and not for the specific 3D/WebGL context they wanted) was incorrect, and is upset that Apple didn’t provide an exact target release date so the author would know when their incorrect feature detection was going to break on production browsers.

      As a side note, on (3) the author says:

      Apple pointed out that this is apparently allowed by the spec, and that it was faulty feature detection on our part. Looking at the relevant spec, I still can’t say, as a web developer rather than a browser maker, that it’s obvious that it’s allowed.

      But the prose section of the interface definition for offscreen canvas says, explicitly:

      Only the 2D context for offscreen canvases is defined in this specification.

      I know this article is going around as “proof” of the “Safari is the new IE! Safari is the new IE!” stuff that’s become fashionable, but it appears that of the three issues listed, only one was an actual bug in Safari and they fixed it promptly and the fix was verifiable in a preview release. The other two were explicit instances of the author assuming that whatever Chrome does is the “standard”, which points much more strongly toward Chrome being the “new IE”, at least if we want to compare to the bad old days of the actual MSIE monopoly.

      1. 15

        It feels like the underlying problem is that the web is not really what people like the author of this post want. They want a stable, portable, cross-platform development environment. What they have is a set of different (and mostly-but-not-quite compatible) implementations of an overlapping set of APIs, with no control over when their users move from one version of the application runtime to another. I suspect that Apple’s perspective on this is that they wouldn’t have any of these problems if they shipped a native app.

      2. 10

        I don’t think the bugs are really the main complaint in this article. The main complaint is the lack of communication from Apple about release timing—something that neither Google nor Mozilla feels the need to be so secretive about. It seemed like the team was able to work around the bugs themselves, but the uncertainty around whether a particular issue would be fixed in the next public release, and when that release will be, caused a lot of unnecessary stress. You say,

        One [release of Safari Technology Preview] did in fact ship the fix, and then the next proper public release of Safari shipped it as well. But the author does not feel this is sufficient for some reason.

        The author wrote,

        STP 166 came out on Thursday March 23rd, and then Safari 16.4 finally rolled out on Monday March 27th. There was just a single full working day in between.

        This comes across to me as a very capricious and abrasive way to run a platform. The fact that things worked out okay in the end does not mean that Apple’s processes are fine.

        I think one of the underlying issues here is Apple’s insistence on bundling Safari updates with iOS releases. Another issue is their refusal to announce most software updates in advance. I understand why they want to keep the new iPhone under wraps, but I don’t think those reasons apply to iOS point updates.

        1. 10

          This comes across to me as a very capricious and abrasive way to run a platform. The fact that things worked out okay in the end does not mean that Apple’s processes are fine.

          Should apple have not shipped STP166, or not shipped Safari 16.4?

          I think one of the underlying issues here is Apple’s insistence on bundling Safari updates with iOS releases.

          WebKit is a system framework, that is used by vastly more than just Safari. It’s not like chrome where every app has a full copy of the browser.

          Another issue is their refusal to announce most software updates in advance.

          Why would this matter? If someone’s site is broken (as multiple of the complainants bugs indicated was the case) they should fix their site, rather than IE-ing their way to single browser support. Why would knowing the exact time of release change anything?

          1. 3

            Should apple have not shipped STP166, or not shipped Safari 16.4?

            I’m not suggesting Apple should have held the release. But they could have said, “Safari 16.4 will be released no earlier than [date].” That would have avoided a lot of angst on this development team, and doesn’t really have any disadvantages for Apple, as far as I can tell. That’s really the issue here: the humans on the development team going through an unnecessarily stressful process because Apple is so tight-lipped about whether and when STP builds are going to turn into public Safari builds.

        2. 1

          Apple can afford to be abrasive, because they own the mobile platform which can earn developers the most money.

          And Apple has never had the developer-centric focus that Microsoft has (had?). They basically lucked into this situation and have never had to change their mindset because they’re making money hand over fist.

        3. 0

          This comes across to me as a very capricious and abrasive way to run a platform.

          I mean, that’s on-brand.

          https://www.zdnet.com/article/apple-deprecating-macos-kernel-extensions-kexts-is-a-great-win-for-security/

          ”Until now, macOS has been a haven for developers and its users. If macOS didn’t have a specific feature, developers could just create an app and leverage a kernel extension to add the features they needed.”

    2. 3

      Shipping Safari updates independent of OS updates would help with this. Is not 1998 anymore…

      1. 3

        How would this be different from shipping an OS update that merely contains Safari fixes, if there were an urgent need to release a Safari fix? Their release timing is not a technical limitation.

      2. 2

        Apple does update Safari independently on macOS. I don’t know why they don’t on iOS. My guess is that there are arcane details of the iOS build/release processes that make it more difficult than it seems from the outside.

        The core functionality is in the WebKit framework, which is a system framework used by many Apple and 3rd party apps, and updating that should require an OS update, but I think on macos they get around that by bundling Safari updates with their own private copy of WebKit.

        1. 1

          Maybe webkit is more baked into iOS than it is on MacOS? It’s exposed to arbitrary apps as part of the system API instead of a library that apps can pack in.

          1. 3

            It’s a system framework on all Apple platforms, i.e. a dynamic library in /System/Library/Frameworks.

            1. 1

              Yeah if it’s a system framework of the OS they probably can’t just push updates whenever they want. They have a release schedule that they need to follow.

    3. 1

      I feel for them, but some of their pain seems to have been avoidable.

      Construct projects are based on zip files, and we use a popular library zip.js to read them, which in turn uses the Compression Streams API when supported.

      Meanwhile, consider that during everything else described in this post, we weren’t able to open most projects in Construct.

      Couldn’t they have patched zip.js — replaced the check for the Streams API with a false — to work around the issue? Even if there were an obscure reason they couldn’t ship that way, it would have at least unblocked their testing.

      1. 3

        Couldn’t they have patched zip.js

        I don’t think this would avoid the issue for them. The description of the other issue related to OffscreenCanvas suggests to me that the output of their tool, a completed game, includes a snapshot of the code at that time thus the author would need to republish to have things update, all existing games would be broken unless this was done.

        1. 2

          I get that, but the wording “We weren’t able to open most projects” implies they were blocked from doing any testing, and that it wasn’t finished games they were opening but the editable projects, which presumably don’t include the runtime code.