NSPersistentCloudKitContainer

I have a CoreData model with two entities, 'User' and 'Player', that both use 'Person' as their 'Parent Entity'. While the App appears to work correctly in the simulator, including with CloudKit via NSPersistentCloudKitContainer, I get a crash in Xcode Previews: libswiftCore.dylib [ AGScoringModel/Persistence.swift:183: Fatal error: #init(inMemory:): Failed to load persistent stores:Error Domain=NSCocoaErrorDomain Code=134110 An error occurred during persistent store migration. UserInfo={sourceURL=file:///Users/ebg/Library/Developer/.../CoreDataStores/private/database.sqlite, reason=Cannot migrate store in-place: Cannot merge multiple root entity source tables into one destination entity root table, destinationURL=file:///Users/ebg/Library/Developer/.../CoreDataStores/private/database.sqlite, NSUnderlyingError=0x600000ce02a0 {Error Domain=NSCocoaErrorDomain Code=134110 An error occurred during persistent store migration. UserInfo={message=Cannot merge multiple root entity source tables into one desti

How does one know when the CloudKit data in a CoreData+CloudKit (NSPersistentCloudKitContainer) has been fully synchronized. UseCase would be a user starts the App on a second device, user deletes then reinstalls the App, another User accepts a share and the share needs to sync. Is the containerEventChanged Notification for 'import success' the definitive event? CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _finishedRequest:withResult:](3403): Finished request: 729A742A-7F3B-42F1-B04C-72705D41FFEF with result: storeIdentifier: 79FA5848-A135-41B1-A36A-09F2F914D23D success: 1 madeChanges: 0 error: (null) As the sync could be time-consuming, is there a way to identify a single CloudKit record?

Before the code... CloudKit, background mode (remote notifications) and push notifications are added to Capabilities. Background sync is working fine and view loads current store on manual fetch. Code that initialises the persistent container in app delegate... - (NSPersistentCloudKitContainer *)persistentContainer { // The persistent container for the application. This implementation creates and returns a container, having loaded the store for the application to it. @synchronized (self) { if (_persistentContainer == nil) { _persistentContainer = [[NSPersistentCloudKitContainer alloc] initWithName:@Expenses]; [_persistentContainer loadPersistentStoresWithCompletionHandler:^(NSPersistentStoreDescription *storeDescription, NSError *error) { if (error != nil) { __block NSPersistentStoreDescription *sDescription = storeDescription; dispatch_async(dispatch_get_main_queue(), ^(){ [sDescription setOption:[NSNumber numberWithBool:YES] forKey:@PersistentHistoryTracking]; [sDescription setOption:[NSNu

I am working on an interactive widget and merging changes provided by a user over it with the app. I store my data, using Core Data. However, I noticed an issue with sync between other user's devices after that person made a change over the widget (in my case, it is completing a task). Here is my schema: Main app: it looks for relevant transactions (https://developer.apple.com/documentation/coredata/consuming_relevant_store_changes). When it found that one, the app merges changes: if transaction.author == widget { if let userInfo = transaction.objectIDNotification().userInfo { NSManagedObjectContext.mergeChanges(fromRemoteContextSave: userInfo, into: [taskContext]) } } Widget: If the user clicks on the checkbox in order to complete a task, using an AppIntent class, app creates an identical NSPersistentCloudKitContainer and completes the task. However, in that case, the NSPersistentCloudKitContainer of the widget does not look for changes. That works correctly. However, only in a local enviro

I work on a MacOS app (which has a companion iOS app) that uses Core Data with NSPersistentCloudKitContainer. The app also supports widgets and hence there is a need to migrate the persistent store within the core data stack using replacePersistentStore( at:.... During development I recently created a new model version and added a new entity, replaced some attributes etc... Working on the iOS app is fine because deleting the app clears all the data allowing me to work with a clean slate. On MacOS, I initially thought that I could simply navigate to the app group file location, delete the .sqlite file, along with the sqlite-shm and sqlite-wal. I also went and deleted the CloudKit related files. I did all of this out of pure ignorance - my expectation was that it would give me a clean slate, but it did not. This instead gave me some unpredictable behaviour, but the app was always in a bad state. the issues I saw were; • migration failure, • sqlite errors highlighting no such column: t0 - where all the

So I've been developing happily with CoreData+CloudKit for a while now, and really haven't run into any issues until this. I've migrated my model a couple of times, and it worked fine, but this was the first time I added a new entity to the model. If I run on a device (any device, iPhone, iPad, Mac via Catalyst), I get a migration error. Here's the entirety of my persistentContainer setup: public var persistentContainer: NSPersistentContainer = { let modelPath = Bundle(for: CoreDataStack.self).url(forResource: Progress, withExtension: momd)! let model = NSManagedObjectModel(contentsOf: modelPath)! let container = NSPersistentCloudKitContainer(name: Progress, managedObjectModel: model) container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { print(storeDescription) fatalError(Unresolved error (error), (error.userInfo)) } }) return container }()And here's the error I'm getting:Callstacks=true}}}CoreData: annotation: : Attempting recovery from e

