NSPersistentCloudKitContainer

Ok I've narrowed the issue down. If my call to setParent on the Chat object (line 13 above of the first code listing). If I remove this line. Everything works and my two references are saved so each record has a reference to each other. However I believe then that I'm missing the benefits of using setParent? So that when I do an update to a child object things are kept in sync? Or is setParent only to be used when using CoreData/CloudKit syncing that was introduced in 2019 with NSPersistentCloudKitContainer? I'm not using that (as much as I'd like to) because I need to share my records. So I'm doing the Core Data/Cloud Kit syncing myself.

How can I confirm this behavior when migrating using NSMigrationManager? I don't think you need to explicitly checkpoint the store. The Core Data migration process should handle that for you – If it doesn't, I'd see that a framework bug When I enable com.apple.CoreData.MigrationDebug the lightweight migration logs the WAL checkpointing, however, when using NSMigrationManager no such log appears. When I tried inserting 1000 objects, all of them get inserted into the sqlite file. Nothing gets inserted in WAL file. Is the behavior different for NSPersistentCloudKitContainer? Regarding the error, did you try to set up options in the following way: Yes, this works. However, if the NSMigrationManager handles this then should be avoided, right?

I don’t think this last comment is accurate, at least as of iOS 15. In digital lounges at WWDC Apple engineers explained it is possible for NSPersistentCloudKitContainer to sync while your app is open in the background. It seems though the work is scheduled with utility priority. In my testing it will sync if you make 4 changes - once enough updates are accumulated it’ll process them. But even then my widget is showing the changes from the 3rd update because it hasn’t yet finished updating it seems, and attempting to delay it causes the code not to execute I assume because iOS suspends the app again very soon after. So basically it may eventually sync in background, only if your app is already open in background, and it may not be reliable and your widget might not get the most up-to-date data. Maybe this can be improved by utilizing background task API, that’s what they suggested trying in the digital lounge. Do note they also said NSPersistentCloudKitContainer does not support multi-proces

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

