SwiftUI Weekly - Issue #238
The curated collection of links about SwiftUI. Delivered every Monday.
The hidden cost of unstable SwiftUI environment defaults
The @Entry macro lets us define a custom SwiftUI environment value and its default in one declaration. Starting in Xcode 27, the compiler shows a warning when we create a class instance directly in the default expression. Every fallback access then returns a new reference, which can make SwiftUI treat the environment value as changed and re-evaluate views that read it.
Splitting Large SwiftUI Views in the Apple's way
A separate View struct with narrow inputs gets its own boundary. SwiftUI can skip its body when only its inputs are unchanged. That’s the difference “skip for readability” and “split for performance”.
The Anatomy of a Reusable SwiftUI View
Whenever I build a custom reusable SwiftUI view as part of a larger application's design system, I follow the same principle: design its API to be as close as possible to Apple's view APIs. This keeps the "distance" between the behaviour of custom views and native view primitives small, and developers do not need to learn new ways of interacting with custom views.
Equatable properties in @Observable classes
One of the main advantages of using @Observable models in SwiftUI is that the framework can track individual property accesses. When a view reads a property in its body, it only needs to reevaluate when that property changes, rather than whenever another part of the model is updated.