There is not really enough info to fully answer your question. I have no clue what you’re building or how (besides “if (isIOS)…”). But that kind of code smacks of how we used to develop web apps in 2005. We generally use libraries and/or frameworks that take into account the subtle browser differences.
My suggestion, don’t relearn the lessons of the last 20 years of web development. Try your hardest to avoid browser-specific code. If you must, wrap it in some kind of abstraction and centralize it. Avoid sprinkling browser-specific code throughout your app. Dig a little deeper into the docs of the library/framework you’re using. Or, if you aren’t using one, do so.
@Reilly
You can always architect your own basic framework if you want to. The important bit of their advice is using abstraction and centralizing all the workarounds in such a way they stay in one easy to manage spot.
I imagine you’re running into issues based on events in JS. There are more than a handful of event systems that handle cross-browser and mobile/desktop. I suggest you swap out your event handling to one of them. Beyond that, using plain JS across different browsers and devices is pretty much the same.
Having built navigation menus that utilize focused elements to hide/show submenus, I was a bit traumatized with how differently Safari manages focus state.
With regard to how I deal with cross-browser compatibility in general, I try to use best practices and approaches that work across browsers. It’s annoying when there is a difference (like focus state management), but most modern browsers are largely compatible nowadays. As one example, I mostly don’t worry about portrait/landscape/device, as responsive design makes it relatively straightforward to create a layout that works across most every device. And whenever possible, I do things with CSS rather than with JavaScript (it is super rare that I need to do some sort of device/viewport detection with JavaScript).
Safari is SO much more capable than explorer was compared to chrome–there is a much smaller gap.
Most people aren’t saying it’s “as bad as IE was”. That’s such a hard bar to clear. It’s just saying “Safari is the new IE” in that it’s analogous to having 1 browser being way behind all other browsers to the point you need to get hacky with specific fixes just for that one browser and you have to do it because so much of your traffic is coming from them, much like how IE was back in the day.
You are correct that Safari is no where near as bad as IE was back then. But you’ll be hard-pressed to argue that it doesn’t bring back very similar vibes. I did plenty of IE hacks, polyfills and what not 15 years ago, and working with Safari now brings back similar feelings, but just less frustrating, usually.
@Jesse
IE was not a problem because it wasn’t capable. It was much more capable than everything else at the time, not to mention it was way ahead of its time in many areas.
Its problem was that it didn’t follow standards - in many cases because it was a pioneer and already had something that did the same thing, but with a different name.
@Jesse
I’m saying that Safari is the new IE and I was coding back when IE 6 was the standard.
It is capable, but Apple is purposely locking features that are widely used in other browsers. Of course the analogy is not 1:1 the same, as we live in different times now, but it’s 2025th and we have a browser that holds back the whole web development efforts. It’s not that Apple can’t develop these features, it’s that they don’t want to. And I’m writing this from a Mac with an iPhone and AirPods.
@Jesse
I have not missed that Era; I survived it lol.
Safari is 90% of our browser-specific bugs on our design system now; updates break stuff and they tend to stick to their own standards instead of the consortium.
@Jesse
The current issues are related to touch-events, such as long-presses and text-boxes, where Apple apparently has some restrictions on bringing the focus to a textbox programmatically due to “security reasons.”
The workarounds end up giving a sour UX experience… for both Android, as well as iOS…
As someone else had noted… I should have used a modern framework.
Luckily, there aren’t … TOO many “gotchas”, but the ones that you’ll stumble across can indeed be infuriating.
How do we deal with it? Fock, we just deal with it. You have to support Safari, as you’ve discovered. So you jump through the hoops. Best of luck buddy, sorry I don’t have any better advice.
I read that you are a Java developer, then you know about classes; use a JavaScript class for each browser to avoid sprinkling if cases everywhere. Now you only need one if case on page load to pick the correct class based on what browser.
Either you use inheritance to share common functionality and override methods when needed and/or class methods can call into a common reusable library or do some custom code.
Add to all your woes users who swear up and down that Safari and Apple are doing it right and you are wrong for daring to go against their design philosophy.
