22 ms·

Safari releases are development hell

318 points by AshleysBrain 4y ago

realusername 4y ago
I'm fortunate enough to be in another job now where we don't need iOS web support so we can tell customers that we won't fix it, in my past job where I had to it was very hard to keep up with the constant stream of broken safari releases, every one of them being broken in different ways. I sympathize with those who still do and I'm looking forward to EU regulations to allow other rendering engines.
meibo 4y ago
Supporting iOS and macOS in webdev is an absolute nightmare and a big reason why I left that space and am not planning to go back until something fundamentally changes. It's clear that they're still trying to undermine the web where possible, without it seeming too obvious or getting them into hot water re: the recent monopolization debate.
- pier25 4y ago
  I 100% agree with the sentiment and I have suffered a lot because of that. But I will say things seem to be slowly progressing. Webkit is releasing more often and closer to the standards now than they used to. I'm guessing Apple knows they will be forced to allow other engines on iOS and are finally making Safari a good product.
- bzzzt 4y ago
  While I get where the 'undermine' narrative is coming from, there are other, IMO more plausible, reasons why support is difficult: - Apple doesn't want others to dictate their development schedule. - Some Web standards clash with Apple's privacy promises. While I'd like Apple to do a bit more about those long standing bugs, I think the narrative they are actively undermining the web is short sighted. I prefer Apple's behaviour instead of Google's behaviour to actively monopolise the web...
  - wswope 4y ago
    Yes, thank you for speaking up to defend Apple’s prerogatives here. No one should have to suffer through the (checks notes) privacy violations and grueling six-year implementation timeline of adding a date picker input to their browser. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
    - illiarian 4y ago
      I wish HN had more complaints like this, and not the usual "whatever is the latest Chrome API of the day we need it in all browsers now!" --- As a tangent. If it was Apple of, say, 5-10 years ago, I'd also root for them to get their head out of their ass and lead in https://open-ui.org/ https://open-ui.org/ (started, of all people, by devs from Microsoft). Alas, with the way they approach interfaces these days, I'd want them far away from leading :)
      - wdb 4y ago
        Pretty confusing name when OpenUI5 already exists
timeimp 4y ago
Safari is to browsers today what IE once was: dread by those that have to support them. I am yet to meet competent developers who have ever given two hoots about “super fastest browser #1!!” blog posts over feature completed-ness / spec-compliance. I hope the C-level exec at Apple sees this and realises why more devs are going to go with Edge (lol) / Firefox support: the sales guys are running Apple now.
- manuelmoreale 4y ago
  > Safari is to browsers today what IE once was: dread by those that have to support them. I mean, I don't think it's even close to beign modern day IE. Perfect? Far from it but definitely not as much of a pain as IE
  - ihateyouall123 4y ago
    I think so
  - squaresmile 4y ago
    I think one thing that makes it IE-like is updates being tied to the OS. Asking the users to update an app is an easier sell than updating their OS.
    - kergonath 4y ago
      This is so far down the list of issues related to IE 6… If it’s the worst aspect of mobile Safari, then there’s not much to complain about.
- Grieverheart 4y ago
  Nothing beats Safari in terms of battery usage, and there are features like the reading list that work really well (for me). For development, yes, I always have Chrome installed in case I needed it.
  - brnewd 4y ago
sunaurus 4y ago
I switched to a Safari-first approach for web development a while back and it has reduced my pain considerably. In fact I use it as my main daily driver browser in general now. I've yet to run into a single case of some code running well on Safari but breaking on other major browsers, so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything.
- faitswulff 4y ago
  This wouldn’t have helped the author, though, since their issues were contingent on what fixes were included in the actual releases.
  - ricardobeat 4y ago
    It's always been a web developer's job to workaround browser incompatibility issues. Expecting them all to be 100% compliant with specs is a mirage.
- saagarjha 4y ago
  Ok, but that doesn't actually help when you run into WebKit bugs.
  - giraffe_lady 4y ago
    It does because you notice you've run into a webkit bug and work around it. A surprisingly high number of sites have core functionality like signin, nav or payment broken on safari and apparently aren't aware of it.
- lostgame 4y ago
  This is an exceptionally smart outlook; and reflects my own experience - if something is wrong in my code in Safari it is usually wrong elsewhere. There's an important and cool concept here about using the weakest link sometimes. Similar example: as an app developer, I intentionally use a phone several, several generations behind so I can see what the actual response time and general UX feeling is on the devices frankly a lot of users are going to have. If my app runs well on my iPhone 8, it's obviously going to scream on a 12.
meindnoch 4y ago
TL;DR: they are mad because of: 1. A genuine (?) Safari bug with the CompressionStream API. (we never learn what the actual bug was, and their bugreport to WebKit was literally just that "hey, our website at URL ... doesn't work" - no minimal reproducible example whatsoever. Lol) 2. An issue due to them relying on a Chromium bug. 3. An issue due to them assuming that OffscreenCanvas will always support both 2D and 3D (WebGL) contexts.
- replygirl 4y ago
  > I assumed it would have parity with the standard <canvas> element. Why wouldn't it? The MDN documentation mentioned nothing about inconsistent availability of contexts. only mdn docs do list the context types as separate subfeatures in the support table, as does caniuse
- mrweasel 4y ago
  It honestly impressive how quickly they get a fix. Sure it take seven days for someone to get to the bug they filed, but from there it's fixed in 12 hours. The post makes it sound like both Mozilla and Google are better at handling releases, but Chrome has the service worker bug, so I don't know if that's actually true. I get that Safari is sluggish, at least compared to Chrome and is currently lacking features, but doesn't it seem like they've picked up the pace in the last year or so?
- theodorejb 4y ago
  These were just a few issues with the latest version. Similar problems have occurred with past releases for years, and it seems the author is justifiably stressed out over the lack of transparency and never being sure if/when a breaking change is about to occur for customers using Safari.
- MrBuddyCasino 4y ago
  I've read the standard [0], to be fair there is nothing in there explicitly indicating that some contexts might be unsupported, except the vague "if this does not throw an exception" condition, which is easy to miss. [0] https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface https://html.spec.whatwg.org/multipage/canvas.html#the-offsc...
tgv 4y ago
I understand they're annoyed, but "hell"? Chrome put me through a wild goose chase somewhere around version 94 with some non-standard behavior, and Safari 16 has some weird issue with requestAnimationFrame, but "hell"? That's out of proportions.
- pier25 4y ago
  If you're a game engine or just have a product focused on realtime graphics, issues with requestAnimationFrame can just destroy your product.
