I am preparing to submit my app to the App Store. From the research I've done, it seems that there is no easy way to move records from CloudKit's Development environment to its Production environment. According to this answer (Move record from development to production in CloudKit?), I need to download all my records in Development to some sort of file and then upload them to Production. Can someone break down this process for me a bit more? How am I supposed to download these records? What kind of file am I supposed to make? I don't understand. Thanks!
2 Answers
There is no method that you're "supposed" to use, because there's no supported method of migrating data across environments. There is no "file" that you can download and simply re-upload. The normal path expected by Apple is: create a schema in the dev env, create test records in the dev environment, deploy the schema to the prod environment, then start all over with new records in the prod env. Since that path doesn't preserve data across envs, you're pretty much on your own to find a way to preserve the data yourself.
The answer you referenced is suggesting to use this approach (https://stackoverflow.com/a/40414108/1641444) to switching between dev and prod environments in order to do the following:
- Build your app configured to access the Dev env
- Your app retrieves all of the records you want to migrate. Retrieve all of your public ID records. Retrieve all of the records in this user's private DB. You will have to figure out the necessary queries to retrieve all of the records.
- Your app saves those records on your device. How you do this is entirely up to you, based on the type and quantity of data you have.
- Rebuild your app re-configured to access the prod env (and, obviously, deploy your schema to prod if you haven't already done so)
- Your app re-reads the data you saved in step 3
- Your app creates new records in the prod env using that data.
- Submit your app to the app store.
How you choose to save the data in step 3 will depend on how many records you have, what types of data they store, and which methods of saving/retrieving data you're familiar with. Personally, I have SQL database in my app, so I'd probably just create new tables and store the records there. You could open another question describing the schema/data you're working with and ask for ideas on how to save it on the device and later re-read it.
Also, you can only migrate the privateDB records for the iCloud account that's logged into the device. If you've used the development builds with multiple iCloud accounts, each one will need to repeat the process in order to migrate all of their private DB records.
The other alternative, if you don't have too many records and don't have binary data, is to manually create new records in the prod database using the cloudkit dashboard.
If you have a complex schema with lots of record types and/or field types, steps 2, 3, 5 and 6 could be very difficult (or at least, very time consuming) to code.
I had the same question and found myself here. The only solution I have found is one similar to Thunk's above. My version of this solution was as follows:
- Build and test app on a device in development environment as is typically done. Your app should include local storage of the development data on the device.
- In your development account, deploy the development container to production. This will create the same schema but will not transfer the data from the development to production.
- Upload your app to the appstore and distribute the production version through testFlight. The device development version of your app will be overwritten, but the local data files will still be there.
- Your new production version will upload the previous local (development) data and then sync to the production cloud container, assuming this is they way your app is designed.

- 196
- 1
- 8