Hey thanks for replying! You can file a feedback report for this and use a private scoped database to initialize your container as a workaround. Done! FB9179243 recordName and modifiedAt are default fields on every record type, so if they are missing you should definitely file a feedback report with CloudKit. I have a feeling this might just be a display issue in the CloudKit dashboard UI - Maybe new with the new dashboard update? I've never really used CloudKit 'in anger' so I don't really know. What appears as 'Name' in both the "Records" table and "Record Details" sidebar, seems to be "recordID" if filtering, and also in the field dropdown when you are creating the index. So I guess it is there, it's just not named what I was expecting. And it's the same situation for modified. Does this sound right? This looks like you tried to use a database file with the public database that was previously syncing with the private database. If you can reproduce this from a clean (empty) database file and some set of steps we'd appreciate a feedback report with a test case in it we can run I am definitely using a coredata database file that has never touched the private database. It's reproduce-able. I've tried with a few different CoreData schemas to see if it was something I was doing there but that appears to have no effect. The TLDR is: If the core data store is empty, creating records will send them up to CloudKit If the store is NOT empty, and the database syncs (e.g. app launch), you will get the "Custom zones are not allowed in public DB" errors Once you are in this state with the ""Custom zones are not allowed in public DB" errors, changes from the device will no longer make it to iCloud However, if you make a record off-device (e.g. In the Dashboard, via the API, or from another device), it will make it down to the device. I created a feedback: FB9179204