{"id":35614,"date":"2022-04-18T16:27:06","date_gmt":"2022-04-18T20:27:06","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=35614"},"modified":"2022-04-18T16:27:06","modified_gmt":"2022-04-18T20:27:06","slug":"nspersistentcloudkitcontainer-in-2022","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/04\/18\/nspersistentcloudkitcontainer-in-2022\/","title":{"rendered":"NSPersistentCloudKitContainer in 2022"},"content":{"rendered":"

Steve Troughton-Smith<\/a>:<\/p>\n

\n

For the longest time, Core Data had a very bad rap for iCloud syncing, so I just never engaged with it even after the APIs were improved. What is the story in 2022? Is Core Data + CloudKit in a good place, or nightmare fuel? What are the current pitfalls? …should I use it?<\/p>\n<\/blockquote>\n\n

Becky Hansmeyer<\/a>:<\/p>\n

\n

It’s been nightmare fuel for me, but maybe I just don’t have it set up right. I hear from users now and then who say that all of their data has been wiped out, and I have no idea what could have happened.<\/p>\n<\/blockquote>\n\n

Roland Gropmair<\/a>:<\/p>\n

\n

I tested it a bit, it seemed<\/em> to work fine. But I never got it working with watchOS - no way to troubleshoot - and left it there<\/p>\n<\/blockquote>\n\n

Antwan van Houdt<\/a>:<\/p>\n

\n

For my specific use case it has been a nightmare to optimise the size of the data. My app generates many but small records and this doesn’t go well with CoreData + CloudKit. I created a binary format which reduces the amount of records that helps with this problem somewhat.<\/p>\n<\/blockquote>\n\n

Davide Benini<\/a>:<\/p>\n

\n

It’s quite reliable, a bit hard to set up and debug, but still much simpler than building your own sync system. You’ll need to follow Apple’s docs to set up sync and reconcile conflicts yourself, but it’s a logical process an quite mechanical.<\/p>\n<\/blockquote>\n\n

Mrabti<\/a>:<\/p>\n

\n

It works quite good, but I think it is better to have your own sync code instead of using the Apple Blackbox sync implementation, then you will have more control on edge cases, and you can troubleshoot issues much more easier.<\/p>\n<\/blockquote>\n\n

Binary Formations<\/a>:<\/p>\n

\n

The built-in CloudKit mirroring stuff is too opaque for our needs.<\/p>\n<\/blockquote>\n\n

Quentin Zervaas<\/a>:<\/p>\n

It is a really elegant solution that mostly works well, but in rolling out this update, we’ve come to learn a few things about it.<\/p>

[…]<\/p>

[Just] because an event finishes, doesn’t mean everything is in sync yet. You may experience many consecutive events of the same type all within a short timeframe.<\/p>

[…]<\/p>

If an error occurs, it will frequently give you a CKError<\/code>, but these aren’t necessarily the same as when accessing CloudKit directly. For example, if you receive a CKError.Code.partialFailure<\/code>, it’s not possible retrieve the errors that would normally be contained.<\/p>

[…]<\/p>

For errors that aren’t a CKError<\/code>, I haven’t been able to find documentation for many of the errors that occur, but these are the ones I’ve discovered (I’m sure there are more).<\/p>

[…]<\/p>

There’s some quirky behaviour with Apple Watch, which can make it challenging to keep everything up-to-date between the Apple Watch and its linked iPhone.<\/p>

[…]<\/p>

Since NSPersistentCloudKitContainer<\/code> uses transactions to keep the data in sync, it needs to propagate through every database changed one by one.<\/p><\/blockquote>\n\n

Previously:<\/p>\n