SwiftUI re-runs body whenever observed state changes, then diffs the new view tree against the old one and updates only what differs. Performance problems come from making that diff do too much work: unstable , over-broad , and expensive computations. Fix it by controlling identity, scoping state, and keeping cheap.
bodybodySwiftUI matches views across renders by identity. For lists this is the id; if the id is unstable, SwiftUI throws away and rebuilds the view (losing state and animations) instead of updating it.
// BAD: array index as id — reorders/inserts break identity, full rebuild
ForEach(items.indices, id: \.self) { i in Row(items[i]) }
// GOOD: stable identity tied to the data
ForEach(items) { item in Row(item) } // items: Identifiable, stable id
An ObservableObject re-renders every view observing it whenever any @Published property changes. Split large models, or move to the Observation framework (@Observable, iOS 17+), which tracks per-property reads so a view only re-renders when a property it actually used changes.
@Observable final class Feed { // iOS 17: fine-grained dependency tracking
var unreadCount = 0 // a view reading only .posts won't re-render on this
var posts: [Post] = []
}
body runs often, so never do heavy work inline:
var body: some View {
List(sortedItems) { ... } // BAD if sortedItems sorts on every render
}
// GOOD: compute derived data in the model, not in body
LazyVStack/List for large collections so off-screen rows aren't built..equatable() or EquatableView to short-circuit diffing on stable subtrees.AnyView erases type identity and defeats structural diffing — avoid it in hot paths.On a 120Hz ProMotion display you have ~8ms per frame; a body that sorts a large array or re-renders an entire list drops frames and janks scrolling. Senior interviews probe view identity and observation scope because that is where real SwiftUI apps get slow — and where a few precise fixes restore smoothness.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate