NSPersistentCloudKitContainer in 2022
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?
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.
I tested it a bit, it seemed to work fine. But I never got it working with watchOS - no way to troubleshoot - and left it there
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.
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.
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.
The built-in CloudKit mirroring stuff is too opaque for our needs.
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.
[…]
[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.
[…]
If an error occurs, it will frequently give you a
CKError, but these aren’t necessarily the same as when accessing CloudKit directly. For example, if you receive aCKError.Code.partialFailure, it’s not possible retrieve the errors that would normally be contained.[…]
For errors that aren’t a
CKError, 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).[…]
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.
[…]
Since
NSPersistentCloudKitContaineruses transactions to keep the data in sync, it needs to propagate through every database changed one by one.
Previously:
- Increased iCloud Errors
- iCloudCoreDataStarter and Temporary IDs Bug
- How to Set Up Core Data and CloudKit
- Syncing Core Data With CloudKit and NSPersistentCloudKitContainer
- The Deprecation of iCloud Core Data
2 Comments RSS · Twitter
"Opaque" is the right word. In terms of reliability, I'd say it's been working fine for me; no puzzling conflicts.
But the performance is hit and miss. Photos builds on it (I think?), and suffers from Apple's usual "let's not confuse the user with status information" syndrome — it'll even claim that it's up to date, even when a photo or two are clearly still missing. (In my cases, never for more than a few minutes, but that's enough to be annoying and confusing. If there were some kind of indicator that it's still looking for more data, it'd be fine.) Notes occasionally suffers this, too.
But, years and years of usage and haven't lost any data.
@Sören I think Photos and Notes use CloudKit directly, not via NSPersistentCloudKitContainer. I find that Photos syncing is often way out of date, and it has lost data for me.
