CloudKit: iCloud schema scheduled deploy (Using Seam3)

Question

I use Seam3 framework to sync application data with iCloud. I am working on new release and my CoreData schema was changed. So I changed iCloud schema accordingly. But I'm nervous about deploying it to production. When I tested sync, I have found that sync itself works properly, but is not able to finish successfully when new schema is deployed in CloudKit Development environment and app still uses old schema.

So to avoid any issues (or minimize prossible impact) - I need to deploy schema to production environment with application release in the AppStore. I can see that I can setup scheduled deploy in iTunesConnect, but did not see such option in CloudKit Dashboard.

I have also checked Apple Doc and did not found any solution for this. What is the best solution for this issue? To schedule deployment in iTunesConnect and log into CloudKitDashboard and promote schema to Prod in the same time when app should be published? But could there be any gaps between my action and real promotion to prod?

Answer 1

Apple doesn't provide any tools to coordinate schema roll out with an app release. I'm not familiar with Seam3, but I can see why the old version would fail attempting to sync with a new schema it doesn't understand. I see two courses of action here:

First option: you'd release a version of the old app that tolerates the new schema or gives a notice that an update is required when the new schema is detected. Then publish the new schema. Then release the new version of the app. If you haven't branched your code (so that you can release fixes to both versions), or if your new schema makes changes to the same records used by the old schema (as opposed to just adding new record types), then this could be very difficult.

Second option: Roll out the new schema in a new container. You can create as many containers as you like (although you can't never delete them). So the old app uses the original, probably default, container with the original schema. All of the new additions in the new container will effectively be invisible to the original version of the app and should therefore not confuse Seam3. Then, the new app uses the new schema in a different container. The new app can easily read data from the old container then write it to the new container, if you need to migrate data.

I prefer the second option because users of the old app will continue to operate fine, even if they never update. This could happen to users still using older hardware, say an iphone5, that can no longer update to the latest IOS but have the older version of your app installed. This approach also gives you the option to migrate data, since the new app can read from the old container and write to the new container. Finally, you can roll out the new schema in the new container ahead of the release of the new app so it's ready the minute your new version goes live, without interfering with the old version.