This document discusses performance and memory management techniques in SwiftUI. It provides information on ObjectWillChange and Published properties, how to use StateObject and ObservedObject, and best practices like only publishing properties that matter to the UI and caching ObservedObjects to avoid unnecessary view recreations. NavigationLink performance is also covered, including using LazyView for deep navigation flows.

1. Andrei Solovev, iOS Tech Lead at Seven Peaks Software
SwiftUI
Performance and Memory Management

2. SwiftUI
SwiftUI automatically updates the a
ff
ected parts of the interface. As a result, the
framework automatically performs most of the work traditionally done by view
controllers.

3. Topic
• ObjectWillChange and @Publishe
d
• NavigationLink performanc
e
• Creating @ObservedObject with parameters

4. ObjectWillChange
• ObservableObjec
t
• @StateObject and objectWillChang
e
• @StateObject and @Publishe
d
• @ObservedObject and @Publishe
d
• Unused @ObservedObject

5. ObservableObject
A type of object with a publisher that emits before the object has changed.
By default an ObservableObject synthesizes an objectWillChange publisher that emits the changed value
before any of its @Published properties changes
.
class Contact: ObservableObject {
@Published var name: String
}
https://developer.apple.com/documentation/Combine/ObservableObject

6. @StateObject and objectWillChange
objectWillChange
A publisher that emits before the object has changed.
var objectWillChange: Self.ObjectWillChangePublisher { get }
https://developer.apple.com/documentation/combine/observableobject/
objectwillchange-2oa5v

7. @StateObject and @Published
Avoid the overhead of a published property when you don’t need it. Only publish
properties that both can change and that matter to the user interface.

8. @ObservedObject and @Published
SwiftUI might create or recreate a view at any time, so it’s important that initializing a
view with a given set of inputs always results in the same view. As a result, it’s
unsafe to create an observed object inside a view.

9. Unused @ObservedObject
SwiftUI monitors observable object changes, not a particular property and View will be
updated even if you don’t use the property that changed

10. NavigationLink
A view that controls a navigation presentation.
A NavigationLink de
fi
nes a destination for a navigation-based interface and allows the user to
perform that navigation. Optionally, you can use the NavigationLink to perform a navigation
programmatically
• LazyVie
w
• Deep Navigatio
n

11. LazyView
To solve the problem when a parent View creates all children Views that could be used
for navigation we can introduce LazyView, that would take factory closure that creates a
new View and execute it on rendering, means only when this view is going to be
presented on the screen.

12. Deep Navigation
Sometimes there are multi-step flow when you have to present multiple Views with next
button and then do some action on the last screen, most common case it’s a Sign Up
where used could enter Email on first screen, Password on seconds, then OTP and
Success in the end.

13. Creating @ObservedObject with parameters
• @StateObjec
t
• @ObservedObjec
t
• Caching @ObservedObjec
t

14. @StateObject
A property wrapper type that instantiates an observable object.
Create a state object in a View, App, or Scene by applying the @StateObject attribute to
a property declaration and providing an initial value that conforms to the
ObservableObject protocol
:
https://developer.apple.com/documentation/swiftui/stateobject

15. @ObservedObject
A property wrapper type that subscribes to an @observable object and invalidates a
view whenever the observable object changes
.
https://developer.apple.com/documentation/swiftui/observedobject

16. Caching @ObservedObject
Everytime @ObservableObject emits changes every View that owns this object as
@EnvironmentObject, @StateObject or @ObservedObject will be recreated and the
body will be executed automatically by SwiftUI, even if this view doesn’t use the property
that was changed. It could be done multiple times per user action or some event
triggered.
That means we have to keep View’s init() and body as simple as possible and keep free from any kind of calculations and object creations.