Short Answer: It is a bug. Just run (command + R) your app then stop it. Then talk to your Siri. You will see the new Item is added to your list. I think debugger stops core data to be updated from external events. Long Answer: I also tried many different approaches in the web and nothing worked. But here is the simplest code that I could add item to my list via Siri. Simply setup your PersistenceController public struct PersistenceController { public static let shared = PersistenceController() public let container: NSPersistentCloudKitContainer init(inMemory: Bool = false) { container = NSPersistentCloudKitContainer(name: YourApp.) if inMemory { container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: /dev/null) } else { let storeURL = AppGroup.coredata.containerURL.appendingPathComponent(YourApp.sqlite) let description = NSPersistentStoreDescription(url: storeURL) container.persistentStoreDescriptions = [description] } container.loadPersistentStores(completionHandler: { (sto

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

I'm sorry, I thought I'd already replied to this... destroyPersistentStore isn't the right API that deletes the data lol Can you clarify what you mean by destroy those CoreData objects? What I mean by destroy here is get rid of your reference to the read/write NSPersistentCloudKitContainer object. That will then: Free up some memory (minor benefit). Ensure that you can't accidentally get a read/write object reference, since your app won't have a reference to the object that COULD have given you one. (major benefit). In code level terms, this would mean either NULL out a var reference or having the let go out of scope. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Assume the public database contains 10,000+ Locations from which a User would select a few as favorites How large are these locations? For example 10k CLLocation objects is a trivially small dataset for CoreData to manage. It could be downloaded in seconds or minutes and queried extremely efficiently in local storage with indexed fields or via Spotlight. Sending out a CKQueryOperation for each search requires network and unnecessarily drains a customers battery. NSPersistentCloudKitContainer supports millions of records as long as they fit in local storage. Another approach is to simply ship the locations with your application in a CoreData store that's part of your application bundle and added as a read-only store to the container.

hi, it may be as simple as not turning on history tracking. in my code, i usually have these lines right after creating the NSPersistentCloudKitContainer: // (1) Enable history tracking. this seems to be important when you have more than one persistent // store in your app (e.g., when using the cloud) and you want to do any sort of cross-store // syncing. See WWDC 2019 Session 209, Making Apps with Core Data. guard let persistentStoreDescription = container.persistentStoreDescriptions.first else { fatalError((#function): Failed to retrieve a persistent store description.) } persistentStoreDescription .setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) persistentStoreDescription .setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) hope that helps, DMG

HI, Asking for more background time doesn't feel like a solution, that will just postpone the crash. Actually, that is the answer, at least partly. The reason this can't really happen: In my naiveté I assumed that NSPersistentCloudKitContainer and Core Spotlight would release any locks when app is suspended. ...is that the system can't really know in advance what you're going to ask it to do. They actually take out some of their own tasks, but that doesn't really help if the suspension process is starting at roughly the same time you're asking them to do work. That solution here is to create your own background task for the larger job that you're trying to finish (Add some stuff to my CoreSpotlight index) and end it once the work is done. -Kevin Elliott DTS Engineer, CoreOS/Hardware

The crash you’re seeing— FAULT: NSInternalInconsistencyException: This NSPersistentStoreCoordinator has no persistent stores (unknown). It cannot perform a save operation. (Apple Developer) —happens because by the time your onAppear runs, the debug block has already loaded and then removed the only store from the underlying NSPersistentCloudKitContainer. When you immediately call newContainer = try ModelContainer(for: Page.self, configurations: config) SwiftData’s internal coordinator finds no stores to save into and throws. The fix is to perform both the CloudKit‐schema initialization and your ModelContainer setup early, in your App struct (or in its init), rather than inside an onAppear. That way SwiftData creates its SQLite store after you’ve torn down the temporary CloudKit container, so it can recreate a fresh store. For example: @main struct MyApp: App { // 1) Build your debug store, initializeCloudKitSchema, remove it… // 2) Then immediately create the SwiftData ModelContainer private var mode

Please file a bug report with Apple using Feedback, if you haven't already done so. Quote my report FB9859660. I am in the same situation as you, and feel as though I'm the only one! I too don't know what to say to my users, other than Apple have a bug and they are working on it, with no timescale for resolution. People are not happy! It was working perfectly well in iOS14. Now it's not in iOS15. Instruments suggests to me that there is probably a memory leak in NSPersistentCloudKitContainer. Large spikes in Virtual Memory usage on all imports (even the small ones) but the small ones dont trigger a crash. The same (smallish) database in iOS14 uses 36MB of VM but in iOS15 uses 1.49GB for example!!

I might have answered my own question. First, add a managedObject variable to the TimelineProvider and a initializer: struct Provider: IntentTimelineProvider { var managedObjectContext : NSManagedObjectContext init(context : NSManagedObjectContext) { self.managedObjectContext = context } ... Then initialize the persistentContainer within the Widget struct and pass the persistentContainer.viewContext into the new Provider initializer: struct Widget_Extension: Widget { private let kind: String = Widget_Extension public var body: some WidgetConfiguration { IntentConfiguration(kind: kind, intent: ConfigurationIntent.self, provider: Provider(context: persistentContainer.viewContext), placeholder: PlaceholderView()) { entry in Widget_ExtensionEntryView(entry: entry) } .configurationDisplayName(My Widget) .description(This is an example widget.) } var persistentContainer: NSPersistentCloudKitContainer = {... return container }() The Provider now has access to your CoreData+CloudKit data.

@eskimo I am using Logger (OSLog) and I don't want debug messages from frameworks like mentioned below. What should I do to achieve that? When I use CoreData / CloudKit especially NSPersistentCloudKitContainer I do see a lot of debug messages such as the ones below: CoreData: debug: CoreData+CloudKit: -[PFCloudKitOptionsValidator validateOptions:andStoreOptions:error:](36): Validating options: containerIdentifier: databaseScope:Private ckAssetThresholdBytes: operationMemoryThresholdBytes: useEncryptedStorage:NO useDeviceToDeviceEncryption:NO automaticallyDownloadFileBackedFutures:NO automaticallyScheduleImportAndExportOperations:YES skipCloudKitSetup:NO preserveLegacyRecordMetadataBehavior:NO useDaemon:YES apsConnectionMachServiceName: containerProvider: storeMonitorProvider: metricsClient: metadataPurger: scheduler: notificationListener: containerOptions: defaultOperationConfiguration: progressProvider: test_useLegacySavePolicy:YES archivingUtilities: bypassSchedulerActivityForInitialImport:NO stor

Since the log still says that 'recordName' is not marked queryable, I am wondering if the CloudKit container and environment you are examining are exactly the same – If you are viewing the development environment in CloudKit Console, while your app is working with the production one, you would need to deploy your CloudKit schema to the production environment. You might also consider removing the existing index and creating a new one to see if it is that the existing index was broken for some reason. If it is indeed that the view in CloudKit Console isn't consistent with what NSPersistentCloudKitContainer reports, I’d suggest that you file a feedback report to see what the CloudKit folks have to say – If you do so, please share your report ID here. Best, —— Ziqiao Chen  Worldwide Developer Relations.