NSPersistentCloudKitContainer

Adding a CKAsset field for a Core Data String attribute is as designed. It is because the size of a CloudKit record (not counting assets) is limited to 1MB, while a Core Data attribute has no size limit. What ChatGPT said is basically right – When the size of a Core Data String attribute exceeds a certain value, NSPersistentCloudKitContainer converts it to a CKAsset object in the data transformation process. Whether the value is about 1KB or not is not formally documented though. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for the reply! Firstly, correct, we're using CoreData + CloudKit and mirrored relationships means reflexive relationships (e.g., Article.similarArticles whereby both are of the type Article). Assuming that you are using Data + CloudKit, I am guessing that this can be triggered by your code and data. Regrettably, that doesn't seem to be the case, also given the Delete Rule is Nullify. Digging through our old messages, we found out that we had already reported this very same issue a couple of years ago with a similar data model but where no entity was ever deleted. At that time we filed feedback report 9118745 and we were told that this was likely a bug. it is worth filing a feedback report for the Core Data team Given this seems to be the very same issue, I’ve added the information of this post to our above ticket (and have provided the relevant system diagnose logs, data model, etc. there too). Does your Core Data model indeed has the reflexive relationship? If yes, has it been there for long time, or

SwiftData and CloudKit are two different frameworks, and so you are free to use both of them in your app. Note that CloudKit here means the CloudKit framework, not NSPersistentCloudKitContainer. As of today, when you configure SwiftData to use CloudKit, as mentioned in here, SwiftData uses NSPersistentCloudKitContainer underneath to sync the data, and so you won't want to create your own NSPersistentCloudKitContainer instance for the purpose. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Is there a way to get the container from a device NOT having Xcode or Development tools if they can connect to a Mac? Not that I am aware of. Many of whom DO NOT use iCloud which is also weird. A few using iCloud but most are NOT. Any thoughts on why that might be? If the impacted users didn't use iCloud, you can rule out CloudKit, which will simplify the issue a bit. However, I still can't say anything for sure – Debugging a random data loss can be hard and my sitting here and guessing won't be helpful. To eventually figure it out, you might consider reaching out the impacted users to hopefully find more hints, or ideally, create a reproducible case. now it is almost as if a user has NSPersistentCloudKitContainer options set to nil and the data is deleted. Can you confirm or provide a link to documentation confirming? Setting the CloudKit option to nil does not delete the data in the existing Core Data store. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Ziqiao are you aware of any behavioral changes in iOS 18 that causes an NSPersistentCloudKitContainer to delete data? In past we were told it could be used in all cases with history on, even if user was not allowing cloudkit. This was true until iOS 18 it seems now if that initializes and user is not using iCloud would it delete data. I thought I was seeing people talking about that and that it does that for security. if That is true that is a huge damn change and which Apple should tell people about?!

are you aware of any behavioral changes in iOS 18 that causes an NSPersistentCloudKitContainer to delete data? Not that I am aware of. To be clear, NSPersistentCloudKitContainer does clean the data on the device if it gets notified of a change on the current logged-in Apple ID, but that has been the as-designed behavior since the very beginning. Note that it only cleans the local data; the data on CloudKit is still there, and will be synchronized back when the user logs back in with the same account, and so no data loss will happen. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Well something changed since we switched to iOS 18 SDK and it definitely did not work this way in earlier versions of iOS. At some point after iOS 15 SDK something changed and the cleaning process you mentioned is literally wiping users data and if it was never in iCloud in the first place it is totally gone now?! We have always used an NSPersistentCloudKitContainer since we first implemented it years back regardless of if the person enabled iCloud (in our App or not). This was based on statements Apple Engineers made in the past that you could always use NSPersistentCloudKitContainer since it was subclass of nspersistentcontainer and with History on but options set to nil for NOT ALLOWED. But now it seems that users running iOS 18 and who did not allow us to use iCloud (are getting data wiped). It is not clear if they are entirely logged out of iCloud or just have iCloud Drive off or what, but something is different in iOS 18. I really need a way to zero in on what is going on. This is one

This issue is still ongoing. Thus far we have not been able to figure out what is going on but have reduced complaints quite a bit by rolling back to minimum OS / Devkit of iOS 17. So it is some kind of bug or behavioral issue with iOS 18 SDK. We cannot find a pattern to it other than that most users are in Europe and are not using iCloud to backup. This means we are using the NSPersistentCloudKitContainer regardless of if users enable or do not enable iCloud usage. This might be the root so if anyone is aware of what might have changed in iOS 18 that would do this PLEASE let me know. We have also now default always enable iCloud usage without asking if we find an account present. They can turn it off (with big warnings) if they want but we no longer ask on launch. Also we will investigate not always using NSPersistentCloudKitContainer if iCloud is not used.

+1 I've built an app using CoreData + CloudKit and now I have to rewrite everything using NSPersistentCloudKitContainer.

Since Swift Playground 4.6, as you have observed, it is no longer possible to import PlaygroundSupport because the PlaygroundSupport framework provides no functionality to app playgrounds. However, starting in Swift Playground 4.6, you can conditionalize code with the SwiftPlaygrounds condition: #if SwiftPlaygrounds container = NSPersistentContainer(name: myApp, managedObjectModel: Self.createModel()) #else container = NSPersistentCloudKitContainer(name: myApp) #endif

What CloudKit API are you using? If you are using NSPersistentCloudKitContainer, I'd suggest that you start with the following technotes: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3164: Debugging the synchronization of NSPersistentCloudKitContainer If you are using the CloudKit framework, start with: TN3162: Understanding CloudKit throttles The general methodology to debug a CloudKit synchronization issue is to capture and analyze a sysdiagnose, and try to find relevant CloudKit errors from there. If you did find an error and need further discussion, please post the detailed error message here for folks to take a look. In any case, if you believe that CloudKit should be improved in some way, please feel free to provide actionable feedback for the CloudKit folks to consider. Best, —— Ziqiao Chen  Worldwide Developer Relations.