Full Answer

Detecting Safari is trivial. The user agent string identifies it, and so do feature-detection checks. The problem isn't detection; it's what you do next. Branching your tracking into a Safari path and a non-Safari path doubles the surface area for bugs, and user agents can be spoofed or quietly changed by Apple, so the branch you write today may misfire after the next Safari release.

Apple's Intelligent Tracking Prevention is the reason people reach for detection in the first place. ITP caps cookies set by JavaScript at seven days, and trims that to 24 hours when the visitor arrives from a domain it classifies as a tracker. No amount of browser sniffing changes those limits, because they're enforced at the browser, not negotiated with your script. Treating Safari users as a special case just means you've accepted worse data for roughly a fifth of your traffic.

The approach that holds is to stop depending on the browser. Server-side tracking sets cookies over HTTP from your own server, where the JavaScript cap doesn't apply, and matches conversions using first-party data you already hold. That's one code path for every browser, no detection logic to maintain, and consistent data quality whether the visitor is on Safari, Chrome, or Brave. The real question isn't how to handle Safari differently, it's why your measurement is tied to the browser at all.