Automatic Observation Tracking in UIKit and AppKit
Remember when SwiftUI came out and we all marveled at how views automatically updated when
@Publishedproperties changed? Well, Apple has been quietly working on bringing that same magic to UIKit and AppKit. The best part? It shipped in iOS 18/macOS 15, but hardly anyone knows about it. You don’t even need Xcode 26, it’s just one simple plist entry away.[…]
The automatic observation tracking is supported in a variety of UIKit and AppKit methods. For most cases,
viewWillLayoutSubviews()in UIKit view controllers,layoutSubviews()in UIKit views, and their AppKit equivalents (viewWillLayout()andlayout()) are the go-to choices.[…]
If you’ve used SwiftUI, you know the joy of
@EnvironmentObject- drop an object at the root, access it anywhere. UIKit developers have been jealous of this pattern for years. Well, jealous no more. (Mac devs miss out tho - there’s no equivalent on AppKit yet)
The keys are UIObservationTrackingEnabled and NSObservationTrackingEnabled.
It tracks which object properties are accessed when updating the view and then observes future changes to then to trigger view updates automatically. This sounds great, but it looks like it only handles a view displaying a fixed set of objects. How do you handle changes that affect which objects are eligible to be displayed in the view? I guess it will be like KVO where you need some other way of observing changes so that you know to mutate the array of matching objects, and then that last part can be observed automatically.
Previously:
- WWDC 2025 Links
- Cancellable withObservationTracking in Swift
- Swift 5.9
- SwiftUI Data Flow 2023
- Swift Pitch: Observation
