Safari releases are development hell

https://www.construct.net/en/blogs/ashleys-blog-2/safari-releases-development-1616

by AshleysBrain • 3 years ago

318 274 3 years 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• 3 years 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.

bzzzt3• 3 years 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• 3 years 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/in...

pier253• 3 years 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.

timeimp• 3 years 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• 3 years 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• 3 years ago

I think so

squaresmile• 3 years 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.

Grieverheart• 3 years 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• 3 years ago

I don't think this is still the case with Chrome 110 and higher that sleeps/suspends inactive tabs.

Y-bar3• 3 years ago

For me, a Firefox user, I don't share your point of view. I see a lot more "optimized for Chrome" or "run this in Chrome because that is the only browser we decided to support" because Google decided on implementing some feature of their own making. Never have I been hindered in my web browsing by something tailored to Safari.

masklinn• 3 years ago

Yeah the kids don’t remember the bad days.

It was not just that IE was broken in all sort of very odd ways, or that it was incompatible with the rest (and standard), or that it was essentially a monopoly.

It was all three. So a site built for IE would not work at all in other browsers if it used anything remotely advanced (and advanced back then was users events), you had to support IE to live (on anything but demo site), and doing so was hell on earth because the bugs went from top to bottom (the browser’s memory management had to be worked around, and there were no memory profiler, hell the debuggers only worked half the time).

Not that it’s any fun encountering a buggy browser, even less so when a feature is so broken you’d be better off if it were not supported and just did nothing or used a fallback and you now have to coerce it into that, and it does seem to be a recurring issue of safari.

But it’s no IE, at this point you’d need malice aforethought to get there.

masswerk• 3 years ago

Also, typed arrays being slower than normal arrays for years on Chrome (and therefor pretty useless), Chrome breaking audio buffer playback for several major iterations, etc. This "whatever Chrome does is the standard" attitude reminds somewhat of the days of IE6 devs.

NovemberWhiskey• 3 years ago

Nah. It's more like "Chrome is the new IE 6": it's the default target for everyone and you'd better be bug-for-bug compatible or else.

philistine• 3 years ago

It’s exactly what the article describes. Because Safari was correctly implementing something and not reproducing a Chrome bug, the dev is asking Apple to change their release structure to reduce their stress.

This is the endgame of a monopoly. Other people start demanding others stop fairly competing with you.

mason55• 3 years ago

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'd like to think I'm a competent dev.

I use Safari as my daily driver because the difference in performance/battery life on Apple silicon is worth whatever small incompatibilities I run into. It just doesn't ever impact me on a day-to-day basis in the way that performance and battery life do.

Good engineering is all about trade-offs and this is one that doesn't even require a second thought for me.

myspy• 3 years ago

I use Safari as my main browser too. The features that link it between Mac and iPhone are very nice and easy to use.

What also is cool in Safari is to zoom into a page so that everything gets bigger which makes it easier to read text or view pictures (not sure if this is the normal zoom a site has, or something on top OS wise). But a lot of sites are breaking that behaviour now, which results in either not being able to zoom or elements overlapping in weird ways, text not staying where it should. I wonder what CSS stuff is used there.

jojobas2• 3 years ago

Why would they care what devs do? They are an infinitesimal minority. Their product are status/convenience for "normal" people, and they will use whatever browser Apple ships and if something breaks it's anybody else's fault. "If your Mac can't run it you don't need it".

ezfe2• 3 years ago

raises hand I think I'm a competent developer and I use Safari primarily. The number of times I've tried to build something and found out that Firefox or Chrome got halfway through the spec and then stopped working on it isn't 0 either. It goes both ways.

robertoandred• 3 years ago

No real developer thinks Safari is comparable to IE, that's just something Google fans say.

sunaurus• 3 years 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• 3 years ago

This wouldn’t have helped the author, though, since their issues were contingent on what fixes were included in the actual releases.

ricardobeat3• 3 years 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.

saagarjha4• 3 years ago

Ok, but that doesn't actually help when you run into WebKit bugs.