- tough 4y ago
  Man is free to make up their own personal hells
- throwayyy479087 4y ago
  His complaints are very well outlined. They are a bit niche due to his use case, but they certainly are real, breaking changes out of nowhere. Standards compliance really is the name of the game, and I wish people like GP had more pull to force Apple to make these reasonable changes.
  - lucideer 4y ago
    If you think this you haven't read the linked bug reports. His second one in particular is his app relying on unspecified implementation quirks - the Safari devs are responsive due to a desire to be more compatible with Chrome's quirks, not because they've failed to conform to spec. His first bug report is just lazy and devoid of any detail - completely relies on the Safari team to do the work of debugging his app for him.
    - AshleysBrain 4y ago
      I credited the Apple developers with doing a good job in the blog. The point is Apple's policies end up turning what should be a routine bug fix in to a total nightmare. I've filed dozens of issues with Apple and many of them go in to great detail. However when you're pushed for time and dealing with multiple potential emergencies, you can't always manage much more than a "heads up, this looks wrong" type issue. In the case of the first bug, it was indeed a real problem with Safari and it was Apple's responsibility to fix it. Given that Apple are a trillion-dollar company with thousands of employees, and we have a handful of people in an office in south-west London, I think it's reasonable that Apple does more of the heavy lifting investigating Safari issues anyway. Ultimately it's up to Apple to make Safari a high-quality browser, not us, although we still do our bit with bug reports where we can.
z3t4 4y ago
Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work, they are used to it. If possible you should have automatic tests that you can run automatically in several browsers. Some browser need to be the first one to implement new functionality, before there is a specification! Then the specification comes and often it's different then the already implemented API. You should not complain about new features, and you should not complain when browsers follow specifications. Instead you should have tests, and encourage users to report problems. Most browsers have a beta/review release, you can run your test on that, once per day, automatically. Use a program that automate mouse movements and clicks, for example Puppeteer for automating Chrome. (tip: also do performance test while you are at it, so you will know which changes affect performance)
- whywhywhywhy 4y ago
  > Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work Please go and meet some of your users in person and watch them use a computer/phone. Your eyes will be opened to a world you never knew existed.
- rippercushions 4y ago
  > Most browsers have a beta/review release, you can run your test on that, once per day, automatically. A large part of the post's complaint is that not only does Safari not have a nightly build, but they don't even give advance notice of when their "technology preview" (beta) or stable releases are coming. Chrome, by contrast, not only has a public schedule, but a public dashboard where you can follow along. https://developer.chrome.com/blog/early-stable/ https://developer.chrome.com/blog/early-stable/ https://chromiumdash.appspot.com/schedule https://chromiumdash.appspot.com/schedule
  - Y-bar 4y ago
    I thought there were nightly (or at least daily) builds? At least it looks that way in the WebKit archive where the three latest builds right now are: 262503@main April 3, 2023 at 01:23 PM GMT+2 262502@main April 3, 2023 at 10:51 AM GMT+2 262501@main April 3, 2023 at 10:17 AM GMT+2 https://webkit.org/build-archives/#mac-ventura-x86_64%20arm64 https://webkit.org/build-archives/#mac-ventura-x86_64%20arm6...
macguillicuddy 4y ago
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.
kouteiheika 4y ago
This does match up with my experience pretty well. Hopefully once the EU forces Apple to open up their app store I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.
- Aaargh20318 4y ago
  They you'd lose me as a user. For me as a user Firefox is a terrible browser, it doesn't integrate well with the OS (e.g. no iCloud Keychain) and feels clunky but most importantly: I don't trust Mozilla. In the past they have on multiple occasions shown poor judgment [1][2][3] where they obviously prioritise making money over the interests of their users. For me, Safari is het only browser I truly trust, because Apple makes money from selling me stuff, instead from selling me. [1] https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robot-arg-plugin-firefox-looking-glass https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robo... [2] https://www.theverge.com/2021/10/7/22715179/firefox-suggest-search-ads-browser https://www.theverge.com/2021/10/7/22715179/firefox-suggest-... [3] https://blog.mozilla.org/advancingcontent/2015/05/21/providing-a-valuable-platform-for-advertisers-content-publishers-and-users/ https://blog.mozilla.org/advancingcontent/2015/05/21/providi...
  - smoldesu 4y ago
    It's alright if you prefer the way Safari works, but I wouldn't "trust" any browser. I certainly wouldn't only trust the browser made by a company that complies with 90% of government requests for account access: https://www.apple.com/legal/transparency/us.html https://www.apple.com/legal/transparency/us.html A trustworthy browser holds itself accountable by making it's code transparent and it's intentions clear. Mozilla is terrible at marketing Firefox, but I'd argue they've built a much more amicable framework for the web than Apple has.
  - kouteiheika 4y ago
    > They you'd lose me as a user. To be quite honest, I don't care. I'm just a single guy working in his spare time; I don't have the resources to keep up with a trillion dollar corporation. I'm so done with the endless Safari-only hacks. I'm so done with having to push emergency updates because Apple decided to suddenly break half of my website in the newest version of Safari. And I'm so done with having to explain to my users that, yes, audio autoplay doesn't work on Safari, and no, it's not a bug, it's because Apple actively blocks it and won't let you decide for yourself if you want to enable it for my site, and all of that because they want to force me to build a native app (where I can autoplay to my heart's content) so that they can extort 30% of my income. > where they obviously prioritise making money over the interests of their users. ...and Apple doesn't do that? > because Apple makes money from selling me stuff, instead from selling me. Are you sure? https://proton.me/blog/apple-ad-company https://proton.me/blog/apple-ad-company
alkonaut 4y ago
I'm so happy I don't develop anything that targets web browsers or web servers. Yes deployments are a pain instead, but at least it's a known pain. Package the app and send it off.
alex-moon 4y ago
In the job I'm currently in (doing front-end for the first time in many years) I can confidently say that every time we've had a bug that was browser-specific, that browser was some brand of Safari - usually Safari mobile, which shits me even more because the iPhone doesn't let users install any alternatives, i.e. literally what Microsoft went to court for. Reason enough on its own not to get an iPhone, or indeed any Apple product at all. I can only imagine how much Safari has cost the industry in wasted dev time.
- realusername 4y ago
  Sometimes you can even tell it just from the sentry error text itself that it's a safari bug. It has a kind of distinctive feel of nonsense, I don't know how to explain it.
