5 ms·

What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices

What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?

tempodox 4y ago
My thoughts exactly. With the problems reported in the article, I wouldn't want to use SwiftUI, no matter who else declares it “ready for production”.
avianlyric 4y ago
I think scrolling has always been an issue with native apps, it’s a fundamentally hard problems to solve on CPU and memory constraints device (although modern phones are neither). Scrolling allows the user to move through huge amounts of data in a very short period of time, loading that data in, rendering it, then animating, all at 30-60fps is difficult. The reason I suspect people don’t think scrolling was ever an issue (especially on iOS, I doubt Androids will share the same view), is because Apple spent so much time getting it right for the original iPhone. Correctly identifying that scroll behaviour was a kind of “killer app” for touch screens. But in order to make that scroll behaviour so rock solid. They heavily constrained the problem and did bunch of visual tricks to make it appear smoother that it actually was. Most notably, native scroll views generally required that every individual scroll element was an identical size and shape. So you could cheat during the scrolling process by not actually rendering all the content while scrolling, just rendering the UI chrome (which was identical for every scroll item), and loading the content once the scroll velocity was low enough that there was time to load and render the details before they needed to be displayed. The other thing that happened, was basically stopping any other compute from occurring. When you scrolled on the original iPhone (and for many generations afterwards), your phone basically dropped everything and dedicated all its compute to just scrolling the view. Not even code to compute the content of scroll elements was executed, you were expected to have done that before the scrolling started. This was most obvious in Safari, where JS execution was halted, and even page rendering was halted, so if you scrolled beyond the boundaries of what had already been rendered, you just got white. With modern frameworks (and especially the web) there’s been a strong desire to deliver scrolling with a completely arbitrary set of scroll elements, that can all be different shapes, sizes, colours and trigger all manner of background computation. Modern devices are broadly capable of delivering that, but care is needed to exceed the available compute. That’s different from historical native frameworks, where they simply didn’t let people have that kind of flexibility. You got the handful of options the framework gave, and that’s it (which is why older iOS app all had identical scroll UI).
- geraldwhen 4y ago
  UiTableView could use arbitrary height cells and smooth scroll a decade ago, as long as you could compute row height. UiScrollView has always been harder to deal with.
mrtksn 4y ago
I don't think this is true, I recall an interview with the original Instagram people saying that it was not possible to scroll with that many photos and text being live rendered and they had to fake it with something like pre-rendering the UI as an image and scrolling that.
hombre_fatal 4y ago
Scrolling has never been trivial. It’s very hard to build abstractions around it. For example UITableView required quite a lot of boilerplate and manual edge case code. Android’s abstractions have very similar issues. So no, it’s never been a solved problem just like UI abstractions have never been a solved problem, so solved that there’s nothing to improve or explore.
jb1991 4y ago
Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the battery as your device will doing orders of magnitude more work than necessary. You don't encounter lists of this length as often on web apps, but the same issue would apply if you did -- why do you think infinite scrolling only loads a few rows at a time until you scroll further? And how many times have you been on an "infinite scroll" web and as you scrolled, you had to wait for it to do the work for the next scrollable content. Happens to me often. Now take all those concerns and bundle them in a UI that is suppose to manage all this for you automatically via declarative behavior, and you can see why it's not as trivial as you suggest.
- WA 4y ago
  Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.
  - jb1991 4y ago
    Well at least what you describe would be sitting on a GPU using all the technologies (both hardware and software) developed for precisely that purpose. Also keep in mind that the battery drain using those technologies to play a game does not scale to a normal mobile app when people expect their phone to be available all day.
  - avianlyric 4y ago
    Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of course, stutter and jump if they need to dynamically load new content in, but can’t quite get it into working memory before it’s needed for rendering, usually resulting in entire frames being delayed. Scrolling on the other hand is a very sequential task, if you don’t want to have a loading screen before displaying the list. The location of every item in the list depends on the location and size of the item before it, those data dependencies make parallelism pretty close to impossible. Made worse when each item is loaded on demand, and needs to execute code to determine how it should be rendered. Of course, you could load all your scroll data into memory, precompute all the needed render parameters, arrange the results for parallel rendering, then have blazing fast and stable scrolling. Just like a video game loading screen, but then every scrollable view would have a loading screen…
veidr 4y ago
That isn't true; scrolling (and resizing) was a performance sinkhole for all kinds of apps that used the native table views (NSTableView and NSOutlineView), for many generations of Mac OS X. They eventually added enough optimizations and performance cutouts to make it pretty easy to not fall in the hole with your app, so it hasn't been a problem with AppKit (or its younger 85% clone, UIKit) for a long while. But I'm not surprised to hear Apple's much newer and not-very-related UI toolkit still has lots of those problems. That's one of the problems when not many developers actually use a technology — it's not just a popularity contest, having lots of users who complain is how you find a lot of the bugs and performance issues in your UI toolkits and app frameworks. So lack of popularity often does mean there are probably a lot of those.
Pulcinella 4y ago
Scrolling on SwiftUI is extra bizarre because I often observe weird micro stutter. A scroll view with perfectly static text that never updates will sometimes scroll at what seems to be ~45fps. But really it’s more like it’s randomly dropping 1 out of every 4 or 5 frames or so. It also seems to be related to dragging the scroll view, because programmatic scrolling can be very smooth. (Also SwiftUI was weirdly capped at 60hz and couldn’t do 120hz until iOS16.2. Doesn’t make me confident that SwiftUI will ever get a lot of development love from Apple if it took over a year for SwiftUI to support a flagship feature from the iPhone).

tempodox 4y ago

My thoughts exactly. With the problems reported in the article, I wouldn't want to use SwiftUI, no matter who else declares it “ready for production”.

