NSPersistentCloudKitContainer

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

Hi cristosv, Thanks for posting your solution to this online. I'm having the same problem, but it would be great it for you could help a little more. For example, all your code is working fine, but I can't seem to figure out how to use my core data entity in a Text() view in my widget. Below is my code, and any help with this or more sample code would be great. Thanks 🙏 import WidgetKit import SwiftUI import Intents import CoreData struct Provider: IntentTimelineProvider { func placeholder(in context: Context) -> SimpleEntry { SimpleEntry(date: Date(), configuration: ConfigurationIntent()) } func getSnapshot(for configuration: ConfigurationIntent, in context: Context, completion: @escaping (SimpleEntry) -> ()) { let entry = SimpleEntry(date: Date(), configuration: configuration) completion(entry) } func getTimeline(for configuration: ConfigurationIntent, in context: Context, completion: @escaping (Timeline) -> ()) { var entries: [SimpleEntry] = [] // Generate a timeline consisting of five entries an

HiI try to use the NSBatchInsertRequest. but the insertResult is nil, and my CoreData is emptyI use the viewContext of the NSPersistentCloudKitContainer.let container = NSPersistentCloudKitContainer(name: CoreDataPerformance) container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } }) try container.viewContext.setQueryGenerationFrom(.current) let moc = container.viewContext moc.automaticallyMergesChangesFromParent = true moc.perform { let insertRequest = NSBatchInsertRequest(entity: Client.entity(), objects: clients) let insertResult = try? moc.execute(insertRequest) as? NSBatchInsertRequest if let success = insertResult as? Bool { print(RESULT: (success)) } }This is the error I receive in the console.2020-02-04 18:30:25.800705+0200 CoreDataPerformance[62836:778869] [error] warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'CoreDataPerformance.Client' so +entity

Sorry, Apple... this is still broken in iOS 15.1 (beta 2) The CPU & RAM usage is still excessive and no syncing occurs at all. I've replied to my TSI in the hope I can get someone to look into this as a matter of urgency. I now have users running iOS 15 who are no longer seeing their data syncing via iCloud, resulting in a terrible user experience, using my app downloaded from the App Store which has been unchanged since iOS 14. Whatever Apple did in iOS 15 beta 4 to NSPersistentCloudKitContainer, they broke it badly. Maybe users who don't have complex databases aren't seeing this problem, but the whole point of NSPersistentCloudKitContainer is to sync a Core Data store with complex relationships (and besides, it works just fine on iOS 13 & iOS 14!). My testing setup Monterey (beta 8) Xcode 13 (13A233) non-beta Testing on iPhone 13 Pro with iOS 15.1 (beta 2) Preparation Deleted iCloud data for my app Deleted my app from the device (App Store download) Rebooted device Reset the iCloud

I have recently been experiencing issues in the Production Environment as well, although I cannot confirm if it is the same situation. My app is Mac only. I am adding iCloud support to an existing app that is already on the Mac App Store. I am testing such support via TestFlight builds. I am not using SwiftData but traditional Core Data with NSPersistentCloudKitContainer. – When making use of the Production Environment, only partial synchronization took place. This has not been an issue when run in the Development Environment. This occurred multiple times even when testing using accounts with different App IDs. My only thought was that perhaps iCloud also needed to be enabled as a Capability in Certificates, Identifiers & Profiles. That did not end up being the case. However, I was surprised to see that two iCloud Containers were enabled for this app even though only one was selected for the target in Xcode. After removing the unused container from the list and saving, I performed the following a

This error message your post provided indicates that Core Data failed to unarchive the import request (NSCloudKitMirroringImportRequest). Archiving / unarchiving an import / export request is a Core Data internal logic, and so I agree your assessment that it is not about your code. The feedback report you filed (FB10392936) doesn't mention the error message, and so I'd suggest that you file a new one to specifically report the error – If you do so, please share your report ID here for folks to track. Regarding FB10392936, you most likely hit CloudKit throttles. For more information of this topic, see the following documentations: TN3162: Understanding CloudKit throttles Understand system throttles. When uploading a big data set and hitting CloudKit throttles, the only thing you can do is to lower the CloudKit operation rate. When using Core Data + CloudKit, however, you don't control how NSPersistentCloudKitContainer synchronizes data. Based on today's API, the only thing you can do is to somehow con

I wanted to give this thread a bump because I too am facing the same issue. The proposed answer from rr0924, and the referenced article from Antoine van der Lee, does not work for me either. To inject my CoreData model into the Widget extension one failing attempt I've tried was to use a similar method in my iOS app and watchOS companion app. For example this code will allow proper access to CoreData from iOS and watchOS; @main struct RunRosterApp: App { @Environment(.scenePhase) private var scenePhase @StateObject private var persistentStore = PersistentStore.shared var body: some Scene { WindowGroup { ContentView() .environment(.managedObjectContext, persistentStore.context) } } The PersistentStore class is a set up as a singleton to load the NSPersistentCloudKitContainer. That code is fairly boiler plate so I won't post it but can upon request. Using a similar pattern in WidgetKit and SwiftUI I currently have this; @main struct WidgetRunPlanner: Widget { @StateObject private var persistentStore =

Did you get this to work? I have a similar need, that is, to offer iCloud storage and sync as a premium feature. I have CloudKit sync working but how do I switch it off? I want to disable CloudKit sync and only enable it when a customer pays for the premium version. I've tried setting the container's cloudKitContainerOptions property to nil but CloudKit sync still happens.Here's my Core Data stack:private lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentCloudKitContainer(name: modelName) let localDescription = NSPersistentStoreDescription(url: configurationsURL.appendingPathComponent(local.sqlite, isDirectory: false)) localDescription.configuration = Local let cloudDescription = NSPersistentStoreDescription(url: configurationsURL.appendingPathComponent(cloud.sqlite, isDirectory: false)) cloudDescription.configuration = Cloud cloudDescription.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: cloudKitContainerIdentifier) cloudDescrip

When there's a crash in WidgetKit, it often goes unnoticed by developers and users because there's no clear indication within the widget itself. In contrast, a crash in the main app is more apparent because it causes the app to close suddenly. One theory, as discussed in this https://developer.apple.com/forums/thread/668649, is that the main app and the widget are attempting to perform a migration simultaneously. However, I'm skeptical of this theory because our last CoreData migration began last year. Therefore, it's surprising to see a high number of crashes after a year. Here's where fatal error occurs. It is a pretty standard CoreData stack used in widget. private static func setupNSPersistentContainer() -> NSPersistentContainer { precondition(Thread.isMainThread) let container = NSPersistentCloudKitContainer(name: xxx, managedObjectModel: NSManagedObjectModel.xxx) // Integrate AppGroup with CoreData. If we are assigning a new store description to CoreData, it is important // to finish all sto