I've encountered a significant sync issue with watchOS 10 RC on every device combination I've tested, running both iOS 17 and watchOS 10. I'm curious if others have noticed a similar problem. Context: Standalone watchOS app developed in SwiftUI with a companion iOS app. Both apps use NSPersistentCloudKitContainer for bi-directional CloudKit CoreData Sync between the iOS app and watch. Previously, this sync mechanism was near instant in the foreground and took max 1-2 minutes in the background NSPersistentCloudKitContainer has been reliable since the app was first developed in the watchOS 6/iOS 13 era. Issue: In watchOS 10 RC, sync can take hours--and doesn't even occur when the app is in the foreground. Sync only reliably happens when the watch is placed on the charger, seemingly only if the charge is over 50%. Once taken off the charger, the watch will continue push and receive CoreData changes briefly before becoming unresponsive to sync again. Additional Info: The problem persists even wh

Hello, I'm running into an odd error. I'm trying to add a composite attribute called period to a Core Data Entity named Report, but I'm getting a compile-time error that points to my xcdatamodel file: Report.period cannot use an attribute type of Composite. In my model configuration I have Used with CloudKit box checked. If I uncheck this box, the error goes away and everything builds fine. But the documentation for NSCompositeAttributeDescription says: You may use composite attributes anywhere you use standard attributes, including lightweight migrations and CloudKit, through NSPersistentCloudKitContainer. So it seems like I should be able to use composite attributes in Core Data with CloudKit syncing enabled. What am I missing here? Is this a bug, or am I doing something wrong?

Hi, Xcode warns me that NSPersistentContainer, NSManagedObjectContext, NSPersistentHistoryTransaction and NSPersistentHistoryToken are non-Sendable types and therefore cannot cross actor boundaries. These warnings occur even when I use @preconcurrency import CoreData (only works with Xcode 14.0 Beta, in Xcode 13.4.1, it says '@preconcurrency' attribute on module 'CoreData' is unused) I understand that types in Core Data have yet to be marked as Sendable when it makes sense. Although NSPersistentHistoryTransaction, and NSPersistentHistoryToken are reference types, they should qualify to be marked as Sendable in the future since these are immutable types, am I right? NSPersistentContainer provides variables and methods like viewContext and newBackgroundContext(). It would make sense that this type is thread-safe. However, I'm not sure about it, especially regarding its loadPersistentStores(completionHandler:) method. Is NSPersistentContainer (and its subclass NSPersistentCloudKitContainer) thread-safe

I have an app that uses NSPersistentCloudKitContainer and a widget that displays a record. I want to add a button with interactive widgets in iOS 17 to modify the visible record via an AppIntent. When I do this the app logs: CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2945): : Observed context save: - It does not automatically sync this change to iCloud, not until I manually return the app to the foreground, even if I delay returning from the perform() function. Is there a way to sync NSPersistentCloudKitContainer while the app is in the background as a result of this change triggered in the widget? Thanks!