I think I see what you want, but I'd be worried about modifying a UI action that is otherwise mandated by the system. Point is that Apple has already trained users to expect the UI to perform in a prescribed manner (see 'feels natural' below). Changing it might violate that flow. Not being able to casually disable just auto could be that mandate in action.
In practice, w/that example, as you point out, the user can already control scrolling. That said, and without testing, I can imagine an example where you fully DIY an additional layer above the system UI that captures the user's touches and moves a child view's inbounds contents at will, under your full control. But whether or not app review would complain is unknown.
A scroll view allows users to browse content, such as text in a document or a collection of images, that’s larger than the visible area. As people swipe, flick, drag, tap, and pinch, a scroll view follows the gesture, revealing or zooming content in a way that feels natural. A scroll view itself has no appearance, but does display transient scrolling indicators as people interact with it. A scroll view can also be configured to operate in paging mode, where scrolling reveals an entirely new page of content rather than moving around the current page."
Perhaps if you can provide better context to your specific goal (map app, game, product catalog, reader, etc.), someone can offer a suggestion that satisfies you and Apple.
That is not exactly what you are looking for, but you could slow down scrolling:
scrollView.decelerationRate = UIScrollView.DecelerationRate.fast
for more sophisticated behavior.