Just published my first Swift article of 2023! 🎉

This one is about how the content offset (or scroll position) of a SwiftUI ScrollView can be observed without requiring any UIKit bridging. Very useful when implementing things like collapsable headers, or when performing other kinds of scroll position-dependent operations 👍

https://www.swiftbysundell.com/articles/observing-swiftui-scrollview-content-offset

Observing the content offset of a SwiftUI ScrollView | Swift by Sundell

How the content offset of a SwiftUI ScrollView can be observed without bridging to UIKit.

Swift by Sundell
@johnsundell I’ve done something like this in the past, but it resulted in really bad scroll performance for complex scroll view content. In short, we profiled it and realized that with every update of the offset, we were causing cascading body re-computations. Do you know if this variant has this problem?
@schrismartin yeah that’s a typical tradeoff with SwiftUI in general, since every time any view state is changed, that view’s body needs to be re-evaluated. So same thing here. Those performance issues can often be addressed, though, using tools like EquatableView, and by ensuring that ObserableObjects aren’t re-instantiated. But for very complex scroll view layouts that also adapt according to the content offset, it might be worth using UIScrollView instead.