Hi Andrew, did you have any luck finding another mechanism for enabling syncronization for existing records that were created before NSPersistentHistoryTrackingKey was set to true? I'm starting to implement the bool hack now but it indeed is really cumbersome.

Wow thanks a lot for posting this here, I just spent a lot of time trying to debug this exact problem. As you wrote, I had added a new entity with a name between existing entities. I got an constraint violation during attempted migration error. And indeed saw in the log there were new ID's assigned to each of the entities. When I put a Z in front of the name it works! Problem is, this could be solved in iOS 14, but what about iOS 13? Do I have to keep adding Z's to entity names while supporting iOS 13?

I've posted a suggestion for a sync enabled/disabled switch on NSPersistentCloudKitContainer through the feedback tool (FB8571301). This is the reply I got: We do not encourage applications to implement their own sync controls. The user can control the sync state of an application using the iCloud Preferences in the Settings app. The problem is that the iCloud preferences in the settings app are rather hidden.. And there is no way to directly link to this page from my app. There are inherent ownership challenges with toggling between synced and unsynced data. For this reason we recommend using a separate persistent store to hold unsynced data separately from the user’s iCloud data. This is necessarily a heavy-weight operation, the local store must be added and the cloud store removed when the user disables sync. You can customize the persistent store descriptions of a container after it is initialized. For example, you can set the store descriptions on it immediately, which will prevent the default descriptions from loading. If the container is already loaded, you must unload all the persistent stores and then mutate the descriptions accordingly.