4 ms·

It's been out for 3 years, but it's honestly still quite rough around the edges. It's like the highways and some roads are paved, but otherwise you're off-roadi

It's been out for 3 years, but it's honestly still quite rough around the edges. It's like the highways and some roads are paved, but otherwise you're off-roading if you need to drive outside of the city. There's a fair bit of UIKit-parity that's still missing, which forces you to create a ViewRepresentable class and do the UIKit bridging yourself (this ranges in complexity, but can definitely present significant challenge depending on the task). This becomes more frequent too for lesser used Apple platforms (watchOS and tvOS). Another place that's lacking that the author doesn't quite dig into is that SwiftUI has no concept of cell re-use at all. The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. With UIKit, cell re-use is a foundational concept that all devs should be utilizing, so it's a bit of a headscratcher that something like this is still missing from SwiftUI by now. To top it all off, as Apple does get SwiftUI up to spec, they are completely resistant to releasing support libraries (or anything along those lines) - so rudimentary UI features/modifiers/etc. that get added years later will only ever support the latest version of iOS and forward. This makes it much more restrictive to work with, as most apps are targeting at least 1 year back and not only the latest major version of the OS.

ericmay 4y ago
> The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. What's the trade-off here for loading versus pre-loading? I guess if you are pre-loading all of that content is loaded into memory from the start, right? I'm guessing there's a performance advantage to have images pre-loaded, but then: 1. Are you doing that dynamically? How would you know what content to pre-load onto the device? My Netflix queue is different from others. 2. If you're loading a lot of content (like scrolling left/right to get new titles) maybe it makes sense to guess/decide what the next cells off the screen might be and load those up as the user scrolls versus loading them for sure, and what about the case where the user scrolls down/up but not left right? You wouldn't necessarily want to load all of that content unless you know the user is going to look at it? Also wondering how for Netfilx this would factor into their algorithms. If I "like" a show when I first load the app if they pre-load the cells then they'll have more compute to re-load all the cells to change their recommendations? Curious about this.
- saagarjha 4y ago
  Preloading in this case is "rendering a cell before you scroll to it".
  - ericmay 4y ago
    Yes but presumably that cell has content fetched from a server right (title, actor names, title image which itself is dynamic based on Netflix A/B testing scheme, etc.)? Wouldn't it be faster to just get the content from the server ad hoc? I'm thinking you'd also potentially have a lot more network overhead if you preload the cells because then if a user doesn't scroll to one of these cells you've created them and they aren't used, and you've fetched server content too. How many cells would you create? I guess maybe Netflix has a default limit per category of titles they would display?
raydev 4y ago
> SwiftUI has no concept of cell re-use at all. This is not true, `List` definitely uses the same approach internally as `UITableView` for cell reuse.

ericmay 4y ago

> The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. What's the trade-off here for loading versus pre-loading? I guess if you are pre-loading all of that content is loaded into memory from the start, right? I'm guessing there's a performance advantage to have images pre-loaded, but then: 1. Are you doing that dynamically? How would you know what content to pre-load onto the device? My Netflix queue is different from others. 2. If you're loading a lot of content (like scrolling left/right to get new titles) maybe it makes sense to guess/decide what the next cells off the screen might be and load those up as the user scrolls versus loading them for sure, and what about the case where the user scrolls down/up but not left right? You wouldn't necessarily want to load all of that content unless you know the user is going to look at it? Also wondering how for Netfilx this would factor into their algorithms. If I "like" a show when I first load the app if they pre-load the cells then they'll have more compute to re-load all the cells to change their recommendations? Curious about this.

saagarjha 4y ago
Preloading in this case is "rendering a cell before you scroll to it".
- ericmay 4y ago
  Yes but presumably that cell has content fetched from a server right (title, actor names, title image which itself is dynamic based on Netflix A/B testing scheme, etc.)? Wouldn't it be faster to just get the content from the server ad hoc? I'm thinking you'd also potentially have a lot more network overhead if you preload the cells because then if a user doesn't scroll to one of these cells you've created them and they aren't used, and you've fetched server content too. How many cells would you create? I guess maybe Netflix has a default limit per category of titles they would display?

raydev 4y ago

> SwiftUI has no concept of cell re-use at all. This is not true, `List` definitely uses the same approach internally as `UITableView` for cell reuse.