giraffe_lady• 3 years 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• 3 years 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.

ChrisMarshallNY2• 3 years ago

Currently, my LET (Low-End Test) device is an original SE, running iOS 15. I also have a 4th gen iPad Mini, and an iPhone 8Plus (for the screen).

mouzogu• 3 years ago

"so by ensuring my code is compatible with Safari, I'm basically guaranteeing full compatibility with everything."

Ah the sweet nectar of naivety. Godspeed to you.

Can't believe I've been a webdev 15 years. What's old becomes new, except for me that is....

illiarian19• 3 years ago

"Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds."

https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

coldtea7• 3 years ago

Well, I've been a webdev for more, and he sounds prudent, not naive.

rimliu• 3 years ago

And I have been for 25 years. Looks you still have some learning to do.

Waterluvian• 3 years ago

This seems wise. It’s akin to developing for the slowest machine. I’m tempted. Though developing on Chrome just feels the best given the tools.

bioemerl10• 3 years ago

This statement here should be seen as a crimson flashing red flag waving as madly as a person can wave.

"Want global web compatibility? Fuck you buy a Mac"

-Apple

jojobas2• 3 years ago

Well who wouldn't want to be in position to dictate that your bugs have to be other peoples' specs?

illiarian19• 3 years ago

"Want global web compatibility? Fuck you buy a Mac"

Still better than "whatever we throw over the wall is now a standard" that Chrome has, and you can see people clamouring for those on HN.

coldtea7• 3 years ago

Better than the alternative: leave it to Google to dictate whatever they like as a standard and ship it.

flatiron2• 3 years ago

https://github.com/kholia/OSX-KVM also works (also not very legal)

kevincox2• 3 years ago

To me this is the biggest difference between Safari and IE/Edge. Microsoft provided free VMs that you could download with all supported versions of IE and Edge. So you could test sites and investigate bug reports. With Safari you can't debug an issue without expensive Apple hardware. I was happy to keep my sites compatible with IE and Edge (maybe not constant testing but some manual testing after big changes). However no way I was going to do that work for Apple when they didn't help out at all.

(The Edge VMs don't appear available anymore but since Edge is cross-platform and free it should be easy enough to install it in your own VM or on your workstation.)

fHr• 3 years ago

2023 state of frontend testing still scares me

folkrav2• 3 years ago

Whenever I look at the frontend QA loop vs. the backend at the places I've worked at, I'm glad I work in machine readable, typed, easier to test API land.

folkrav2• 3 years ago

Anecdotally, about half the frontend bugs that I see go through our JIRA at work seem Safari/iOS specific lol

bzzzt3• 3 years ago

Probably because all the frontend people are using Chrome, so those bugs were already fixed.

jalk• 3 years ago

And about the other half is for chrome, and the rest is for all other browsers or what?

coldtea7• 3 years ago

Seeing that Safari/mac/iOS and Chrome/blink (so also Edge/Opera) are the only game in town adoption wise (FF has fallen way below), how else would it be?

capableweb2• 3 years ago

That would be a helpful process for more people to maybe look into, if it wasn't for the fact that most computers can't even run Safari, as it's not available on their platform, less than 10% worldwide who browse the web are using macOS.

coldtea7• 3 years ago

A hella lot more are using iOS though.

Eric_WVGG• 3 years ago

You're not wrong (I develop that way as well), but I'd wager that like me you're not neck deep in service workers and WASM and a "compression streams API."

This isn't a Chrome vs Safari issue (Safari is better, of course), it's the fact that browser development suffers from Apple's corporate wall of silence. In this case, devs literally suffering.

ohgodplsno• 3 years ago

I switched to an Internet Explorer-first approach for web development, and it has reduced my problems considerably. In fact, I make my websites assume they will be viewed in a 640x480 viewport.

I'm basically guaranteeing full compatibility with everything, because everyone has to comply with IE's behaviour. After all, I put a "Best viewed in Internet Explorer", this way if it fails, people blame their browser and not me.

meindnoch• 3 years 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• 3 years 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• 3 years 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?

theodorejb4• 3 years 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• 3 years 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-offsc...

lapcat8• 3 years ago

TL;DR: they are mad because of:

This is not a good summary of the article. They're aren't mad at the bugs, they're mad at how Apple handles Safari releases (as seen in the very title of the article).

If you read the "how to fix it" section, the fixes are "transparency", "update Safari independently of the OS", "more pre-release testing options", "communication".

lucideer4• 3 years ago

Release schedules &c. aside, they have no argument if they're complaining about the Safari team's "communication". The diligence from the Safari team in responding to those bug reports is not something I've seen from other browsers vendors.

tgv3• 3 years 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.

tough• 3 years ago

Man is free to make up their own personal hells

throwayyy479087• 3 years 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.

lucideer4• 3 years 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.

pier253• 3 years ago

If you're a game engine or just have a product focused on realtime graphics, issues with requestAnimationFrame can just destroy your product.

z3t4• 3 years 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)

