SwiftUI feels unfairly productive right up until an app grows. Then a scroll view starts to stutter, a filter panel gets noticeably sluggish, and one small state update appears to wake half the hierarchy. Instruments hands you symptoms rather than a cause, and nobody can point at an obviously terrible line, because there isn't one.
The argument: performance follows from the contract you sign with SwiftUI — the framework re-evaluates a body and needs to decide, cheaply, whether anything that matters actually changed. Closures defeat that comparison. Reference identity hiding inside a supposedly value-typed model defeats it too. Computed properties look like a tidy way to organise a view but create no diffing boundary at all, and a large body quietly turns into performance debt.
The fix is making rendering inputs explicit rather than sprinkling manual Equatable conformances, which do not scale — and there is a section on seeing the problem visually rather than guessing at it.
The piece is also careful about scope: it argues this kind of rewiring pays off for screens with real churn — feeds, search results, checkout flows, anything rendered at scale — and not for a static settings row. It closes with a short checklist for triaging a screen that already feels heavy, and a case for treating diffability as a codebase-wide habit, backed by review and tooling, rather than something one careful engineer has to remember alone.