|< How to read the Digital Crown on watchOS using digitalCrownRotation()||How to configure Core Data to work with SwiftUI >|
Updated for Xcode 12.0
As two massive pieces of Apple’s software platform, it won’t surprise you to learn that Core Data and SwiftUI have been written to work well together: we get property wrappers, environment support, and more, all to make sure we can integrate Core Data into our SwiftUI apps with the least hassle.
Before SwiftUI it was common to find a range of ways you might find Core Data being used from an architectural perspective – Apple strongly encouraged us to create containers at the AppDelegate level then reach back up as needed, others preferred using manager classes, and some preferred abstracting Core Data away entirely so they had the freedom to move to Realm or other options at a later date.
However, SwiftUI’s integration with Core Data is different because it points very strongly in one direction: create the Core Data container once when the app starts, inject its managed object context into the environment, then perform fetch requests directly on there.
This isn’t me guessing – Apple literally designed it in a highly specific way, and if you want to take advantage of all the features of SwiftUI’s Core Data integration then you ought to follow the path Apple is laying down for us.
Here are the four specific features that will help you see what I mean:
NSManagedObjectconforms to the
ObservableObjectprotocol, which means we can bind any object to part of our user interface.
managedObjectContextkey in the environment designed to store our active Core Data managed object context.
@FetchRequestproperty wrapper that uses the environment’s managed object context to perform fetch requests.
So, we create a managed object context when the app launches, attach it to the environment for our views, then use
@FetchRequest to load data for the app to use.
Link copied to your pasteboard.