rippercushions• 3 years 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://chromiumdash.appspot.com/schedule

Y-bar3• 3 years 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%20arm6...

ducknalddon• 3 years 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.

I don't. If your web site doesn't support Safari then I will take my business elsewhere.

theodorejb4• 3 years 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.

Unfortunately iOS users don't have this option.

luckylion• 3 years 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.

Is there any statistic to back that up that safari users first blame their browser and switch to a different one before they give up on a site? And why are they still using safari in the first place if it happens so frequently that they made a habit out of switching browsers? I'm not convinced.

sccxy6• 3 years 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.

HAHAHA.

Are you not aware that every browser in iOS is basically wrapper for Safari?

New bugs in Safari will break other browsers also.

hk1337• 3 years 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.

I haven't found that to be entirely true. Users will definitely have multiple browsers installed but that's usually because someone in their IT department had them install a second browser for testing. Most users will use one browser the entire time and need someone to tell them to try it in another browser if it's not working.

jeroenhd3• 3 years ago

This is also my experience, but people do tend to migrate to a different browser entirely if their workflows don't work in the other browser.

If every website works in Chrome and most websites work in IE, users will switch to Chrome. Same with Safari. If the thing you're building is interesting enough for users to return to it, the unsupported browser may just stop getting used all together, especially if multiple sites break at the same time (i.e. when Safari broke WebAssembly support).

realusername3• 3 years ago

Most browsers have a beta/review release, you can run your test on that, once per day, automatically.

Okay, how do I run headless Safari in a CI exactly? And how do I run Safari mobile in a CI since it has different bugs than the other one sometimes?

I'm sure some people hacked some stuff together with ducktape but you are far far outside the supported development cycle of this software.

bioemerl10• 3 years ago

Most users will have other browsers installed along with Safari.

Apple literally goes out of their way to deny you the right to use another browser engine on their mobile phones.

whywhywhywhy3• 3 years 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.

macguillicuddy• 3 years 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

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.

saagarjha4• 3 years 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.

miohtama2• 3 years 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.

jefftk6• 3 years ago

When I was working on open source at Google this was also something we had to be very careful with: you don't want to make promises you can't keep. But this wasn't as strict as what Apple does, and vague estimates were allowed.

For example, here's what Chrome does: https://chromiumdash.appspot.com/schedule. All the dates are tentative and sometimes slip, but an engineer can point people to it, say "fix X made the branch cutoff for release NNN", and you can get a pretty good prediction for when X will get to what sort of devices.

bob1029• 3 years ago

We've had a similar constraint issue on getUserMedia where it will return the lowest possible resolution for video by default instead of something more pedestrian. Setting exact constraints never seems to work correctly either. Ideal gets closer.

It took us over a year to realize this was the root cause for 2D barcode scanning issues - we had an information-theoretic failure mode due to the low resolution.

Etheryte2• 3 years ago

Fyi I don't think this issue is limited to Safari, I've seen the exact same problem in some third-party apps which, as far as I can tell, look and feel native.

vially• 3 years ago

Do you mean third-party apps on iOS? All web-based iOS apps are powered by Webkit/Safari so it makes sense that they all share the same bugs.