- vlovich123 4y ago
  Microsoft went to court over that because they were leveraging their OS monopoly into a browser monopoly. Microsoft always let you install alternatives by the waybut IE was the default and most people don’t change defaults. Apple is not a monopoly unless you’re just looking at mobile profits, which historically is not how a monopoly is defined (they’re not even a monopoly in the luxury smartphone market). Android is actually much closer to being a monopoly and does all sorts of deals to maintain their monopolies on search, browsers, and Android which would warrant investigation. Now maybe a monopoly should be defined as % of total profits in a market? Not sure. It would be breaking new regulatory ground for sure. Also, from the sounds of it, Apple is going to be forced to allow third party browsers and app stores via EU regulation. It’s less clear exactly how that will work and whether that will be available to customers in other jurisdictions.
  - scarface74 4y ago
    I knew this bit of false internet lore was going to come up. Out of all the things that the justice system was throwing at MS, bundling IE was the least of them and absolutely nothing changed about browser bundling in the US. No there was never a browser choice mandate.
chatmasta 4y ago
I concur with the frustrations in the article. Note that you can automatically test Safari releases with Playwright and GitHub Actions MacOS runners.
ricardobeat 4y ago
These bug reports are very poor, with apparently no effort to zoom in on the underlying issue, but the WebKit team took application-specific problems like “can’t open project”, “the app gets stuck in the loading screen”, dug in and fixed them in days time. This is stellar support for a single company or product, props to the Safari team for that. I do agree releasing a broken implementation is bad, not clear what happened there. Aren’t Safari releases held back until a TP is free of critical issues? Was this not marked as critical due to being reported as an app issue instead of a Compression Streams or Service Workers incompatibility / regression?
- saagarjha 4y ago
  > Aren’t Safari releases held back until a TP is free of critical issues? No. Safari releases ship in lockstep with iOS releases.
  - ilikehurdles 4y ago
    Not so on MacOS.
    - lapcat 4y ago
      It is so on macOS. In fact, macOS updates now ship in lockstep with iOS releases. This is because they all share code, and more importantly, security vulnerability fixes. You might be referring to how Safari is updated independently of macOS on the 2 non-latest versions of macOS. But those are still released simultaneously with the OS updates, and Safari on the latest version of macOS is bundled with the OS update.
      - ilikehurdles 4y ago
        I think I might be referring to that? Mainly referring to the separate “Other Updates” section of downloads, but I didn’t know those are still tied to OS updates for Safari.
        4y ago
sccxy 4y ago
Safari is real pain for web apps. "Most powerful" phone runs out of memory, but 10 year old Android can handle same site fine. It was working fine in iOS 15 also. And works even in old IE11. Every iOS release is horror, what will be broken again... Yes, I am angry and tired of Apple's lack of QA. Trillion dollar company should invest more in quality.
VyseofArcadia 4y ago
It's not limited to Safari. I used to work on a macOS desktop application, and we used to beg our customers to put off upgrading to new macOS versions to buy time to sort out all the undocumented behavior changes.
pveierland 4y ago
"Epiphany Technology Preview" is a WebKit build available for Linux which has been very helpful for testing Safari quirks without having macOS available. https://webkit.org/downloads/ https://webkit.org/downloads/
exabrial 4y ago
Server side rendering… makes things a lot easier.
ribit 4y ago
Apple would certainly benefit from more transparency in these matters, no question. Decoupling Safari updates from OS updates and better communication/tracking of issues and release dates would be a big help At the same time, I don't really see why they should aim to replicate other browser bugs or be responsible for author's idiosyncratic assumptions regarding feature availability. It's a shame that browsers don't have to undergo strict compliance tests and that JavaScript is generally pretty much awful. Under these circumstances the most popular browser (Chrome) is taken as a gold standard and that can't be good for the open web.
- AshleysBrain 4y ago
  Is it idiosyncratic to assume that two variants of the canvas API support the same things?
  - bzzzt 4y ago
    Considering it's a big API with dozens of methods I'd be surprised if two implementations would agree exactly.
    - AshleysBrain 4y ago
      I would have assumed browsers had one internal implementation and exposed it through both APIs. They wouldn't want to have two separate implementations of a large amount of complex code.
  - cxr 4y ago
    Yes, and it's a little reckless to even get to a state where, even in the presence of bonafide bugs re non-standard behavior, just showing "a blank screen" when your app dies is a possibility. Add some basic error detection/reporting.
    - AshleysBrain 4y ago
      We did have basic error detection and reporting. For example if it failed to get WebGL in a normal HTML canvas, it would show a "WebGL not supported" error message with some diagnostic details and some advice about what the user could do about it. The problem in this case is a gotcha where there are two ways to access the canvas API, one supporting WebGL, and the other not - a case we never anticipated, nor had happened with any previous browser.
lapcat 4y ago
> More pre-release testing options It's also worth noting that Apple has the bad habit of discontinuing Safari Technology Preview support on older macOS versions faster than they discontinue Safari support on older macOS versions, which results in testing gaps for Safari on those versions. Safari supports the last 3 macOS versions, while Safari Technology Preview only supports the last 2. Take a wild guess which macOS version gets the most new regressions from new Safari versions.
davbryn 4y ago
Other than the CompressionStream API bug, the rest of these could have been avoided by a) not relying on a supported 3D Offscreen Canvas and b) having unit tests so you aren't running prod against a Chromium bug. I understand the stress, but why do they think their product deserves more of Apple's attention than Safari's own product team who undoubtably are working to hard deadlines? This felt like a really, really long whine because they didn't account for certain issues, and I found the 'Apple employee' references to be a little crass
- AshleysBrain 4y ago
  Sure, mistakes happen, and sometimes it's our fault. But the point is Apple's policies turn what would normally be a routine bug fix in to a total nightmare.
  - tokamak-teapot 4y ago
    The suggestions as to what Apple could do to help are all great, but it does look (from here) like there could be ways to tweak application development process to better shield against breakage. It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases. I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier? The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library. The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour? The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but… … the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined. It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.
