The ScrollView is a critical component on all platforms, but it is a vitally important one on mobile. Essentially all apps on mobile are ScrollViews. The current ScrollView is missing many key features for it to be seriously used on iOS and Android.

1. The scrollview incorrectly uses the term 'viewport' to actually mean 'view content'. A port has a very specific meaning in english and for a scrollview would mean the with and height of the ScrollView component. One way to solve this might simply be to just deprecate all uses of 'viewport' and use 'content' or 'content-container'.
2. Some way of handling the platforms specific behaviours are needed. iOS and Android have some different but critical properties that should be settable. For example when you hit the end of a scrollview on iOS the view has the option to 'bounce'. Sometimes this is disabled, for example when a scrollview is used, but it's content fits within the current view. Or Android has its own 'overScrollMode'. Similar to where bounce is used, but an enum of options that make sense for Android because it doesn't have an actual bounce.
3. ScrollBars are not making anyone happy. Since at least Windows 10, MacOS, Android and iOS there should be 'scroll indicators'. A visible line that shows when the view is being scrolled vertically or horizontally. But it does not take up any content space and will overlap content. Where it can be mouse hovered or on iOS 'long pressed' it can grow into a scrollbar that can be moved to scroll content. However in this mode the scrollbar still overlaps and content and does not change the content width. Finally after a pre set time when not scrolling or having the mouse over the indicator it fades away. Currently none of this standard behaviour exists? Finally desktop needs to support Windows and MacOS 'always show scrollbars' which are permanent scrollbars that do not overlap content and reduce the width/height of the available content.
4. ScrollBars seems to have some performance issues and some of this is in the component itself and some might be in Slint. Within the Scrollbars width, height, x and y seem to have a behaviour on them to compensate for some other performance issue. But this makes the bars visually 'lag' when resizing them. However if these behaviours are turned off and you resize the window you can see the scrollbars fail to render in a timely manner with the window. Instead they lag the resize by a frame or two and can vanish off screen or detach from the side of the window and be left a few pixel away inside the window.
5. There are no easy ways to scroll to specific x/y content position with or without an animation.
6. On all platforms the inertia scrolling doesn't fit the platform native behaviour. iOS has the most complex behaviour with its physics based inertia and over scroll bouncing. However Windows, MacOS, Android, iOS and Wasm all have scrolling that 'feels' sub optimal.
7. There is no 'direction lock'. This is a standard part of ScrollViews since the original iPhone in 2007. It's most often used in the web browser and once you start scrolling in one direction this is 'locked in' and you cannot accidentally start scrolling diagonally or on a different axis.
8. There is no 'paged' support. Often used for carousels. Or the classic 'image gallery'. Where you can scroll and the view will come to rest not on inertia, but per item e.g. per image so one image is always fully on screen.