depressedpanda• 3 years ago

and Safari updates are tied to OS releases.

Safari is the last non-evergreen browser. As long as Apple insists on this policy it doesn't matter how good a job the WebKit team are doing; they're still hamstrung by the outdated release policy Apple enforces.

Luckily, soon Apple will be forced to allow alternative browsers. At that point, I hope Apple will spend some of its trillions on actually improving Safari, in order for it to stay relevant and competitive.

musicale• 3 years ago

actually improving Safari, in order for it to stay relevant and competitive

Safari seems to be the last bulwark against a Chrome-only web driven by features of the week.

Full Chrome/Chromium on iOS could very well end that, and I'm not thrilled at the prospect.

Personally I appreciate Safari's resistance to constant featurism in general, and conservative approach to features that are likely to compromise power usage or privacy. I have little desire for web apps to reach complete feature parity with native apps, or to have complete access to all hardware and OS features. Many developers may hate it and want to usher us into Google's PWA future, but I'm absolutely fine where things are right now. And I certainly don't want to have to use Chrome/Chromium for everything.

Lastly, as a developer, I don't like building on quicksand. And yet that's often what it feels like using web/JavaScript frameworks and browsers that change from week to week.

Nonetheless, OP's recommendation that Apple note which versions of Safari a certain bug is fixed in seems like a very good idea that should be adopted.

kouteiheika2• 3 years 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• 3 years 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-robo... [2] https://www.theverge.com/2021/10/7/22715179/firefox-suggest-... [3] https://blog.mozilla.org/advancingcontent/2015/05/21/providi...

smoldesu• 3 years 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

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.

kouteiheika2• 3 years 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

tgv3• 3 years ago

And I hope they don't have to. Opening it up will move the entire web environment to Chrome, and Google's dominance.

I can just tell all of my users that Safari is unsupported and that they should switch to Firefox.

What do you need from a browser that Safari doesn't support? In my experience, everything except obvious bugs has an easy work-around that is supported by the other platforms.

jeroenhd3• 3 years ago

What do you need from a browser that Safari doesn't support?

For me: a download for Linux or Windows so I can test with the browser. A macOS VM, like Microsoft used to provide for IE development, would also be acceptable.

All my personal projects and even professional projects haven't supported Safari for this very reason.

alkonaut• 3 years 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• 3 years 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.

realusername3• 3 years 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.

vlovich1233• 3 years 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.

scarface742• 3 years 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.

411111111111111• 3 years ago

Android is actually much closer to being a monopoly

Thats only true outside of the US though. iOS is >60% in the USA.

cxr6• 3 years ago

I've run into a pretty ridiculous Chrome bug:

  let f = document.createDocumentFragment();
  f.appendChild(document.createElement("div"));
  f.firstChild.outerHTML = (`<a href="https://bugs.chromium.org/"></a>`);

Fails because a fragment "is not an element node", a completely bogus error. No idea if it fails in Safari, too, since I don't have a Mac anymore, but I'd guess so, since this reeks of the type of corner-cutting that WebKit was guilty of while swimming in accolades for being a fast, standards-compliant browser engine (in contrast to e.g. Gecko).

lapcat8• 3 years ago

a completely bogus error

How is it bogus? outerHTML is an attribute of Element https://developer.mozilla.org/en-US/docs/Web/API/Element/out... and DocumentFragment is not an Element https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...

No idea if it fails in Safari, too

It does.

Have you considered that it's just a Gecko quirk that it happens to work in Firefox? Where do the standards say it ought to work?

kingboss4• 3 years ago

Laughable take. When there was only IE6 people complained. Now that there is more than one people complain that they have to test their stuff more and wish to go back to one browser to rule them all. You don't like testing? How hard can it be to test on the top 3-4 browsers? Maybe it's not wasted dev time, it's called work? Maybe software industry isn't for you... Sidenote: Why so many snowflakes on HN? Too much entitlement or is it the easy money? In what job is it considered acceptable to not test on half the devices in the world?

