Using Core Data with Watchos 2.0

Using Core Data with watchOS 2.0

Yes, you'll have to maintain two separate stores. If either side is a "read-only" client and the CoreData datastore is small and changes infrequently you could potentially use the transferFile WatchConnectivity API to transfer the whole store each time it changes.

Implementing Core Data to watchOS 2.0

The process of setting up the watchOS Core Data stack is identical to iOS. In fact, you can share that common code (and even a common data model) between your iOS and watchOS targets.

You can initialize your stack when your application launches, or move that code out of the (app or) extension delegate into a shared manager, which gets initialized the first time you need to obtain data from your model.

I actually wait until my interface controller's awakeWithContext to load my data (which lazily initializes my manager's stack).

If you're looking for a working example, Jesse Squires has an excellent Swift Core Data stack which you might find helpful.

Core data + CloudKit - sharing between iOS and watchOS companion app

Resolved by adding a cloudKitContainerOptions to my context description like this :

class CoreDataStack {
    static let persistentContainer: NSPersistentCloudKitContainer = {
        let container = NSPersistentCloudKitContainer(name: "MyProjectName")
        let description = container.persistentStoreDescriptions.first

        description?.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "myCloudContainerID") // HERE !

        container.loadPersistentStores(completionHandler: { (_, error) in
            if let error = error as NSError? {
                fatalError("Unresolved error \(error), \(error.userInfo)")
            }
        })
        return container
    }()  

}

Where should data reside in a watchOS app?

It is typically best practice to be storing persistent data for watchOS in the cloud or on a companion iPhone app. My guess is that what your source refers to by 'data model' is the data in active storage, i.e. when the app is open. You shouldn't be storing redundant data locally if you don't need to, esp. not for watchOS.

All that being said, watchOS does have access to CoreData and NSCoding methods. I'm not sure about NSUserDefaults - but I wouldn't use that anyway for data storage. (This is a general principle for iOS as well: CoreData is used for data, and UserDefaults for user preferences.) Here is a similar thread explaining how that's done.

But I would highly recommend finding an alternative before storing data on the watch - there just isn't a whole lot of persistent storage space available on there.

EDIT: Check out Apple's WatchKit docs for more details on your options.

Sending Core Data objects to read only Apple Watch App

Your approach sounds good. Mirroring your CoreData database on your watch app would indeed be overkill if you don't play to change the data on the watch.

So using the Application Context to send the data via background transfer is the right choice. This has only one caveat: The updateApplicationContext method that you use to tranfer the data only accepts a dictionary of property list values. In other words, you can only send objects that you could add to a property list:

• Array
• Dictionary
• String
• Data (NSData)
• Date (NSDate)
• Integer
• Floating-point value
• Boolean

So, you'll have to convert your Core Data objects to dictionaries that contain only those types, before you can send them.

That's a bit of an effort, but you would have to do that anyway even if you wanted to mirror your database on the watch side, because with watchOS2 you cannot use App Groups anymore to share CoreData files.

---

Related Topics