toyg 4y ago
> "I desperately want Apple to change" Ahh, that's your problem right there, man. Apple don't change for you, for me, or for anyone who isn't called Tim Cook. They'll be out there doing their monopolistic, zero-sum, winner-takes-all, my-way-or-the-highway, straight-outta-the-'90s thing, forever and ever. Apple doesn't care about developers really, as far as the company is concerned they're all little sharecroppers on Steve's garden. Any help you get you should be thankful for, because you have no rights there and never will have. Enjoy your Stockholm syndrome while it lasts.
- kingboss 4y ago
  Why would they care about developers? They care about their customers. People buy their stuff and you, as a dev, have to support Safari. Whether you like it or not. It's called work.
  - toyg 4y ago
    "the beatings will continue and you will like it"
livelielife 4y ago
quality is expensive. if not even apple can afford it, what can we expect from the rest?
danaris 4y ago
In general, I much prefer Safari to other browsers (though Firefox is generally quite good too). However, I've been bitten by what appears to be a WebKit bug in the latest update: using -webkit-mask-box-image to mask a div with an SVG shape no longer seems to respect the other sub-settings for that property, resulting in the mask being, at least for my use case, repeated 4 times within the space that it is supposed to show once. I'm still investigating whether this is something that's actually changed with the not-exactly-spec for this WebKit-specific CSS property, but given the behavior I've already observed when trying to debug it, it certainly seems like a regression.
JoeOfTexas 4y ago
Apple doesn't want webapps to replace their app store. That is why they gimp the hell out of Safari.
TheCoreh 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. 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.
VWWHFSfQ 4y ago
Safari is easily the worst browser in existence. It is absolutely riddled with bugs. Anything except the most basic functionality you can expect to be a buggy piece of crap for years on end. See webrtc. Hopefully apple gets sued someday so we can stop using their horrible browser
- ezfe 4y ago
  lol
coldtea 4y ago
We should have static builds and mostly static environments (libs etc). The "evergreen" madness must stop for platforms that are app delivery targets. Or do it like Java does it...
victor96 4y ago
I've always struggled with Safari for it's terrible WebGL implementation. Even had to globally disable anti-aliasing otherwise the app would be unusably slow!
mkl95 4y ago
The browser world is a political, uncoordinated mess. For example WebTransport (an HTTP3 API) has been available on Chromium-based browsers for months, but it's still on "Safari Technology Preview", and Firefox does not support it at all. You can probably find dozens of similar examples over the years.
- illiarian 4y ago
  > For example WebTransport (an HTTP3 API) has been available on Chromium-based browsers for months, but it's still on Perhaps because WebTransport is still not even anywhere close to be to a web standard? Perhaps because its status is literally, quote: --- start quote --- works in progress inside a W3C Group and are not required to have the consensus of the Group participants. These drafts have not received formal review and are not endorsed W3C. These drafts MUST NOT be cited as W3C standards and may or may not become W3C standards. --- end quote --- Just because it's shipped in Chrome does not make it a standard that every other browser has to implement immediately.
  - mkl95 4y ago
    I agree with all your points. I was trying to highlight how dysfunctional it feels from my point of view (backend engineer).
donmb 4y ago
Safari is the new Internet Explorer. We need to face it.
- kingboss 4y ago
  You meant to write Chrome.
blahblah1234567 4y ago
[dead]
jmull 4y ago
> ...which in turn uses the Compression Streams API when supported > ...uses OffscreenCanvas when available I think it's a mistake to write your code to automatically use new platform capabilities when they become available if you won't have an adequate chance to validate them first. It's just too optimistic to believe a new implementation of a low-level mechanism is going to work exactly the way you need. (1) new things have new bugs; (2) changes are you'll end up depending on implementation details that will vary between different implementations.
- jefftk 4y ago
  What should you do instead? The alternative is UA-sniffing, and that's worse: https://news.ycombinator.com/item?id=35425549 https://news.ycombinator.com/item?id=35425549
  - jmull 4y ago
    > What should you do instead? It's your choice: (1) don't use it; (2) validate it before using it; (3) roll the dice on behalf of your users -- that is, use it without validating it. Don't let religious beliefs around UA-sniffing cause you to screw over your users.
- AshleysBrain 4y ago
  Browser makers, including Apple, always say to use feature detection - i.e. to use features when they appear to be available. The alternative is user-agent sniffing, which they advise against.
  - kevincox 4y ago
    Yeah, this is the problem with feature detection which isn't talked about enough. It is often easy enough to detect whole APIs or even some new methods but correct functionality and optional parameters can be hard or impossible to test. In most cases I have found that feature detection + a blacklist of problematic browsers is often a good compromise. But there is no perfect solution.
jwlake 4y ago
The problem I see with this is people assume that web platforms are platforms like the windows API where Microsoft doesn't like breaking things. It's more like Xcode, where every point release breaks something. You need to design your software and your development pipeline to handle that. Even Google isn't great in this but their continuous release schedule makes it less likely to break things in the wild because they get constant pushback.
- circuit10 4y ago
  From what I understand the web is meant to be 100% backwards compatible. You should be able to load up the first HTML document ever made and have it still render fine (and it probably would)
rejectfinite 4y ago
>I asked whether the fix would ship in Safari 16.4, and an engineer responded talking about STP. Spanning Tree Protocol? :D
wdb 4y ago
My main problem with Safari is that it is not as convenient to use a developer tool. Sure, its devtools looks pretty but it doesn't have all the useful devtools extensions that Chrome/Edge has. I use Safari as my main content browser but typically switch to Edge for development work. Also when you read W3C specs it can get confusing pretty quickly, vage wordings, etc. Or have MDN documentation that doesn't describe particular behaviour that is defined in the W3C specs etc.
huntedsnark 4y ago
Wherein people who only develop in Chrome cry about web standards
paulddraper 4y ago
> Safari is the last browser in the industry left tied to its OS Isn't that like illegal or something? Like Microsoft got sued for it?
h4ch1 4y ago
How do I test on Safari while building my webapps; I only have a single machine that runs Linux and Windows; and the last Safari release for Windows is from 2015. It was very recent that I came accross a flexbox bug with flex-wrap which had me scrambling to find someone with an iOS device so I could test on Safari and that was pretty painful. PS; I am not very well off, so buying devices merely for testing on a browser seem pretty overkill.
- Y-bar 4y ago
  Try Epiphany, WPE, or WebKitGTK: https://webkit.org/downloads/ https://webkit.org/downloads/
gloosx 4y ago
And we always wondered, why is it this way? Apple - beautiful hardware, crappy software...
thatsadude 4y ago
Personally, Safari left a bad taste in my mouth. We had to kill a product line because bugs in Safari's AudioWorklet. I don't think audio processing on Web is viable until Safari plays nicely with WebAudio.
- pier25 4y ago
  Yep. Working on some audio thing and had to desist of using WebAudio because of Safari.

