Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views

Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views

I'm seeing inconsistent trackpad scrolling behavior on macOS where the system setting Accessibility → Pointer Control → Trackpad Options → Use inertia when scrolling appears to be ignored by many native applications.

According to the macOS description of this setting, when inertia is disabled, scrolling should stop immediately when the fingers are lifted from the trackpad.

However, in many native or heavily AppKit/SwiftUI-based applications, momentum scrolling remains active even with this option disabled.

Examples include built-in macOS applications and other applications that use native scrolling extensively.

Steps to reproduce

1. Open System Settings → Accessibility → Pointer Control → Trackpad Options.
2. Disable Use inertia when scrolling.
3. Open a native application containing a scrollable view.
4. Perform a reasonably fast two-finger scroll on the built-in trackpad.
5. Lift both fingers while they are still moving.

Expected behavior

As soon as the fingers leave the trackpad, scrolling should stop immediately, since Use inertia when scrolling is disabled.

Actual behavior

In many native scroll views, scrolling continues after the fingers have been lifted, as if inertia were still enabled.

More importantly, there also appears to be an abnormal transition between the direct finger-controlled phase and the momentum phase.

If the fingers are lifted while still moving, the content often makes an additional sudden jump immediately after finger release before continuing its deceleration.

If I stop my fingers completely before lifting them from the trackpad, this jump is either absent or much less noticeable.

This makes scrolling feel uneven even when the frame rate itself is stable.

Additional observations

The behavior seems strongly related to the native macOS scrolling implementation.

Applications or scrolling implementations that perform their own smooth scrolling do not show the same behavior, even on the same machine and display.

This does not look like a general rendering-performance or low-frame-rate issue. The actual scroll trajectory appears incorrect around the transition from the physical gesture to momentum scrolling.

There is an existing Developer Forums report titled “NSScrollView scrolling hitch” describing a very similar jump on the first frame after a scroll gesture transitions into momentum scrolling. In that report, disabling NSScrollView.isCompatibleWithResponsiveScrolling reportedly removes the large jump.

My observation may be related, but there is an additional issue here: the user-facing system setting that is supposed to disable scroll inertia does not appear to disable this momentum behavior in many native scroll views at all.

Questions

• Is NSScrollView expected to respect the system Use inertia when scrolling preference?
• Should NSEvent.momentumPhase events still be generated when this setting is disabled?
• Is there a separate native scrolling path that bypasses this preference?
• Could this be related to responsive scrolling or the transition from the regular phase to momentumPhase?
• Is there currently any workaround for applications or users affected by this behavior?

Environment: MacBook Air with Apple M4, built-in trackpad, macOS 27 Beta (26B5112a).