I believe the the worse performace you were experiencing was due to the Randomness in the view down. SwiftUI View bodies can be evaluated many times, but painting happens only when there is a diff (unless using an ID, these diffing happens by structural identity)
The below setup should give a much better performance compared to random height.
If we were to invalidate the CollectionView layout rapidly and eachtime change the height of cell to a random value, we might end up with similarly bad performance with UIKit as well.
`
private enum Constants {
static let heights: [CGFloat] = (0..<1_000).map { _ in
CGFloat.random(in: 150...300)
}
}
ScrollView {
LazyVStack {
ForEach(Constants.heights.indices, id: \.self) { index in
Just wanted to thank you for a brilliant and extremely useful blog. It's been extremely helpful for my iOS app. I wonder if any of this has improved with iOS 27...? I'm putting off downloading the beta for a while.
I think it's a valid and trivial way to solve any problem which deals with unbounded constraints which is achieving the maximum frame rate possible while plugged in charging. Thus to solve it we generally focus on achieving maximum performance on least finite energy constraint which is low power mode. And we project that conclusion as it is performing it's theoretical best in unbounded mode thus the 120FPS challenge title.
Would be nice to have a series dedicated to optimizing SwiftUI unnecessary redraws.
Did you try LazyVGrid at all? I’ve heard that’s better?
That is a great question. I didn't try grid at all. Maybe I need to write a sequel.
I believe the the worse performace you were experiencing was due to the Randomness in the view down. SwiftUI View bodies can be evaluated many times, but painting happens only when there is a diff (unless using an ID, these diffing happens by structural identity)
The below setup should give a much better performance compared to random height.
If we were to invalidate the CollectionView layout rapidly and eachtime change the height of cell to a random value, we might end up with similarly bad performance with UIKit as well.
`
private enum Constants {
static let heights: [CGFloat] = (0..<1_000).map { _ in
CGFloat.random(in: 150...300)
}
}
ScrollView {
LazyVStack {
ForEach(Constants.heights.indices, id: \.self) { index in
PostCellView()
.frame(height: Constants.heights[index])
.clipped()
}
}
.scrollIndicators(.visible)
}
`
Just wanted to thank you for a brilliant and extremely useful blog. It's been extremely helpful for my iOS app. I wonder if any of this has improved with iOS 27...? I'm putting off downloading the beta for a while.
It sounds like a click-bait, when you titling your article as "The 120FPS Challenge" and then "really going to do the 60fps challenge"
I think it's a valid and trivial way to solve any problem which deals with unbounded constraints which is achieving the maximum frame rate possible while plugged in charging. Thus to solve it we generally focus on achieving maximum performance on least finite energy constraint which is low power mode. And we project that conclusion as it is performing it's theoretical best in unbounded mode thus the 120FPS challenge title.