318 points by AshleysBrain 4y ago

I'm fortunate enough to be in another job now where we don't need iOS web support so we can tell customers that we won't fix it, in my past job where I had to it was very hard to keep up with the constant stream of broken safari releases, every one of them being broken in different ways. I sympathize with those who still do and I'm looking forward to EU regulations to allow other rendering engines.

meibo 4y ago

Supporting iOS and macOS in webdev is an absolute nightmare and a big reason why I left that space and am not planning to go back until something fundamentally changes. It's clear that they're still trying to undermine the web where possible, without it seeming too obvious or getting them into hot water re: the recent monopolization debate.

pier25 4y ago
I 100% agree with the sentiment and I have suffered a lot because of that. But I will say things seem to be slowly progressing. Webkit is releasing more often and closer to the standards now than they used to. I'm guessing Apple knows they will be forced to allow other engines on iOS and are finally making Safari a good product.
bzzzt 4y ago
While I get where the 'undermine' narrative is coming from, there are other, IMO more plausible, reasons why support is difficult: - Apple doesn't want others to dictate their development schedule. - Some Web standards clash with Apple's privacy promises. While I'd like Apple to do a bit more about those long standing bugs, I think the narrative they are actively undermining the web is short sighted. I prefer Apple's behaviour instead of Google's behaviour to actively monopolise the web...
- wswope 4y ago
  Yes, thank you for speaking up to defend Apple’s prerogatives here. No one should have to suffer through the (checks notes) privacy violations and grueling six-year implementation timeline of adding a date picker input to their browser. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
  - illiarian 4y ago
    I wish HN had more complaints like this, and not the usual "whatever is the latest Chrome API of the day we need it in all browsers now!" --- As a tangent. If it was Apple of, say, 5-10 years ago, I'd also root for them to get their head out of their ass and lead in https://open-ui.org/ https://open-ui.org/ (started, of all people, by devs from Microsoft). Alas, with the way they approach interfaces these days, I'd want them far away from leading :)
    - wdb 4y ago
      Pretty confusing name when OpenUI5 already exists

timeimp 4y ago

Safari is to browsers today what IE once was: dread by those that have to support them. I am yet to meet competent developers who have ever given two hoots about “super fastest browser #1!!” blog posts over feature completed-ness / spec-compliance. I hope the C-level exec at Apple sees this and realises why more devs are going to go with Edge (lol) / Firefox support: the sales guys are running Apple now.

manuelmoreale 4y ago
> Safari is to browsers today what IE once was: dread by those that have to support them. I mean, I don't think it's even close to beign modern day IE. Perfect? Far from it but definitely not as much of a pain as IE
- ihateyouall123 4y ago
  I think so
- squaresmile 4y ago
  I think one thing that makes it IE-like is updates being tied to the OS. Asking the users to update an app is an easier sell than updating their OS.
  - kergonath 4y ago
    This is so far down the list of issues related to IE 6… If it’s the worst aspect of mobile Safari, then there’s not much to complain about.
Grieverheart 4y ago
Nothing beats Safari in terms of battery usage, and there are features like the reading list that work really well (for me). For development, yes, I always have Chrome installed in case I needed it.
- brnewd 4y ago

sunaurus 4y ago

I switched to a Safari-first approach for web development a while back and it has reduced my pain considerably. In fact I use it as my main daily driver browser in general now. I've yet to run into a single case of some code running well on Safari but breaking on other major browsers, so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything.

faitswulff 4y ago
This wouldn’t have helped the author, though, since their issues were contingent on what fixes were included in the actual releases.
- ricardobeat 4y ago
  It's always been a web developer's job to workaround browser incompatibility issues. Expecting them all to be 100% compliant with specs is a mirage.
saagarjha 4y ago
Ok, but that doesn't actually help when you run into WebKit bugs.
- giraffe_lady 4y ago
  It does because you notice you've run into a webkit bug and work around it. A surprisingly high number of sites have core functionality like signin, nav or payment broken on safari and apparently aren't aware of it.
lostgame 4y ago
This is an exceptionally smart outlook; and reflects my own experience - if something is wrong in my code in Safari it is usually wrong elsewhere. There's an important and cool concept here about using the weakest link sometimes. Similar example: as an app developer, I intentionally use a phone several, several generations behind so I can see what the actual response time and general UX feeling is on the devices frankly a lot of users are going to have. If my app runs well on my iPhone 8, it's obviously going to scream on a 12.

meindnoch 4y ago

TL;DR: they are mad because of: 1. A genuine (?) Safari bug with the CompressionStream API. (we never learn what the actual bug was, and their bugreport to WebKit was literally just that "hey, our website at URL ... doesn't work" - no minimal reproducible example whatsoever. Lol) 2. An issue due to them relying on a Chromium bug. 3. An issue due to them assuming that OffscreenCanvas will always support both 2D and 3D (WebGL) contexts.

replygirl 4y ago
> I assumed it would have parity with the standard <canvas> element. Why wouldn't it? The MDN documentation mentioned nothing about inconsistent availability of contexts. only mdn docs do list the context types as separate subfeatures in the support table, as does caniuse
mrweasel 4y ago
It honestly impressive how quickly they get a fix. Sure it take seven days for someone to get to the bug they filed, but from there it's fixed in 12 hours. The post makes it sound like both Mozilla and Google are better at handling releases, but Chrome has the service worker bug, so I don't know if that's actually true. I get that Safari is sluggish, at least compared to Chrome and is currently lacking features, but doesn't it seem like they've picked up the pace in the last year or so?
theodorejb 4y ago
These were just a few issues with the latest version. Similar problems have occurred with past releases for years, and it seems the author is justifiably stressed out over the lack of transparency and never being sure if/when a breaking change is about to occur for customers using Safari.
MrBuddyCasino 4y ago
I've read the standard [0], to be fair there is nothing in there explicitly indicating that some contexts might be unsupported, except the vague "if this does not throw an exception" condition, which is easy to miss. [0] https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface https://html.spec.whatwg.org/multipage/canvas.html#the-offsc...

tgv 4y ago

I understand they're annoyed, but "hell"? Chrome put me through a wild goose chase somewhere around version 94 with some non-standard behavior, and Safari 16 has some weird issue with requestAnimationFrame, but "hell"? That's out of proportions.

