Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

Reply to Share Extension Lifetime and SwiftData
If you are using SwiftData + CloudKit in both your main app and extension, which uses NSPersistentCloudKitContainer under the hood, I'd start with pointing you the following technote: Avoid synchronizing a store with multiple persistent containers Please feel free to follow up with further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Oct ’25
Best Practices for Binary Data (“Allows External Storage”) in Core Data with CloudKit Sync
Hello Apple Team, We’re building a CloudKit-enabled Core Data app and would like clarification on the behavior and performance characteristics of Binary Data attributes with “Allows External Storage” enabled when used with NSPersistentCloudKitContainer. Initially, we tried storing image files manually on disk and only saving the metadata (file URLs, dimensions, etc.) in Core Data. While this approach reduced the size of the Core Data store, it introduced instability after app updates and broke sync between devices. We would prefer to use the official Apple-recommended method and have Core Data manage image storage and CloudKit syncing natively. Specifically, we’d appreciate guidance on the following: When a Binary Data attribute is marked as “Allows External Storage”, large image files are stored as separate files on device rather than inline in the SQLite store. How effective is this mechanism in keeping the Core Data store size small on device? Are there any recommended size thresholds or known lim
2
0
278
Oct ’25
Reply to Cloudkit only syncs when app is reloaded.
You might start with the following technote section: Present the latest data If that doesn't immediately help, the following technotes cover the details about how CoreData + CloudKit works and how to debug a synchronization issue: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3164: Debugging the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Topic: Design SubTopic: General Tags:
Oct ’25
Reply to Best Practices for Binary Data (“Allows External Storage”) in Core Data with CloudKit Sync
Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization thres
Oct ’25
Reply to SwiftData and CloudKit not synching between devices
Our general set of debugging / inspection Tech Notes are: https://developer.apple.com/documentation/technotes/tn3163-understanding-the-synchronization-of-nspersistentcloudkitcontainer https://developer.apple.com/documentation/technotes/tn3162-understanding-cloudkit-throttles https://developer.apple.com/documentation/technotes/tn3164-debugging-the-synchronization-of-nspersistentcloudkitcontainer
Oct ’25
Reply to SwiftData and CloudKit not synching between devices
Just to add that SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the technotes my colleague mentioned apply to your topic. Specifically, you can use CloudKit Console to determine if the data is synchronized to CloudKit. From there, you can determine if the issue happens on the exporting or importing side, and go ahead to capture and analyze a sysdiagnose, as described in the Capture and analyze a sysdiagnose section. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Oct ’25
Reply to I want to make sure to make my app’s data persist across devices, updates, and reinstalls, you need to store it in the cloud.
For data that needs to be accessible across multiple devices (that are logged in with the same Apple ID), even when your app is removed from one of them, consider using cloud storage services, which allow data to be synced across all devices. To use Apple's cloud service, you can look at the following APIs: CloudKit NSPersistentCloudKitContainer NSUbiquitousKeyValueStore iCloud documents This is a lot of things, but it gives you the whole picture about what the platforms have so you can pick the one that fits your use case best. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Oct ’25
Reply to CloudKit - moving record objects between zones
If you are using SwiftData + CloudKit, which is based on NSPersistentCloudKitContainer, it doesn't support cross-share relationships, and so you can't have a collection in one zone and a relationship of the collection (a sub-collection, for example) in another. This is mentioned in here: NSPersistentCloudKitContainer doesn’t support cross-share relationships. That is, it doesn’t allow relating objects associated with different shares. When sharing an object, NSPersistentCloudKitContainer moves the entire object graph, which includes the object and all its relationships, to the share’s record zone. If you are using the CloudKit framework directly, the source and target objects of CKRecord.Reference must be in the same zone of the same database, and so you will need to maintain the relationship with your own logic. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Topic: Community SubTopic: Apple Developers Tags:
Nov ’25
Reply to Strange behavior with 100k+ records in NSPersistentCloudKitContainer
I’m having a similar problem. I found a reddit post about this issue where the author writes, “I’m guessing it only shows up for devs who bulk import/delete during testing, while normal users with a few hundred records never notice.” Which makes sense because I am also bulk importing. I’m seeing about a 6-8 times increase between the local storage and CloudKit. (Specifically, 15k records comes out to around 13mb of local storage, but 100mb with CloudKit enabled. ANSCKRECORDMETADATA appears to be the main culprit.) I’m making a flashcard app, and of course users can import as many cards as they want, which could become a storage problem pretty quickly. From my understanding, and as you mentioned, a storage increase is expected. But the increase I’m seeing just seems excessive. … Or is it? I can’t really find anything on what to expect. I wonder if there’s something I can change in the model to make this work. Or maybe the problem is unique to NSPersistentCloudKitContainer and I should look at other sy
Nov ’25
NSPersistentCloudKitContainer data loss edge case
Hi, I was testing the new iOS 18 behavior where NSPersistentCloudKitContainer wipes the local Core Data store if the user logs out of iCloud, for privacy purposes. I ran the tests both with a Core Data + CloudKit app, and a simple one using SwiftData with CloudKit enabled. Results were identical in either case. In my testing, most of the time, the feature worked as expected. When I disabled iCloud for my app, the data was wiped (consistent with say the Notes app, except if you disable iCloud it warns you that it'll remove those notes). When I re-enabled iCloud, the data appeared. (all done through the Settings app) However, in scenarios when NSPersistentCloudKitContainer cannot immediately sync -- say due to rate throttling -- and one disables iCloud in Settings, this wipes the local data store and ultimately results in data loss. This occurs even if the changes to the managed objects are saved (to the local store) -- it's simply they aren't synced in time. It can be a little hard to reprodu
3
0
295
2w
Reply to NSPersistentCloudKitContainer data loss edge case
This occurs even if the changes to the managed objects are saved (to the local store) -- it's simply they aren't synced in time. This is by design. Turning off iCloud for an app is equivalent to signing out of the account. Perhaps before NSPersistentCloudKitContainer wipes the local store it ought to force sync with the cloud first? Typically that won't work. By the time an application finds out about an account transition (whether by turning off iCloud for an application or signing out) sync will just fail with CKErrorNotAuthenticated.
2w
Reply to NSPersistentCloudKitContainer data loss edge case
If a user writes changes to the app and the app saves those changes to the Core Data store, they should never be permanently deleted just because iCloud was disabled. It seems quite wrong to me that NSPersistentCloudKitContainer will delete even changes that have not been synced to the cloud. As a developer, what could I do to ensure this does not occur? I believe it is a bad idea to programmatically switch between NSPersistentContainer and NSPersistentCloudKitContainer (discouraged by Apple) and you lose privacy and security.
2w
NSPersistentCloudKitContainer in duplicate processes
I have a single multiplatform application that I use NSPersistentCloudKitContainer on. This works great, except I noticed when I open two instances of the same process (not windows) on the same computer, which share the same store, data duplication and Metadata Inconsistency errors start appearing. This answer (https://stackoverflow.com/a/67243833) says this is not supported with NSPersistentCloudKitContainer. Is this indeed true? If it isn't allowed, is the only solution to disable multiple instances of the process via a lock file? I was thinking one could somehow coordinate a single leader process that syncs to the cloud, with the others using NSPersistentContainer, but this would be complicated when the leader process terminates. Currently, it seems iPad split views are new windows, not processes -- but overall I'm still curious :0 Thank you!
1
0
213
2w
Reply to NSPersistentCloudKitContainer in duplicate processes
Is this indeed true? Yes. If it isn't allowed, is the only solution to disable multiple instances of the process via a lock file? I was thinking one could somehow coordinate a single leader process that syncs to the cloud, with the others using NSPersistentContainer, but this would be complicated when the leader process terminates. I'm skeptical that's a workable solution. Holding file locks across assertion boundaries will cause your app to get killed. However the system regularly suspends apps doing NSPersistentCloudKitContainer work for load balancing. There isn't a convenient process model for multiple apps coordinating on a shared networking space. If extensions fail to meet your use case needs, you will have to elect a leader application to manage the CloudKit sync. Other applications can access the same store file without the NSPersistentCloudKitContainerOptions set, but only one process can manage sync.
2w