avianlyric 4y ago

I think scrolling has always been an issue with native apps, it’s a fundamentally hard problems to solve on CPU and memory constraints device (although modern phones are neither). Scrolling allows the user to move through huge amounts of data in a very short period of time, loading that data in, rendering it, then animating, all at 30-60fps is difficult. The reason I suspect people don’t think scrolling was ever an issue (especially on iOS, I doubt Androids will share the same view), is because Apple spent so much time getting it right for the original iPhone. Correctly identifying that scroll behaviour was a kind of “killer app” for touch screens. But in order to make that scroll behaviour so rock solid. They heavily constrained the problem and did bunch of visual tricks to make it appear smoother that it actually was. Most notably, native scroll views generally required that every individual scroll element was an identical size and shape. So you could cheat during the scrolling process by not actually rendering all the content while scrolling, just rendering the UI chrome (which was identical for every scroll item), and loading the content once the scroll velocity was low enough that there was time to load and render the details before they needed to be displayed. The other thing that happened, was basically stopping any other compute from occurring. When you scrolled on the original iPhone (and for many generations afterwards), your phone basically dropped everything and dedicated all its compute to just scrolling the view. Not even code to compute the content of scroll elements was executed, you were expected to have done that before the scrolling started. This was most obvious in Safari, where JS execution was halted, and even page rendering was halted, so if you scrolled beyond the boundaries of what had already been rendered, you just got white. With modern frameworks (and especially the web) there’s been a strong desire to deliver scrolling with a completely arbitrary set of scroll elements, that can all be different shapes, sizes, colours and trigger all manner of background computation. Modern devices are broadly capable of delivering that, but care is needed to exceed the available compute. That’s different from historical native frameworks, where they simply didn’t let people have that kind of flexibility. You got the handful of options the framework gave, and that’s it (which is why older iOS app all had identical scroll UI).

geraldwhen 4y ago
UiTableView could use arbitrary height cells and smooth scroll a decade ago, as long as you could compute row height. UiScrollView has always been harder to deal with.

mrtksn 4y ago

I don't think this is true, I recall an interview with the original Instagram people saying that it was not possible to scroll with that many photos and text being live rendered and they had to fake it with something like pre-rendering the UI as an image and scrolling that.

hombre_fatal 4y ago

Scrolling has never been trivial. It’s very hard to build abstractions around it. For example UITableView required quite a lot of boilerplate and manual edge case code. Android’s abstractions have very similar issues. So no, it’s never been a solved problem just like UI abstractions have never been a solved problem, so solved that there’s nothing to improve or explore.

jb1991 4y ago

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the battery as your device will doing orders of magnitude more work than necessary. You don't encounter lists of this length as often on web apps, but the same issue would apply if you did -- why do you think infinite scrolling only loads a few rows at a time until you scroll further? And how many times have you been on an "infinite scroll" web and as you scrolled, you had to wait for it to do the work for the next scrollable content. Happens to me often. Now take all those concerns and bundle them in a UI that is suppose to manage all this for you automatically via declarative behavior, and you can see why it's not as trivial as you suggest.

WA 4y ago
Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.
- jb1991 4y ago
  Well at least what you describe would be sitting on a GPU using all the technologies (both hardware and software) developed for precisely that purpose. Also keep in mind that the battery drain using those technologies to play a game does not scale to a normal mobile app when people expect their phone to be available all day.
- avianlyric 4y ago
  Completely different problem. Rendering millions of polygons is almost trivial to parallelise, and there’s plenty of hardware around that’s capable of providing the needed parallel compute. You’ll note that games have loading screens, those exist so the games can get everything it needs into working memory, order it to enable extreme levels of parallelism. And only then do you get buttery smooth 60fps, and games, of course, stutter and jump if they need to dynamically load new content in, but can’t quite get it into working memory before it’s needed for rendering, usually resulting in entire frames being delayed. Scrolling on the other hand is a very sequential task, if you don’t want to have a loading screen before displaying the list. The location of every item in the list depends on the location and size of the item before it, those data dependencies make parallelism pretty close to impossible. Made worse when each item is loaded on demand, and needs to execute code to determine how it should be rendered. Of course, you could load all your scroll data into memory, precompute all the needed render parameters, arrange the results for parallel rendering, then have blazing fast and stable scrolling. Just like a video game loading screen, but then every scrollable view would have a loading screen…

veidr 4y ago

That isn't true; scrolling (and resizing) was a performance sinkhole for all kinds of apps that used the native table views (NSTableView and NSOutlineView), for many generations of Mac OS X. They eventually added enough optimizations and performance cutouts to make it pretty easy to not fall in the hole with your app, so it hasn't been a problem with AppKit (or its younger 85% clone, UIKit) for a long while. But I'm not surprised to hear Apple's much newer and not-very-related UI toolkit still has lots of those problems. That's one of the problems when not many developers actually use a technology — it's not just a popularity contest, having lots of users who complain is how you find a lot of the bugs and performance issues in your UI toolkits and app frameworks. So lack of popularity often does mean there are probably a lot of those.

Pulcinella 4y ago

Scrolling on SwiftUI is extra bizarre because I often observe weird micro stutter. A scroll view with perfectly static text that never updates will sometimes scroll at what seems to be ~45fps. But really it’s more like it’s randomly dropping 1 out of every 4 or 5 frames or so. It also seems to be related to dragging the scroll view, because programmatic scrolling can be very smooth. (Also SwiftUI was weirdly capped at 60hz and couldn’t do 120hz until iOS16.2. Doesn’t make me confident that SwiftUI will ever get a lot of development love from Apple if it took over a year for SwiftUI to support a flagship feature from the iPhone).