pier25 4y ago
If you're a game engine or just have a product focused on realtime graphics, issues with requestAnimationFrame can just destroy your product.
tough 4y ago
Man is free to make up their own personal hells
throwayyy479087 4y ago
His complaints are very well outlined. They are a bit niche due to his use case, but they certainly are real, breaking changes out of nowhere. Standards compliance really is the name of the game, and I wish people like GP had more pull to force Apple to make these reasonable changes.
- lucideer 4y ago
  If you think this you haven't read the linked bug reports. His second one in particular is his app relying on unspecified implementation quirks - the Safari devs are responsive due to a desire to be more compatible with Chrome's quirks, not because they've failed to conform to spec. His first bug report is just lazy and devoid of any detail - completely relies on the Safari team to do the work of debugging his app for him.
  - AshleysBrain 4y ago
    I credited the Apple developers with doing a good job in the blog. The point is Apple's policies end up turning what should be a routine bug fix in to a total nightmare. I've filed dozens of issues with Apple and many of them go in to great detail. However when you're pushed for time and dealing with multiple potential emergencies, you can't always manage much more than a "heads up, this looks wrong" type issue. In the case of the first bug, it was indeed a real problem with Safari and it was Apple's responsibility to fix it. Given that Apple are a trillion-dollar company with thousands of employees, and we have a handful of people in an office in south-west London, I think it's reasonable that Apple does more of the heavy lifting investigating Safari issues anyway. Ultimately it's up to Apple to make Safari a high-quality browser, not us, although we still do our bit with bug reports where we can.

z3t4 4y ago

Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work, they are used to it. If possible you should have automatic tests that you can run automatically in several browsers. Some browser need to be the first one to implement new functionality, before there is a specification! Then the specification comes and often it's different then the already implemented API. You should not complain about new features, and you should not complain when browsers follow specifications. Instead you should have tests, and encourage users to report problems. Most browsers have a beta/review release, you can run your test on that, once per day, automatically. Use a program that automate mouse movements and clicks, for example Puppeteer for automating Chrome. (tip: also do performance test while you are at it, so you will know which changes affect performance)

whywhywhywhy 4y ago
> Most users will have other browsers installed along with Safari. And they will just switch browser if something doesn't work Please go and meet some of your users in person and watch them use a computer/phone. Your eyes will be opened to a world you never knew existed.
rippercushions 4y ago
> Most browsers have a beta/review release, you can run your test on that, once per day, automatically. A large part of the post's complaint is that not only does Safari not have a nightly build, but they don't even give advance notice of when their "technology preview" (beta) or stable releases are coming. Chrome, by contrast, not only has a public schedule, but a public dashboard where you can follow along. https://developer.chrome.com/blog/early-stable/ https://developer.chrome.com/blog/early-stable/ https://chromiumdash.appspot.com/schedule https://chromiumdash.appspot.com/schedule
- Y-bar 4y ago
  I thought there were nightly (or at least daily) builds? At least it looks that way in the WebKit archive where the three latest builds right now are: 262503@main April 3, 2023 at 01:23 PM GMT+2 262502@main April 3, 2023 at 10:51 AM GMT+2 262501@main April 3, 2023 at 10:17 AM GMT+2 https://webkit.org/build-archives/#mac-ventura-x86_64%20arm64 https://webkit.org/build-archives/#mac-ventura-x86_64%20arm6...

macguillicuddy 4y ago

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.

kouteiheika 4y ago

This does match up with my experience pretty well. Hopefully once the EU forces Apple to open up their app store I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.

Aaargh20318 4y ago
They you'd lose me as a user. For me as a user Firefox is a terrible browser, it doesn't integrate well with the OS (e.g. no iCloud Keychain) and feels clunky but most importantly: I don't trust Mozilla. In the past they have on multiple occasions shown poor judgment [1][2][3] where they obviously prioritise making money over the interests of their users. For me, Safari is het only browser I truly trust, because Apple makes money from selling me stuff, instead from selling me. [1] https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robot-arg-plugin-firefox-looking-glass https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robo... [2] https://www.theverge.com/2021/10/7/22715179/firefox-suggest-search-ads-browser https://www.theverge.com/2021/10/7/22715179/firefox-suggest-... [3] https://blog.mozilla.org/advancingcontent/2015/05/21/providing-a-valuable-platform-for-advertisers-content-publishers-and-users/ https://blog.mozilla.org/advancingcontent/2015/05/21/providi...
- smoldesu 4y ago
  It's alright if you prefer the way Safari works, but I wouldn't "trust" any browser. I certainly wouldn't only trust the browser made by a company that complies with 90% of government requests for account access: https://www.apple.com/legal/transparency/us.html https://www.apple.com/legal/transparency/us.html A trustworthy browser holds itself accountable by making it's code transparent and it's intentions clear. Mozilla is terrible at marketing Firefox, but I'd argue they've built a much more amicable framework for the web than Apple has.
- kouteiheika 4y ago
  > They you'd lose me as a user. To be quite honest, I don't care. I'm just a single guy working in his spare time; I don't have the resources to keep up with a trillion dollar corporation. I'm so done with the endless Safari-only hacks. I'm so done with having to push emergency updates because Apple decided to suddenly break half of my website in the newest version of Safari. And I'm so done with having to explain to my users that, yes, audio autoplay doesn't work on Safari, and no, it's not a bug, it's because Apple actively blocks it and won't let you decide for yourself if you want to enable it for my site, and all of that because they want to force me to build a native app (where I can autoplay to my heart's content) so that they can extort 30% of my income. > where they obviously prioritise making money over the interests of their users. ...and Apple doesn't do that? > because Apple makes money from selling me stuff, instead from selling me. Are you sure? https://proton.me/blog/apple-ad-company https://proton.me/blog/apple-ad-company

alkonaut 4y ago

I'm so happy I don't develop anything that targets web browsers or web servers. Yes deployments are a pain instead, but at least it's a known pain. Package the app and send it off.

alex-moon 4y ago

In the job I'm currently in (doing front-end for the first time in many years) I can confidently say that every time we've had a bug that was browser-specific, that browser was some brand of Safari - usually Safari mobile, which shits me even more because the iPhone doesn't let users install any alternatives, i.e. literally what Microsoft went to court for. Reason enough on its own not to get an iPhone, or indeed any Apple product at all. I can only imagine how much Safari has cost the industry in wasted dev time.

