Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

Reply to Persisting User Settings with SwiftData
I'd like to comment the second question a bit, as it hasn't been addressed yet: Sometimes when running on a new device it will create a second UserSettings while it is waiting for the original one to sync from CloudKit. When you use SwiftData + CloudKit, under the hood, the framework uses NSPersistentCloudKitContainer to synchronize data. In that environment, duplicate data is sometimes inevitable, which is discussed in great details in the following section: Remove duplicate data The solution is to de-duplicate the data. How to do so is discussed and demonstrated in the sample code. Back to what to what you intent to achieve, my suggestion will be: If you plan to use SwiftData + CloudKit extensively in your app, you might need to handle duplicate data anyway. In this case, persisting user settings to your SwiftData store (and Synchronizing them via NSPersistentCloudKitContainer) makes a lot of sense. If the target is as simple as saving some Cloud-based user settings, I'd probably consider
Topic: UI Frameworks SubTopic: SwiftUI Tags:
2d
Reply to SwiftData @Model: Optional to-many relationship is never nil at runtime
SwiftData default store is based on Core Data. As a historical implementation detail, at runtime, a Core Data to-many relationship, once persisted, is always a [], and never a nil. To adapt this behavior in an effective way, SwiftData always initializes a nil to-many relationship with an empty collection at runtime. So to your first question, the behavior that optional to-many relationships in SwiftData are never nil at runtime is as-designed. The requirement that relationships must be optional is a way to express that NSPersistentCloudKitContainer does not handle relationships atomically, and is enforced by a schema validator at compile time. The validation doesn't have any impact at runtime, and so SwiftData to-many relationships being [] at runtime doesn't break the CloudKit synchronization. To use SwiftData + CloudKit, you make sure your model schema is compatible with the rules so the schema validator doesn't complain, and that will be it. Best, —— Ziqiao Chen  Worldwide Developer Relations.
5d
Extreme increase in app storage size after enabling CloudKit
I have a SwiftData flashcard app which I am syncing with CloudKit using NSPersistentCloudKitContainer. While syncing itself is working perfectly, I have noticed a dramatic increase in the app size after enabling sync. Specifically, without CloudKit, 15k flashcards results in the default.store file being about 4.5 MB. With CloudKit, default.store is about 67 MB. I have inspected the store and found that most of this increase is due to the ANSCKRECORDMETADATA table. My question is, does implementing CloudKit normally cause this magnitude of increase in storage? If it doesn’t, is there something in my model, schema, implementation, etc. that could be causing it? Below are two other posts describing a similar issue, but neither with a solution. I replied to the first one about a month ago. I then submitted this to Developer Technical Support, but was asked to post my question in the forums, so here it is. Strange behavior with 100k+ records in NSPersistentCloudKitContainer Huge increase in sqlit
2
0
125
1w
Reply to Extreme increase in app storage size after enabling CloudKit
When you use SwiftData + CloudKit, under the hood, the SwiftData framework converts SwiftData models to Core Data managed objects, and use NSPersistentCloudKitContainer to synchronize the objects with CloudKit. NSPersistentCloudKitContainer mirrors each Core Data managed object to (at least) a CloudKit record (CKRecord), as described in Reading CloudKit Records for Core Data. To manage the internal state of the synchronization, it adds a few tables to the store, and the ANSCKRECORDMETADATA table is one of them, which is used to store the metadata of the CloudKit records. The metadata includes the system fields and encoded data of every CloudKit record, so yes, you can see that the size of table gets quite large. The ANSCKRECORDMETADATA table is an internal data structure that NSPersistentCloudKitContainer creates and consumes. You can review the documentation mentioned above to make sure that your models are translated to CloudKit schema correctly, but other than that, I don't see a
1w
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
291
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
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
209
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
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
WidgetKit with Data from CoreData
I have a SwiftUI app. It fetches records through CoreData. And I want to show some records on a widget. I understand that I need to use AppGroup to share data between an app and its associated widget. import Foundation import CoreData import CloudKit class DataManager { static let instance = DataManager() let container: NSPersistentContainer let context: NSManagedObjectContext init() { container = NSPersistentCloudKitContainer(name: DataMama) container.persistentStoreDescriptions = [NSPersistentStoreDescription(url: FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: group identifier)!.appendingPathComponent(Trash.sqlite))] container.loadPersistentStores(completionHandler: { (description, error) in if let error = error as NSError? { print(Unresolved error (error), (error.userInfo)) } }) context = container.viewContext context.automaticallyMergesChangesFromParent = true context.mergePolicy = NSMergePolicy(merge: .mergeByPropertyObjectTrumpMergePolicyType) } func save() { do { try c
7
0
283
Nov ’25
Strange behavior with 100k+ records in NSPersistentCloudKitContainer
I have been using the basic NSPersistentContainer with 100k+ records for a while now with no issues. The database size can fluctuate a bit but on average it takes up about 22mb on device. When I switch the container to NSPersistentCloudKitContainer, I see a massive increase in size to ~150mb initially. As the sync engine uploads records to iCloud it has ballooned to over 600mb on device. On top of that, the user's iCloud usage in settings reports that it takes up 1.7gb in the cloud. I understand new tables are added and history tracking is enabled but the size increase seems a bit drastic. I'm not sure how we got from 22mb to 1.7gb with the exact same data. A few other things that are important to note: I import all the 100k+ records at once when testing the different containers. At the time of the initial import there is only 1 relation (an import group record) that all the records are attached to. I save the background context only once after all the records and the import group have been made and
3
0
703
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
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 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