Migration from SwiftData/CloudKit

[frazzeli]

Hi all, I have an app that uses SwiftData and private CloudKit sync to persist user data. NSPersistentCloudKitContainer has proven far too eager to remove the local SwiftData records for privacy reasons whenever it determines the user's iCloud account is unavailable. We haven't found a way to avoid this behavior in a fully-SwiftUI app (existing workarounds for changing the cloudkit container config on the fly seem to require UIKit), so we're looking for alternatives to SwiftData that would still let us use private CloudKit sync.

Can I get your thoughts on a couple of basic questions so I can test my assumptions?

• First is that, because SQLiteData uses CKSyncEngine instead of NSPersistentCloudKitContainer (correct?), we won't see this "privacy" behavior where local data is automatically removed when the OS reports the user has logged out of their iCloud account. Do you think that's correct?

• And second, what would the CloudKit schema production deployment process look like when switching our app from SwiftData/CloudKit to SQLiteData/CloudKit? I assume we'd need to deploy the new GRDB schema, but would that break the existing CloudKit sync for existing users who haven't yet updated their apps?

[mbrandonw]

Hi @frazzeli, some comments below:

NSPersistentCloudKitContainer has proven far too eager to remove the local SwiftData records for privacy reasons whenever it determines the user's iCloud account is unavailable.

Do you know if this behavior is documented anywhere? And does this happen when a full sign out happens from iCloud, or just when the account is "temporarily unavailable" and the user just needs to enter their password again (usually from an automated prompt by iOS).

• First is that, because SQLiteData uses CKSyncEngine instead of NSPersistentCloudKitContainer (correct?), we won't see this "privacy" behavior where local data is automatically removed when the OS reports the user has logged out of their iCloud account. Do you think that's correct?

It's correct that we use CKSyncEngine and not NSPersistentCloudKitContainer, but depending on the exact behavior of NSPersistentCloudKitContainer our tools may behave the same.

CKSyncEngine notifies us when it detects a full sign out of an iCloud account, and at that moment we decide to delete all data. We mainly do this because this is what Apple suggests in their sample code. It also seems like the right approach since the data was previously associated with a particular iCloud user and we no longer have access to that user.

However, CKSyncEngine and CloudKit do have the concept of a "temporary unavailable" iCloud account. That is when the user is in a state where they need to provide their password (to a system prompt) in order to be fully logged in, but they are also not technically logged out. And CKSyncEngine does not send us a .signOut event for that. It only sends it when the user is fully logged out. So perhaps that will work better in your use case?

And if there is a legitimate reason to keep data around even after a user signs out, we could explore possibly making that customizable in the library.

• And second, what would the CloudKit schema production deployment process look like when switching our app from SwiftData/CloudKit to SQLiteData/CloudKit? I assume we'd need to deploy the new GRDB schema, but would that break the existing CloudKit sync for existing users who haven't yet updated their apps?

I'm sorry but I don't really have a good answer for this. Swapping out SwiftData for SQLiteData is going to be incredibly difficult, and doubly so if you have CloudKit sync turned out.

At the very least I imagine you will want to release a kill switch in your app as soon as possible so that at some future date you can force all users to update to the newest version of the app. And then that new version of the app will have converted all SwiftData patterns and tools into SQLiteData patterns, and have a one-time migration that loads all of the SwiftData data into memory and imports it into the new SQLite tables.

If you do all of that work before creating the SyncEngine then the library will take care of uploading all of that data to CloudKit. And that data shouldn't trample on your existing SwiftData/CloudKit data because the two systems will use different zones.

That's the basic idea, but it's a lot of work and a lot of things can go wrong along the way.

[frazzeli]

Thanks @mbrandonw.

Do you know if this behavior is documented anywhere?

Not officially, but you can find other reports of it here: https://crunchybagel.com/nspersistentcloudkitcontainer/#:~:text=Changing%20iCloud%20Account
https://stackoverflow.com/questions/70755205/core-data-database-wiped-when-using-nspersistentcloudkitcontainer
And this is off-topic, but the bolded comment update warns about changing behavior in iOS 18 that can also lead to unexpected local data loss: https://stackoverflow.com/a/72616295

And if there is a legitimate reason to keep data around even after a user signs out, we could explore possibly making that customizable in the library.

With Apple's first-party data (photos, notes, etc), I believe users are given the option to keep or delete local data when they sign out of iCloud. I think it would be a legitimate use case to allow this in third-party apps, as well, especially given that this can happen when the user hasn't intentionally signed out of their device (or may never have signed in to begin with). Making this customizable so we can notify the user before data is deleted would be a huge benefit to the user, IMO.

[mbrandonw]

Not officially, but you can find other reports of it here:

Awesome, thanks for these references. This gives us a good amount of things to think about.

With Apple's first-party data (photos, notes, etc), I believe users are given the option to keep or delete local data when they sign out of iCloud.

Yeah that's fair! We will discuss this more.