[1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...
[1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...
However, if your goal is to prevent Google from having complete and total unilateral control of the web standards, simply the existence of WebKit as a prominent browser engine is enough. Its quality pretty much doesn't matter in this regard. This is pretty much my perspective.
Firstly, you complain of a third-party dependency being broken in a preview build of Safari, and that you had went on holiday the week the stable version was published, meaning you couldn’t guarantee the problem was fixed in the stable release. Plainly, that’s an organisational problem on your end—the Safari team fixed the problem on their end. I’ll come back to your complaints re. release schedules.
Your second complaint is, in your own words, “we accidentally relied on a Chrome bug that meant our Service Worker was broken in Safari 16.4.” You go on to rehash your initial complaint, which is that Apple doesn’t publish a release schedule for Safari. I don’t inherently disagree with this complaint at face value.
Finally you move on to your third complaint, but to me it seems like yet another problem on your end. You made the observation that a given feature was supported and made the assumption that it was supported fully, with no other logic in place to test functionality or fallback to another rendering method. By your own admission again: “We detected OffscreenCanvas merely by seeing if it was defined. I never expected a browser to ship it with some contexts but not others - I assumed it would have parity with the standard canvas element.” I can understand the frustration and panic of being caught out here, but the pitfall is in your application logic. Your arguments afterwards with regard to supporting existing content are well said, but don’t generalise in this case. Just because something broke for you doesn’t mean everyone made the same flawed assumptions you did.
You then go on to list a random assortment of historic instances of Safari having flaws, as if that isn’t true of all browsers across the board.
All other browsers have enough communication and transparency to avoid this. Towards the end of the blog post I outline what Apple need to do - which all other browser makers already do - to make it at least vaguely tolerable to develop for Safari.