It’s more about how on MacOS, Apple gets to dictate what signal that gesture is going to send to the applications and you can’t configure it to send anything else. So either the application recognizes that signal and it works for every system, or it doesn’t and it doesn’t work for every system.
This makes it a lot more likely that apps are going to recognize that signal so it works for every system. It’s the paradox of choice.
Not really. On macOS, trackpad swipes produce a series of horizontal scroll events, not a simple back/forward event. An app can do whatever it wants with the scroll events. Safari, when the scroll position is at the end of the horizontal outer edge of the document, does an interactive back/forward animation that tracks your fingers while they remain on the trackpad.
> On macOS, trackpad swipes produce a series of horizontal scroll events, not a simple back/forward event.
That's not true. On macOS (and also iOS), you subscribe to gesture recognizers (i.e. swipe gestures), not isolated events, which give you easy access to how users interact with macOS without having to analyze (and likely analyze incorrectly) low-level trackpad interaction.
You could always choose to look directly at events instead, but if you are trying to get the behavior of a widely-used gesture like swiping forward/back, you will get much more accuracy (and happiness from users, and less dev time) by just recognizing them at a high level, which is what Apple expects.
As far as I know you’re supposed to use the NSGestureRecognizer system to recognize this kind of gestures and it’ll automatically make it work like you write. If you try to handle all the events yourself you end up doing a lot of work for probably a worse result.
This makes it a lot more likely that apps are going to recognize that signal so it works for every system. It’s the paradox of choice.