SwiftData and CloudKit Development vs. Production Database

For my personal developer account the data is saved in the Developer database correctly and I can inspect it.

If it was a development version built and ran with Xcode, the data would go to the development environment, and so this is as-designed; if it is a production version downloaded from the App Store, or a TestFlight version, no, the data should not appear in the development environment.

When I use the "Act as iCloud account" feature and use one of my other accounts to inspect the data, I notice that for the other user, the data is neither in the Development environment nor the Production environment. Which leads me to believe it is only stored locally on that user's machine, since the app does in fact work, it's just not syncing with other devices of the same user.

If you haven't deployed the CloudKit schema to the production environment, the CloudKit synchronization of your App Store app will hit an error, and the data will stay on the device and will not be synchronized across devices.

So, my question is: how do I "deploy to production"?

This is covered in Deploying an iCloud Container’s Schema.

I know that there is a Deploy Schema Changes button in the CloudKit dashboard. At which point should I press that?

You deploy your CloudKit container to the production environment after you have finalized your CloudKit schema and fully tested your app in the development environment.

In a production environment, you can only make additive changes.

If I press it now, before distributing a new version of my app, will that somehow "signal" the already running apps on user's machines to start using the Production database?

The apps on user's machines should always use the production environment. After you deploy your container to the production environment, the CloudKit synchronization of the apps should start to work.

Is there a setting in Xcode that I need to check for my Release build, so that the app does in fact start using the production db?

CloudKit uses the com.apple.developer.icloud-container-environment entitlement to determine which environment it uses.

By default, Xcode takes care the entitlement for you: It automatically picks the development environment in the development phase, and picks the production environment when you submit your app to App Store or TestFlight.

People may configure the entitlement manually for some reasons (for testing the production environment in the development phase, for example). I don't think you need to do so in your case.

Is there a way to detect in the code whether the app is using the Production database or not?

There isn't.

In your case, the data should start to synchronize after you successfully deploy your container to the production environment, and so you probably don't need to worry.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Thanks for the reply. I've recreated this scenario with a simple test app, and here is what I found:

• Setting the com.apple.developer.icloud-container-environment to Production does indeed make the app use the production database.
• When I run my app from Xcode, the data is synced correctly to CloudKit, and it chooses the correct database based on the entitlement, no issues found.
• When I produce a Release build with this same entitlements file, no data is being synced at all regardless of the entitlement value.

I've failed to mention in my original post, but I am distributing my app using Direct Distribution. Does that have something to do with the fact that CloudKit is not syncing outside of being run from Xcode?

Finally I found that the reason I believed my archived Release build was syncing to the Development database is the following: regardless of the setting of the entitlement, the locally persisted data seems to use one shared store. And because inevitably I would run the app at least once during the day from Xcode, it would pick up the changes and save them to CloudKit, so I assumed it was the Release build, whereas in fact it was the Xcode build all along doing the syncing.

Everything you described above makes sense, except that "a Release build with this same entitlements file" doesn't work.

I don't know a lot about Direct Distribution. My understanding is that it is the same as "Developer ID" distribution mentioned in Supported capabilities (macOS). If that's the case, CloudKit should be supported.

My guess is that your app probably has something wrong about entitlements, which prevents it from using CloudKit. To confirm that, you can:

• Try to capture a sysdiagnose and find relevant error messages from there. This topic is covered in Capture and analyze a sysdiagnose.

• Use the following command line tool to dump the entitlements claimed by your app, and check if there is no difference between the the Release and Debug builds.

$ codesign --display --entitlements - <path_to_your_app.app>

Also, if you can detail the steps about how you produced the Release build, I'd see if I can find something relevant.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.