NSPersistentCloudKitContainer: Set To-One relation to nil is not synced to CloudKit

Using NSPersistentCloudKitContainer: I have a relation between Item --to-one--> Group. This works fine on device: I can set a Group for an Item and remove the Item from the Group again, everything is persisted locally.

The Problem:
Adding does work, but removing the Group never appears on a different device. As soon as the Item gets edited on the different device, the Group relation re-appears with the new changes (even if manually removed there as well).

What I see in CloudKit dashboard:
  • Group field on Item is of type String.

  • A fresh Item record, never assigned to a Group, does not have the Group field.

  • Removing the Group does not remove the Group field in CloudKit.

  • As soon as it gets a Group field, I can’t get rid of it. Manually emptying the value causes to crash on download.

Reproducible with the example project:
The behaviour can easily be reproduced with the example project (https://developer.apple.com/documentation/coredata/synchronizing_a_local_store_to_the_cloud?language=objc). Just replace deleting an Attachment from a Post with unassigning it instead.

Workarounds
I can think of these 4 workarounds:
  1. Just use To-Many relation and manage to allow only a single assignment.

  2. Not use a relation at all, just manually track assignment.

  3. Add isRemoved flag and filter accordingly.

  4. Create an "Empty-Group" record to assign to instead of removing.

I am not very happy with any of these Workarounds. Does anyone have the same problem and a better solution?

Accepted Reply

Resolved in iOS 14 beta 3 🥳

Replies

Sorry to say, but I can just confirm your observation, and I'm going with your workaround (4): A mandatory, undeletable record is created in Group and used by default if Item has no Group assignment. Kind of a hack, but IMHO the best bypass.

Mattes
You can use the feedback assistant to file bugs against NSPersistentCloudKitContainer. Include the following:
  1. A sysdiagnose from all of the participating devices

  2. The persistent store files from all of the participating devices

  3. If your dataset is large, a detailed accounting of the affected records and the mutations made to them from each device (as well as you recall, history tracking is the truth)

Checked with the first iOS 14 beta and the issue still exists.

Filed bug: FB7753661
Your feedback does not include the persistent store files, we'll need those to triage this.
Updated FB7753661 with the requested data.
Resolved in iOS 14 beta 3 🥳