chatmasta• 3 years ago

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

ricardobeat3• 3 years 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?

saagarjha4• 3 years ago

Aren’t Safari releases held back until a TP is free of critical issues?

No. Safari releases ship in lockstep with iOS releases.

ilikehurdles2• 3 years ago

Not so on MacOS.

lucideer4• 3 years ago

This exactly.

Given the diligence of the Safari team - especially in the face of the extremely lazy first bug report - it's kinda wild that this person thought it appropriate to post such a negative angle.

The second bug report wasn't even a bug: Chrome & Safari had implemented an unspecified part of the spec. differently to each other (specifically the implementation behind generating client IDs for fetch events in web workers -vs- the main window). The op is relying on an unspecified implementation detail for their app to work. Yet the Safari team actively treat it as a bug in an attempt to be more generally compatible with Chrome.

My takeaway from actually reading through the content of the post is that the Safari devs are responsive and approachable, even even the bug reporter is lazy. Which is more than can be said of many other browsers projects.

AshleysBrain11• 3 years ago

I credited the Apple developers with doing a good job in the blog. The problem is Apple's policies end up turning a routine bug fix in to a total nightmare.

sccxy6• 3 years ago

It is very hard to properly debug iOS bugs also.

"a problem repeatedly occurred" and page crashes all the time.

Only in Safari iOS 16. Worked in iOS 15. Works even in IE.

What kind of bug report can you make out of it?

mh-• 3 years ago

Attaching Safari Dev Tools from a Mac to the iOS device should surface those errors, in my experience.

sccxy6• 3 years 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• 3 years 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• 3 years 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/

exabrial• 3 years ago

Server side rendering… makes things a lot easier.

ribit• 3 years 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.

AshleysBrain11• 3 years ago

Is it idiosyncratic to assume that two variants of the canvas API support the same things?

bzzzt3• 3 years ago

Considering it's a big API with dozens of methods I'd be surprised if two implementations would agree exactly.

cxr6• 3 years 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.

illiarian19• 3 years ago

It's a shame that browsers don't have to undergo strict compliance tests

There are compliance tests, and it's a thankless job to create and maintain them that some people do. But browsers are bigger than some OSes now. It's almost impossible to create comprehensive compliance tests that cover everything.

lapcat8• 3 years 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• 3 years 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

AshleysBrain11• 3 years 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• 3 years 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.

toyg2• 3 years 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.

kingboss4• 3 years 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.

toyg2• 3 years ago

"the beatings will continue and you will like it"

livelielife• 3 years ago

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

danaris• 3 years 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• 3 years ago

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

TheCoreh• 3 years 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• 3 years 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/

afavour• 3 years 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.

jeroenhd3• 3 years 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• 3 years 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

ezfe2• 3 years ago

lol

coldtea7• 3 years 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• 3 years 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!

mkl952• 3 years 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.

illiarian19• 3 years 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.

mkl952• 3 years ago

I agree with all your points. I was trying to highlight how dysfunctional it feels from my point of view (backend engineer).

donmb• 3 years ago

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

kingboss4• 3 years ago

You meant to write Chrome.

jmull2• 3 years 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.

jefftk6• 3 years ago

What should you do instead? The alternative is UA-sniffing, and that's worse: https://news.ycombinator.com/item?id=35425549

jmull2• 3 years 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.

AshleysBrain11• 3 years 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.

kevincox2• 3 years 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• 3 years 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• 3 years 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• 3 years ago

I asked whether the fix would ship in Safari 16.4, and an engineer responded talking about STP.

Spanning Tree Protocol? :D

wdb2• 3 years 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• 3 years ago

Wherein people who only develop in Chrome cry about web standards

paulddraper• 3 years 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• 3 years 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-bar3• 3 years ago

Try Epiphany, WPE, or WebKitGTK: https://webkit.org/downloads/

gloosx• 3 years ago

And we always wondered, why is it this way?

Apple - beautiful hardware, crappy software...

thatsadude• 3 years 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.

pier253• 3 years ago

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

Safari releases are development hell

Related Stories