SwiftUI Performance Gotchas
[LazyHGrid]container is lazy so it takes more time get the view rendered because SwiftUI has to check if each row is visible before rendering it.[…]
What looks unusual is the huge number of updates on my custom views. Some updates also take 5ms or more which when called on the main thread, will block any UI rendering and animations.
[…]
In the following example, I needed a way to highlight the selected day, but passing
selectedas@Statewouldn’t propagate through the view graph. So I made it a binding, which caused all theDayViewsto update when selecting another day (instead of just the two days that actually changed)[…] The solution I found for this was to turn theBindingback into aStateand manually add an.id()to theDayViewthat factors in theselectedproperty.[…]
Two months later, after exhausting all the optimization possibilities, the app finally felt usable. […] I’m not entirely sure if there’s still a lot of performance left on the table for the SwiftUI engineers, but it kinda looks that way from my side. There are some places where the framework seems to be doing a lot of unnecessary work.
Previously:
Update (2023-08-28): Tony Arnold:
My own experience with #SwiftUI on #macOS reflects this author’s experience.
#SwiftUI is easy to build with, but it’s really hard to get it to be performant. There are lots of places where I’m not sure how I would have fixed the performance of UI elements, Lists, etc without knowing how #AppKit works.
