CloudKit + CoreData: Now how do I take advantage of CloudKit user-to-user sharing without losing CoreData + CloudKit synchronization?

NSPersistentCloudKitContainer does not yet support sharing, please consider filing a feedback request with details about your desired use case.

You can use NSPersistentCloudKitContainer, but you have to implement the code for sharing manually. Here's a great description of what's needed along with sample code: https://developer.apple.com/documentation/cloudkit/sharing_cloudkit_data_with_other_icloud_users

You can retrieve CKRecord objects from NSPersistentCloudKitContainer using https://developer.apple.com/documentation/coredata/nspersistentcloudkitcontainer/3141668-recordformanagedobjectid?language=objc

I'm not sure how to rectify the two answers from Apple.

The "staff" answer reads to me as yes, with some extra work.

The "engineer" answer reads to me as a flat no, don't even try.

Can someone please clarify? Does "does not yet support sharing" mean you literally can't use sharing with NSPersistentCloudKitContainer at all, even with additional code?

Why can’t both be right?

Yes, "It is not supported" and "you can use it, but have to write some extra code" can be read as either saying the same thing, or contradicting each other, and after spending some hours looking through forums and documentation, without more context your intended meaning of "NSPersistentCloudKitContainer does not yet support sharing" isn't obvious to me.

Contributing to my confusion, about a year ago the answer given included:

"NSPersistentCloudKitContainer does not support sharing.... " and "As others have (correctly) pointed out, NSPersistentCloudKitContainer maintains a specific zone in the private database, and therefore will never see any shared zones owned by other users."

Three weeks ago this answer also seems to say no:

"NSPersistentCloudKitContainer only supports the private database and the public database. If you want to let your users share data with each other, you need to use the CKShare and CK operations API."

Also three weeks ago, in this thread the staff answer here seems to say yes to me (with some additional work) and your answer seems to say no - more like the answers from other threads.

I'm currently looking at my CloudKit implementation which needs a serious bugfix/refactor and I'm trying to figure out if I can adopt NSPersistentCloudKitContainer to remove some (or ideally most) of my pretty ****** sync code. That would be amazing, but I know I'm slow and a mediocre programmer and I'd prefer to not spend what will inevitably be hours if in the end I'm barking up the wrong tree.

I'm happy to admit I'm an ***** or not comprehending the obvious and if that's the case I apologize. Would you be willing to provide an answer that I can understand?

I've tried to implement some code for sharing manually with working CloudKit + CoreData mirroring. I've stuck on the parent records (I have one-to-many relationship and child records need to be shared when parent record is shared) and here is why. I've implemented code that is setting parent records for each NSManagedObject's CKRecord, syncing works well, but it causes huge troubles like:

I call my setParentRecords among other places from NWPathMonitor's pathUpdateHandler (literally when internet restored), and fetching NSManagedObjects that's CKRecords if any don't have parent on the server yet. Apple's NSCloudKitMirroringDelegate
is doing the same also on internet restore. And my any fetching at this second causes crash of Mirroring. Mirroring do not work since this point and says "probably no internet" each time!

I could not beat that problem and I am afraid that will have to implement whole sync by myself, even for privateDatabase just because of such bugs (and no any completion handlers in NSPersistentCloudKitContainer).

So, simple fetch crashes whole mirroring until app restarted.

CKDatabaseScopeShared is not supported with NSPersistentCloudKitContainer?

This would be amazing if it could work with NSPersistentCloudKitContainer directly