With web i usually just use the native scroll mechanisms. They are fast, reliable and there is no coding involved.
But, while working more and more in Unity, i have discovered that the available plugins for scroll, even the big ones such as Unity.UI or NGUI are simply awful. I have asked around, and found out that it is like that in most platforms. The physics is plain bad.
I did a bunch of research and i have tried a few solutions, from NGUI scrollView, to web iScroll.js and so on. I have found no solution as perfect as the original Apple's PastryKit. Now, PastryKit is old, deprecated, has no API and as hard to read as hieroglyphs.
But what is important is that while making it, they have managed to exactly recreate the iOS kinetic scroll physics behavior.
I am not trying to implement PastryKit , i am trying to find out how it works. I am trying to understand and replicate.
I am trying to find out the easings/formulas they use and logical conditions they use them in. Apple has a crazy way of writing confusing JS, so even tho i am a full stack developer, i am having a hard time tracing everything down. And i figured few brains is better than one, so lets see, does anyone understand this file? :D
https://github.com/jimeh/PastryKit/blob/master/mobile/dist/PastryKit.js
IN SHORT (so there are no misunderstandings): I am trying to extract a set of physics rules from this file, which i can use as guidelines in order to write my own implementation of scroll on any platform i choose. :)
for example: 'normal' scroll is defined by {>300ms && >10px}, apple uses the following bezier curve when easing the animation of slowdown. cubic-bezier.com/#.25,.46,.1,.94
UPDATE: We solved this a while ago. We discovered how Apple does it's momentum. https://medium.com/homullus/recreating-native-ios-scroll-and-momentum-2906d0d711ad
After many hours of dissecting the algorithm, we concluded that Apple is in fact using magic numbers. And the magic number is: (drumroll) momentum * 0.95.
Basically, while the touch lasts, apple lets you move the screen 1:1.
On touch end Apple would get momentum by dividing number of pixels that the user had swiped, and time that the user has swiped for. If the number of pixels was less than 10 or time was less than 0.5, momentum would be clamped to zero.
Anyways, once the momentum (speed) was known to us, they would multiply it by 0.95 in every frame, and then move the screen by that much.
So idiotically simple and elegant, that it hurts. :)