It's been a few years since I did frontend dev, but Safari was _absolutely_ the most difficult browser we had to develop for, _especially_ on iOS.
With IE, you can polyfill missing APIs. With Safari, you have to put in extra work to ensure your polyfills override Safari's built-in implementations in all sorts of exciting ways based on which particular Safari version someone is running, because it's _obnoxiously_ common for Safari to have broken or incomplete implementations of web APIs. So if you're just checking for the presence of some particular global, it'll be there...but it'll be subtly broken in various ways. We had constant issues with Safari's implementations of LocalStorage and IndexedDB, and with its weird tendency to "ghost-hover" over elements after a completely different element in the page was tapped/clicked, and that's just what's off the top of my head from when I last did frontend dev consistently (about 7ish years ago).
The only way to repro any of Safari's weird bugs nonsense, of course, was to shell out for a Mac or iOS device. You can't repro any Safari issues on any other, less-expensive platform. It's classic Oracle-style vendor lock-in with their vertically-walled-off tooling and lack of test images.
Except at least Oracle never put out a constantly-broken browser, let alone one that had -- and still has -- monopoly capture of an entire platform.
If you've got a desktop Firefox or Chrome issue, you can launch Firefox or Chrome on a cheap Linux or Windows machine or VM and repro it, and then snapshot the VM for reproducibility.
If you've got a mobile Firefox or Chrome issue, you can launch Firefox or Chrome on a cheap android device (or emulator), and if for some reason it really truly proves to be something Google or Mozilla hasn't implemented correctly _and_ you can't polyfill it...then you can advise users to try a different browser as a workaround.
There _is no_ "different browser" on iOS. If Apple has screwed up yet another standard web API, your users are hosed unless you can get really creative at dancing around their broken pile of crap.
With IE, you can polyfill missing APIs. With Safari, you have to put in extra work to ensure your polyfills override Safari's built-in implementations in all sorts of exciting ways based on which particular Safari version someone is running, because it's _obnoxiously_ common for Safari to have broken or incomplete implementations of web APIs. So if you're just checking for the presence of some particular global, it'll be there...but it'll be subtly broken in various ways. We had constant issues with Safari's implementations of LocalStorage and IndexedDB, and with its weird tendency to "ghost-hover" over elements after a completely different element in the page was tapped/clicked, and that's just what's off the top of my head from when I last did frontend dev consistently (about 7ish years ago).
The only way to repro any of Safari's weird bugs nonsense, of course, was to shell out for a Mac or iOS device. You can't repro any Safari issues on any other, less-expensive platform. It's classic Oracle-style vendor lock-in with their vertically-walled-off tooling and lack of test images.
Except at least Oracle never put out a constantly-broken browser, let alone one that had -- and still has -- monopoly capture of an entire platform.
If you've got a desktop Firefox or Chrome issue, you can launch Firefox or Chrome on a cheap Linux or Windows machine or VM and repro it, and then snapshot the VM for reproducibility.
If you've got a mobile Firefox or Chrome issue, you can launch Firefox or Chrome on a cheap android device (or emulator), and if for some reason it really truly proves to be something Google or Mozilla hasn't implemented correctly _and_ you can't polyfill it...then you can advise users to try a different browser as a workaround.
There _is no_ "different browser" on iOS. If Apple has screwed up yet another standard web API, your users are hosed unless you can get really creative at dancing around their broken pile of crap.