Wednesday, November 30, 2022

SwiftUI Performance Gotchas

Alin Panaitiu (Hacker News):

[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 selected as @State wouldn’t propagate through the view graph. So I made it a binding, which caused all the DayViews to update when selecting another day (instead of just the two days that actually changed)[…] The solution I found for this was to turn the Binding back into a State and manually add an .id() to the DayView that factors in the selected property.

[…]

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.

Comments RSS · Twitter

Leave a Comment