TL;DR: iOS 18 and macOS 15 secretly ship with automatic observation tracking for UIKit/AppKit. Enable it with a plist key, and your views magically update when your @Observable models change. No more manual setNeedsDisplay() calls!
Remember when SwiftUI came out and we all marveled at how views automatically updated when @Published properties 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.
Let’s be honest - keeping your UI in sync with your data model in UIKit has always been a chore. Here’s the dance we’ve all done:
\nclass ProfileViewController: UIViewController {\n var user: User? {\n didSet {\n updateUI()\n }\n }\n \n func updateUI() {\n nameLabel.text = user?.name\n avatarImageView.image = user?.avatar\n // ... 20 more lines of manual updates\n setNeedsLayout()\n }\n}\nForgot to call updateUI()? Enjoy your stale UI. Called it too often? Hello, performance issues. It’s tedious and error-prone.
With the new observation framework, this entire pattern becomes obsolete. Here’s the same code with automatic tracking:
\nimport Observation\n\n@Observable\nclass User {\n var name: String = ""\n var avatar: UIImage?\n var unreadCount = 0\n \n var hasUnread: Bool {\n unreadCount > 0\n }\n}\n\nclass ProfileViewController: UIViewController {\n let user = User()\n \n override func viewWillLayoutSubviews() {\n super.viewWillLayoutSubviews()\n // UIKit tracks these property accesses automatically!\n nameLabel.text = user.name\n avatarImageView.image = user.avatar\n badgeView.isHidden = !user.hasUnread\n }\n}\nThat’s it. Change user.name anywhere in your app, and the label updates. No manual calls, no forgotten updates, no performance overhead from unnecessary refreshes. It just works.
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() and layout()) are the go-to choices.
View the complete list of supported methods
\nupdateProperties() (iOS 26+)layoutSubviews()updateConstraints()draw(_:)updateProperties() (iOS 26+)viewWillLayoutSubviews()viewDidLayoutSubviews()updateViewConstraints()updateContentUnavailableConfiguration(using:)When executing the configurationUpdateHandler
updateConfiguration(using:) (UICollectionViewCell)
updateConfiguration(using:) (UITableViewCell)
updateConfiguration(using:) (UITableViewHeaderFooterView)
When executing the configurationUpdateHandler
Here’s where it gets interesting. This feature isn’t enabled by default (yet). You need to add a key to your Info.plist:
\nUIObservationTrackingEnabled\nNSObservationTrackingEnabled\nThis plist key enables observation tracking in iOS 18 and macOS 15. Starting with their 26 releases, this is on by default and the key will simply be ignored.
\niOS 26 (already in beta!) brings improvements. The new updateProperties() method on both UIView and UIViewController provides an even better place for observable property access. For a comprehensive overview of all iOS 26 UIKit additions, check out Jordan Morgan’s excellent writeup.
class MyView: UIView {\n let model: MyModel\n \n override func updateProperties() {\n super.updateProperties()\n // This runs before layoutSubviews for even better performance\n backgroundColor = model.backgroundColor\n layer.cornerRadius = model.cornerRadius\n }\n}\nThis method is specifically designed for property updates and runs before layoutSubviews, allowing for more efficient updates and clearer separation of concerns.
Just like the layout system has setNeedsLayout() and layoutIfNeeded(), the property update system provides setNeedsUpdateProperties() and updatePropertiesIfNeeded(). You can call setNeedsUpdateProperties() to schedule a property update on the next update cycle, or use updatePropertiesIfNeeded() to force an immediate update if one is pending. This gives you fine-grained control over when property updates occur, which is especially useful for optimizing performance in complex view hierarchies.
Apple’s automatic trait tracking documentation provides detailed guidance on using these new APIs. Plus, automatic observation tracking is enabled by default in iOS 26, so you won’t even need the plist key anymore.
\nOf course, it’s not all roses. Here are a few things to watch out for:
\n@Observable is thread-safe, mutations from different threads could lead to inconsistent UI representations. Keep all mutations on the main thread to avoid surprisesYou might be tempted to create a method that pre-accesses all observable properties:
\n// ❌ Don't do this\noverride func trackObservableProperties() {\n // Accessing all properties upfront\n _ = model.backgroundColor\n _ = model.cornerRadius\n _ = model.title\n // ... etc\n}\nThis is an anti-pattern for two reasons:
\nInefficiency: It establishes observation dependencies for ALL properties, even those not used in the current UI state. The beauty of automatic observation is that it only tracks properties actually accessed during updates.
\nFragility: You’re maintaining a duplicate list of properties that can easily fall out of sync with your actual UI code.
\nInstead, access properties directly where they’re used:
\n// ✅ Do this\noverride func layoutSubviews() {\n super.layoutSubviews()\n // Only accessed properties create dependencies\n if model.isOptionEnabled {\n view.foo = model.bar // Only bar is observed\n } else {\n view.foo = model.baz // Only baz is observed\n }\n}\nThis way, only the properties actually affecting your UI get observation dependencies, making your code both more efficient and maintainable.
\nYou might be wondering about performance. The beauty of this system is that it only tracks dependencies when views are actually laying out. If a view isn’t visible, it’s not tracking. The observation framework uses a sophisticated dependency graph that ensures minimal overhead.
\nAutomatic observation tracking is one of those features that makes you wonder how you lived without it. It brings the best parts of SwiftUI’s reactive programming model to UIKit and AppKit, without requiring a complete rewrite of your app.
\nAll the code snippets in this post come from a fully working example project. Check it out on GitHub: ObservationTrackingExample
\nIf 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)
Since iOS 17, UIKit has quietly introduced custom traits - a way to attach arbitrary values to the trait collection that flows through your view hierarchy. These aren’t just for dark mode and size classes anymore. Keith Harrison has an excellent deep dive into custom traits if you want the full story.
\nThe magic happens when you combine custom traits with observable objects. You get automatic propagation AND automatic updates. It’s like having your cake and eating it too.
\nView the complete Example
\nLet’s build an app-wide state container that any view can access and observe:
\nimport UIKit\nimport Observation\n\n@Observable \nclass AppModel {\n var currentUser: User?\n var theme: Theme = .light\n var isOnline = true\n \n // Add more app-wide state as needed\n}\n\n// Define a custom trait for your app model\nstruct AppModelTrait: UITraitDefinition {\n static let defaultValue: AppModel? = nil\n}\n\n// Add convenient accessors\nextension UITraitCollection {\n var appModel: AppModel? {\n self[AppModelTrait.self]\n }\n}\n\nextension UIMutableTraits {\n var appModel: AppModel? {\n get { self[AppModelTrait.self] }\n set { self[AppModelTrait.self] = newValue }\n }\n}\nAt your app’s root (usually in your scene delegate or root view controller), inject the model:
\nclass SceneDelegate: UIResponder, UIWindowSceneDelegate {\n var window: UIWindow?\n let appModel = AppModel()\n \n func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options: UIScene.ConnectionOptions) {\n guard let windowScene = (scene as? UIWindowScene) else { return }\n \n window = UIWindow(windowScene: windowScene)\n let rootViewController = MainTabBarController()\n \n // Inject the app model into the trait system\n rootViewController.traitOverrides.appModel = appModel\n \n window?.rootViewController = rootViewController\n window?.makeKeyAndVisible()\n }\n}\nNow the magic part - any view controller in your hierarchy can access and observe the model:
\nclass ProfileViewController: UIViewController {\n let nameLabel = UILabel()\n let statusIndicator = UIView()\n \n override func viewWillLayoutSubviews() {\n super.viewWillLayoutSubviews()\n \n guard let model = traitCollection.appModel else { return }\n \n // These automatically update when model properties change!\n nameLabel.text = model.currentUser?.name ?? "Guest"\n statusIndicator.backgroundColor = model.isOnline ? .systemGreen : .systemRed\n \n // Theme updates\n view.backgroundColor = model.theme.backgroundColor\n nameLabel.textColor = model.theme.textColor\n }\n}\nNo delegates. No notifications. No manual updates. Change appModel.currentUser anywhere in your app, and every view observing it updates automatically.