Repository navigation
Proposal - Missing dedicated "Rubber Band" physics in BouncingScrollPhysics causes low iOS fidelity #181752
Description
Activity
Note
It looks like native platforms just use an exponential decay approach for the rubber band animation.
1.mov
Reacted by Dominik Roszkowski- added and removed
on Feb 11, 2026 - changed the title
[-]Missing dedicated "Rubber Band" physics in BouncingScrollPhysics causes low iOS fidelity[/-][+]Proposal - Missing dedicated "Rubber Band" physics in BouncingScrollPhysics causes low iOS fidelity[/+]on Feb 11, 2026 This issue is assigned to @MTtankkeo but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!
Is this one of the issues called out in #103762?
Is this one of the issues called out in #103762?
Yes. This issue specifically focuses on the overscroll bounce behavior mentioned in #103762. While #103762 covers several differences between Flutter and native iOS scrolling physics, this proposal isolates the snap-back phase and suggests using a dedicated simulation for it.
- added a commit that references this issue
on Sep 15, 2026 This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Sep 29, 2026
Currently,
BouncingScrollPhysicsin Flutter uses a singleSpringDescriptionfor both momentum scrolling (flings) and the overscroll recovery (snap-back/rubber band effect).This design forces a compromise:
As a result, Flutter's iOS scroll feel lacks the characteristic "heavy and snappy" rubber band effect found in
UIScrollView, creating an "uncanny valley" effect for users.Video
online-video-cutter.com.mp4
Describe the solution
Native iOS behaves as if it uses a different physical property when snapping back from an overscroll. Flutter should implement a dedicated spring simulation for this specific phase.
I have analyzed the motion curves of native iOS and found that separating the spring logic significantly improves fidelity.
Proposed Logic:
mass: 1.0,stiffness: 1e5 * lambda^2,damping: 100001 * lambda.Note
The constants were specially tuned to achieve exponential damping for the spring.
Additional context
I have measured and compared the scroll position over time between:
As shown in the graph, the current Flutter implementation (Cyan) exhibits a significantly slower recovery compared to native iOS. It lacks the initial 'snap' (stiffness) and takes considerably longer to settle (~0.81s) compared to the native duration (~0.63s), leading to the perceived "floaty" behavior.
In contrast, the new implementation (Brown) closely aligns with the native curve (Blue) in trajectory.
I have a PR ready with this fix.