I really appreciate your efforts and knowledge in responding to these forums, and this question in particular. That said, the other metric (besides performance) is ease of coding. One of the advantages of SwiftUI is its ease of coding. WWDC 2020 "Introduction to SwiftUI" spent some time comparing SwiftUI to UIKit, and came to the conclusion that for UIKit "the way we manually manage dependencies today is really hard". There were several other comments about how much UIKit required the coder to "have to hold in your head", and how SwiftUI reduces this cognitive load. Great. I've been nattering on and on for years about how complexity causes errors. But now complexity has been (re)introduced to SwiftUI in order to increase performance. Now we are required to know when to use Lazy Stacks and when not to. Again, thanks for your answer, but I was unable to use it to figure out how to improve my code. It doesn't answer the question about when to use Lazy Stacks and when not to. You gave a few reasons why we should differentiate between Lazy and NonLazy stacks. You gave a brief rule of thumb about when to use Lazy ("if the highest level ScrollView in a view hierarchy directly wraps an HStack or VStack, then that’s a good candidate for a lazy stack"). In addition, even if I understood when to be Lazy and when not to, I still have to retain that knowledge. Why put that cognitive burden on the overworked, confused coder? Why not make all stacks Lazy stacks, and implement the above rule of thumb in the compiler? If the above rule of thumb is insufficient, what are the exact rules I need to maintain in my (limited) headspace for Lazy Stacks?