realusername 4y ago
Sometimes you can even tell it just from the sentry error text itself that it's a safari bug. It has a kind of distinctive feel of nonsense, I don't know how to explain it.
vlovich123 4y ago
Microsoft went to court over that because they were leveraging their OS monopoly into a browser monopoly. Microsoft always let you install alternatives by the waybut IE was the default and most people don’t change defaults. Apple is not a monopoly unless you’re just looking at mobile profits, which historically is not how a monopoly is defined (they’re not even a monopoly in the luxury smartphone market). Android is actually much closer to being a monopoly and does all sorts of deals to maintain their monopolies on search, browsers, and Android which would warrant investigation. Now maybe a monopoly should be defined as % of total profits in a market? Not sure. It would be breaking new regulatory ground for sure. Also, from the sounds of it, Apple is going to be forced to allow third party browsers and app stores via EU regulation. It’s less clear exactly how that will work and whether that will be available to customers in other jurisdictions.
- scarface74 4y ago
  I knew this bit of false internet lore was going to come up. Out of all the things that the justice system was throwing at MS, bundling IE was the least of them and absolutely nothing changed about browser bundling in the US. No there was never a browser choice mandate.

chatmasta 4y ago

I concur with the frustrations in the article. Note that you can automatically test Safari releases with Playwright and GitHub Actions MacOS runners.

ricardobeat 4y ago

These bug reports are very poor, with apparently no effort to zoom in on the underlying issue, but the WebKit team took application-specific problems like “can’t open project”, “the app gets stuck in the loading screen”, dug in and fixed them in days time. This is stellar support for a single company or product, props to the Safari team for that. I do agree releasing a broken implementation is bad, not clear what happened there. Aren’t Safari releases held back until a TP is free of critical issues? Was this not marked as critical due to being reported as an app issue instead of a Compression Streams or Service Workers incompatibility / regression?

saagarjha 4y ago
> Aren’t Safari releases held back until a TP is free of critical issues? No. Safari releases ship in lockstep with iOS releases.
- ilikehurdles 4y ago
  Not so on MacOS.
  - lapcat 4y ago
    It is so on macOS. In fact, macOS updates now ship in lockstep with iOS releases. This is because they all share code, and more importantly, security vulnerability fixes. You might be referring to how Safari is updated independently of macOS on the 2 non-latest versions of macOS. But those are still released simultaneously with the OS updates, and Safari on the latest version of macOS is bundled with the OS update.
    - ilikehurdles 4y ago
      I think I might be referring to that? Mainly referring to the separate “Other Updates” section of downloads, but I didn’t know those are still tied to OS updates for Safari.
      - 4y ago

sccxy 4y ago

Safari is real pain for web apps. "Most powerful" phone runs out of memory, but 10 year old Android can handle same site fine. It was working fine in iOS 15 also. And works even in old IE11. Every iOS release is horror, what will be broken again... Yes, I am angry and tired of Apple's lack of QA. Trillion dollar company should invest more in quality.

VyseofArcadia 4y ago

It's not limited to Safari. I used to work on a macOS desktop application, and we used to beg our customers to put off upgrading to new macOS versions to buy time to sort out all the undocumented behavior changes.

pveierland 4y ago

"Epiphany Technology Preview" is a WebKit build available for Linux which has been very helpful for testing Safari quirks without having macOS available. https://webkit.org/downloads/ https://webkit.org/downloads/

exabrial 4y ago

Server side rendering… makes things a lot easier.

ribit 4y ago

Apple would certainly benefit from more transparency in these matters, no question. Decoupling Safari updates from OS updates and better communication/tracking of issues and release dates would be a big help At the same time, I don't really see why they should aim to replicate other browser bugs or be responsible for author's idiosyncratic assumptions regarding feature availability. It's a shame that browsers don't have to undergo strict compliance tests and that JavaScript is generally pretty much awful. Under these circumstances the most popular browser (Chrome) is taken as a gold standard and that can't be good for the open web.

AshleysBrain 4y ago
Is it idiosyncratic to assume that two variants of the canvas API support the same things?
- bzzzt 4y ago
  Considering it's a big API with dozens of methods I'd be surprised if two implementations would agree exactly.
  - AshleysBrain 4y ago
    I would have assumed browsers had one internal implementation and exposed it through both APIs. They wouldn't want to have two separate implementations of a large amount of complex code.
- cxr 4y ago
  Yes, and it's a little reckless to even get to a state where, even in the presence of bonafide bugs re non-standard behavior, just showing "a blank screen" when your app dies is a possibility. Add some basic error detection/reporting.
  - AshleysBrain 4y ago
    We did have basic error detection and reporting. For example if it failed to get WebGL in a normal HTML canvas, it would show a "WebGL not supported" error message with some diagnostic details and some advice about what the user could do about it. The problem in this case is a gotcha where there are two ways to access the canvas API, one supporting WebGL, and the other not - a case we never anticipated, nor had happened with any previous browser.

lapcat 4y ago

> More pre-release testing options It's also worth noting that Apple has the bad habit of discontinuing Safari Technology Preview support on older macOS versions faster than they discontinue Safari support on older macOS versions, which results in testing gaps for Safari on those versions. Safari supports the last 3 macOS versions, while Safari Technology Preview only supports the last 2. Take a wild guess which macOS version gets the most new regressions from new Safari versions.

davbryn 4y ago

Other than the CompressionStream API bug, the rest of these could have been avoided by a) not relying on a supported 3D Offscreen Canvas and b) having unit tests so you aren't running prod against a Chromium bug. I understand the stress, but why do they think their product deserves more of Apple's attention than Safari's own product team who undoubtably are working to hard deadlines? This felt like a really, really long whine because they didn't account for certain issues, and I found the 'Apple employee' references to be a little crass

AshleysBrain 4y ago
Sure, mistakes happen, and sometimes it's our fault. But the point is Apple's policies turn what would normally be a routine bug fix in to a total nightmare.
- tokamak-teapot 4y ago
  The suggestions as to what Apple could do to help are all great, but it does look (from here) like there could be ways to tweak application development process to better shield against breakage. It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases. I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier? The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library. The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour? The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but… … the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined. It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.

toyg 4y ago

> "I desperately want Apple to change" Ahh, that's your problem right there, man. Apple don't change for you, for me, or for anyone who isn't called Tim Cook. They'll be out there doing their monopolistic, zero-sum, winner-takes-all, my-way-or-the-highway, straight-outta-the-'90s thing, forever and ever. Apple doesn't care about developers really, as far as the company is concerned they're all little sharecroppers on Steve's garden. Any help you get you should be thankful for, because you have no rights there and never will have. Enjoy your Stockholm syndrome while it lasts.

kingboss 4y ago
Why would they care about developers? They care about their customers. People buy their stuff and you, as a dev, have to support Safari. Whether you like it or not. It's called work.
- toyg 4y ago
  "the beatings will continue and you will like it"

livelielife 4y ago

quality is expensive. if not even apple can afford it, what can we expect from the rest?

danaris 4y ago

In general, I much prefer Safari to other browsers (though Firefox is generally quite good too). However, I've been bitten by what appears to be a WebKit bug in the latest update: using -webkit-mask-box-image to mask a div with an SVG shape no longer seems to respect the other sub-settings for that property, resulting in the mask being, at least for my use case, repeated 4 times within the space that it is supposed to show once. I'm still investigating whether this is something that's actually changed with the not-exactly-spec for this WebKit-specific CSS property, but given the behavior I've already observed when trying to debug it, it certainly seems like a regression.

JoeOfTexas 4y ago

Apple doesn't want webapps to replace their app store. That is why they gimp the hell out of Safari.

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

VWWHFSfQ 4y ago

Safari is easily the worst browser in existence. It is absolutely riddled with bugs. Anything except the most basic functionality you can expect to be a buggy piece of crap for years on end. See webrtc. Hopefully apple gets sued someday so we can stop using their horrible browser

ezfe 4y ago
lol

coldtea 4y ago

We should have static builds and mostly static environments (libs etc). The "evergreen" madness must stop for platforms that are app delivery targets. Or do it like Java does it...

victor96 4y ago

I've always struggled with Safari for it's terrible WebGL implementation. Even had to globally disable anti-aliasing otherwise the app would be unusably slow!

mkl95 4y ago

The browser world is a political, uncoordinated mess. For example WebTransport (an HTTP3 API) has been available on Chromium-based browsers for months, but it's still on "Safari Technology Preview", and Firefox does not support it at all. You can probably find dozens of similar examples over the years.

illiarian 4y ago
> For example WebTransport (an HTTP3 API) has been available on Chromium-based browsers for months, but it's still on Perhaps because WebTransport is still not even anywhere close to be to a web standard? Perhaps because its status is literally, quote: --- start quote --- works in progress inside a W3C Group and are not required to have the consensus of the Group participants. These drafts have not received formal review and are not endorsed W3C. These drafts MUST NOT be cited as W3C standards and may or may not become W3C standards. --- end quote --- Just because it's shipped in Chrome does not make it a standard that every other browser has to implement immediately.
- mkl95 4y ago
  I agree with all your points. I was trying to highlight how dysfunctional it feels from my point of view (backend engineer).

donmb 4y ago

Safari is the new Internet Explorer. We need to face it.

kingboss 4y ago
You meant to write Chrome.

blahblah1234567 4y ago

[dead]

jmull 4y ago

> ...which in turn uses the Compression Streams API when supported > ...uses OffscreenCanvas when available I think it's a mistake to write your code to automatically use new platform capabilities when they become available if you won't have an adequate chance to validate them first. It's just too optimistic to believe a new implementation of a low-level mechanism is going to work exactly the way you need. (1) new things have new bugs; (2) changes are you'll end up depending on implementation details that will vary between different implementations.

jefftk 4y ago
What should you do instead? The alternative is UA-sniffing, and that's worse: https://news.ycombinator.com/item?id=35425549 https://news.ycombinator.com/item?id=35425549
- jmull 4y ago
  > What should you do instead? It's your choice: (1) don't use it; (2) validate it before using it; (3) roll the dice on behalf of your users -- that is, use it without validating it. Don't let religious beliefs around UA-sniffing cause you to screw over your users.
AshleysBrain 4y ago
Browser makers, including Apple, always say to use feature detection - i.e. to use features when they appear to be available. The alternative is user-agent sniffing, which they advise against.
- kevincox 4y ago
  Yeah, this is the problem with feature detection which isn't talked about enough. It is often easy enough to detect whole APIs or even some new methods but correct functionality and optional parameters can be hard or impossible to test. In most cases I have found that feature detection + a blacklist of problematic browsers is often a good compromise. But there is no perfect solution.

jwlake 4y ago

The problem I see with this is people assume that web platforms are platforms like the windows API where Microsoft doesn't like breaking things. It's more like Xcode, where every point release breaks something. You need to design your software and your development pipeline to handle that. Even Google isn't great in this but their continuous release schedule makes it less likely to break things in the wild because they get constant pushback.

circuit10 4y ago
From what I understand the web is meant to be 100% backwards compatible. You should be able to load up the first HTML document ever made and have it still render fine (and it probably would)

rejectfinite 4y ago

>I asked whether the fix would ship in Safari 16.4, and an engineer responded talking about STP. Spanning Tree Protocol? :D

wdb 4y ago

My main problem with Safari is that it is not as convenient to use a developer tool. Sure, its devtools looks pretty but it doesn't have all the useful devtools extensions that Chrome/Edge has. I use Safari as my main content browser but typically switch to Edge for development work. Also when you read W3C specs it can get confusing pretty quickly, vage wordings, etc. Or have MDN documentation that doesn't describe particular behaviour that is defined in the W3C specs etc.

huntedsnark 4y ago

Wherein people who only develop in Chrome cry about web standards

paulddraper 4y ago

> Safari is the last browser in the industry left tied to its OS Isn't that like illegal or something? Like Microsoft got sued for it?

h4ch1 4y ago

How do I test on Safari while building my webapps; I only have a single machine that runs Linux and Windows; and the last Safari release for Windows is from 2015. It was very recent that I came accross a flexbox bug with flex-wrap which had me scrambling to find someone with an iOS device so I could test on Safari and that was pretty painful. PS; I am not very well off, so buying devices merely for testing on a browser seem pretty overkill.

Y-bar 4y ago
Try Epiphany, WPE, or WebKitGTK: https://webkit.org/downloads/ https://webkit.org/downloads/

gloosx 4y ago

And we always wondered, why is it this way? Apple - beautiful hardware, crappy software...

thatsadude 4y ago

Personally, Safari left a bad taste in my mouth. We had to kill a product line because bugs in Safari's AudioWorklet. I don't think audio processing on Web is viable until Safari plays nicely with WebAudio.

pier25 4y ago
Yep. Working on some audio thing and had to desist of using WebAudio because of Safari.