“NSPersistentCloudKitContainer”

BAD_REQUEST typically means that the CloudKit server receives an invalid request. That can happen when, for example, your request has a CloudKit record or field that doesn't exist in the CloudKit schema. You mentioned your development scheme had been fully deployed to production, but that doesn't completely rule out the possibility of having invalid requests. For example, if you are using Core Data / SwiftData + CloudKit (NSPersistentCloudKitContainer), and the Core Data / SwiftData model in your app isn't completely mapped to the CloudKit schema, a bad request may happen. What CloudKit API are you using? For Core Data / SwiftData + CloudKit and the CloudKit framework, you might consider capturing and analyzing a sysdiagnose to hopefully find detailed messages that indicate the concrete reason of a bad request. If you are only using NSUbiquitousKeyValueStore, or using file system APIs to access iCloud Drive, you don't directly get involved to CloudKit requests, and so I’d suggest that you file a feed

Did you wait some time to make sure the error didn't pop up? It might take a minute or two. Try inserting a record then re-running and waiting a few minutes. Yeah, I've tried waiting until seeing the new record being synchronized across my devices, and haven't seen the issue. NSKeyedUnarchiveFromData is the default transformer and comes to play when you use a Core Data / SwiftData transformable attribute without explicitly specifying a transformer. Unless you are using a transformable attribute, it shouldn't be engaged. My best guess is that your CloudKit schema / data contains something that needs a transformer (due to your historical changes?), and that triggers the error when NSPersistentCloudKitContainer tries to synchronize the data from the server to your device. If that is the case, consider cleaning up the schema and data on the CloudKit server. Assuming you are on the CloudKit development environment, you can remove the existing schema and data by resetting the environment, and then re-creat

Yeah, I see people reporting that CloudKit synchronization on macOS doesn't happen as quickly as it does on iOS, and that it only happens when the app comes to the foreground. I don't think that is really a bug because CloudKit was designed to synchronize only when it determines appropriate. In this case, it is that CloudKit on macOS chooses to synchronize when your app comes to the foreground. To be very clear, bringing your app to the foreground doesn't always trigger a synchronization, because a synchronization may be throttled if the rate is too high. For more information, see: TN3162: Understanding CloudKit throttles TN3163: Understanding the synchronization of NSPersistentCloudKitContainer In the production environment, that may not be a real issue, because people typically don't put their devices side by side to see the synchronization. Instead, they typically use your app on one device, and switch to another device some time later. When they switch the device and bring your app up, the synchr

@Nick: Initialising against the private database as you suggested works on iOS 14.5. It would be really useful if that was in the documentation for initializeCloudKitSchema() if it's not likely to be fixed to support initialising against a public database, to avoid others falling into the trap I did! I've commented to that effect on FB8995024, too. On iOS 15, I can't verify if that's also the case yet because of FB9156476 (the feedback I created during our lab session). For the sake of anyone else who finds this thread, the error that feedback refers to is below. FB9156476 (iOS 15 NSPersistentCloudKitContainer can't sync initial data from server with “Failed to sync user keys”) error: 2021-06-10 21:51:53.672655+0100 MyApp[1230:15921] [error] error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(955): : Failed to set up CloudKit integration for store: (URL: file:///Users/steve/Library/Developer/CoreSimulator/Devices/59435252-2CF1-4980-8ABB-4B46B21385AA/data/Conta

The reason your main app doesn't update when your widget changes the shared store is most likely because the viewContext in your main app doesn't automatically detect and merge remote changes. Here, remote changes mean the changes made by a different process, or by using batch processing. Your main app can detect and handle remote changes in the following way: Observe the the .NSPersistentStoreRemoteChange notification to get notified of any remote change. In the notification handler, consume the store persistent history to detect the relevant changes and merge them to the managed object context tied to your main app UI. Alternatively, you can manage to reset the context, and then re-fetch, which should give you the up-to-date data. For more information about this topic, see the following Apple sample projects: Loading and Displaying a Large Data Feed. Sharing Core Data objects between iCloud users. Regarding using Core Data + CloudKit (NSPersistentCloudKitContainer) in an extension, I'd like to sugg

The following console log says that your app detected an account switching at the beginning of the launch process, which may erase the existing data created before the switching. It also says that you were using a simulator. CoreData: warning: CoreData+CloudKit: -[PFCloudKitSetupAssistant _checkUserIdentity:]_block_invoke_3(1487): : CKIdentity record has changed from _b09f3f2b1357d21fdd823f58762f6077 to _4e8dc229775b034192825a3081a709a4 error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(1242): : Failed to set up CloudKit integration for store: (URL: file:///Users/yuanping_ke/Library/Developer/CoreSimulator/Devices/BA9191E9-6DB4-4A30-9196-0A6C06A11F2E/data/Containers/Data/Application/5977FE0D-50D4-4AE0-8134-5D8B0B662298/Library/Application%20Support/default.store) Later your app did successfully set up CloudKit integration, as shown below, and then did several successful exports and imports, but it seems that there is no change merged into the store. CoreData: warning:

Both methods experience delays when synchronizing a large amount of data at once. We are using two methods: During the initial installation, we call the below code to receive synchronization data and provide a user experience indicating that synchronization is in progress. public extension NSPersistentCloudKitContainer { func waitForCloudKitEvents(timeout: Int) async throws -> NSPersistentCloudKitContainer.Event? { let affectedStores = persistentStoreDescriptions .filter { description in description.cloudKitContainerOptions != nil } .compactMap { description -> NSPersistentStore? in guard let url = description.url else { return nil } return persistentStoreCoordinator.persistentStore(for: url) } let context = newBackgroundContext() let request = NSPersistentCloudKitContainerEventRequest.fetchEvents(after: .distantPast) request.resultType = .events request.affectedStores = affectedStores for seconds in 0...timeout { await Task.sleep(seconds: 1) let results: NSPersistentStoreResult = try context.e

For a large dataset, the initial synchronization with CloudKit, which can happen in several cases, including on-boarding a new device, can indeed be slow, or even failed. A similar issue was discussed in this thread as well. Depending on your concrete use case, you might address the issue in the following way: Have your app functional before the dataset is fully synchronized. Synchronize the data in batches in the background, until the whole data set is done. As an example, an email app that is just installed on a new device allows users to compose a new email, while synchronizing existing emails in the background. When using the CloudKit framework, you control what kind and amount of data to be synchronized with CloudKit, and hence can implement the strategy, though the implementation can be quite involved. Now that you are using SwiftData + CloudKit integration, NSPersistentCloudKitContainer takes care the synchronization process. I don't really see anything to work around or mitigate the issue in

One root cause that we have identified for this issue is removing a many-to-many relationship from your model. This is supposed to be a supported migration, so we are collecting feedback reports to track against that as a bug. If you would like to be notified of a fix for that share your feedback number here and we can relate them together. As a workaround you can simply add the relationship back. Or, attempt a more detailed / invasive solution described below. Our schema is public and described here: https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/reading_cloudkit_records_for_core_data Your container will contain CDMR records that identify the offending relationship. The fields CD_entityNames and CD_relationships can be used to tell which relationship a record represents. One (or more, depending on how many relationships you removed) of those records may be causing this issue. You can choose to: Add the missing relationship back to your model Delete the offending

For anyone else finding this:You need to call container.initializeCloudKitSchema() after container.loadPersistentStores.You don't really need to call container.initializeCloudKitSchema() at all, as CloudKit will create your schema on the fly. initializeCloudKitSchema just sends some fake data for your model, so it's handy to see if anything's going to break that Xcode didn't warn you about.Here's some code that works in Xcode 11 beta 5 to initialize an NSPersistentCloudKitContainer using a local store and a cloud store (see the Manage Multiple Stores section of the Setting Up Core Data doc). // MARK: - Core Data stack /// Convenience method so you can do DataManager.shared.context instead of DataManager.shared.persistentContainer.viewContext. lazy var context = self.persistentContainer.viewContext /// persistentContainer.viewContext lazy var persistentContainer: NSPersistentContainer = { /* The persistent container for the application. This implementation creates and returns a container, having loade

This is all very confusing to me... ...and it's quite possible that this 'bug' is something I'm doing wrong when ingesting data from a backup file, despite it all appearing to save to Core Data just fine. But why now though? Why has it been working just fine for almost 2 years without modification? Backup Restore Process The backup file that my users create is a serialised dictionary file, which includes encoded data for images (if present). When I restore it, I use a private context to ingest it on a background thread, with a progress bar being updated on the main thread. As I do not want partially imported data to be incorporated into the user's Core Data store I only save the context at the end of the import when successful. This has been working flawlessly for the past 2 years with NSPersistentCloudKitContainer, with the data syncing after the import finishes and is saved to Core Data... but was it only working by accident all this time!? Should I not be using the private context to save imported

I’m seeing the same error on both Xcode 15.0 and Xcode 15.1 Beta. For me, I think this issue stemmed from NSPersistentCloudKitContainerOptions. I’m using NSPersistentCloudKitContainer in my app. If I set NSPersistentStoreDescription.cloudKitContainerOptions to nil, this error would go away. Of course my app can’t sync via CloudKit if I do that. Another issue may or may not related to this warning: ever since I built my app on Xcode 15, I’ve seen excessive disk read on the sqlite file of CoreData on launch. The amount of disk read can be as much as twice the size of the sql file, basically making the app impossible to use for some users with large data set. But if cloudKitContainerOptions is nil, this excessive disk read would disappear. Last issue may or may not related to this warning: the size of CoreData sqlite file in my app is 130 MB. But in iPhone Settings → [User Name] → iCloud → Manage Account Storage, it says my app takes up a whopping 2.7 GB of space. No matter how the calculation is done,

If I'm reading between the lines, after looking at Persistent History Tracking, I think the content will be downloaded in the order it was created. Although the single article, Consuming Relevent Store Changes, I read in the developer docs assumes some familiarity with the technology, which I have none, it doesn't actually mention iCloud or CloudKit. I still have to watch the WWDC video that introduces Persistent History Tracking, so I'm hoping What's New in Core Data 2017, answers a lot of questions, (although I don't have my hopes up considering it's pre-Core Data for CloudKit), because the Persistent History section in the documentation, is just an API reference with zero actual explanation of the technology. When I said my data model represents something like the macOS file system, I was implying it was an analogy. My app doesn't really have concrete directories or files. It's the tree structure I was trying to explain.My situation is slighly more complex than you might imagine, because of the seed data I

There isn't, and I see that an as-designed behavior. When a file is queued for a Watch Connectivity transfer, or a change is queued for a Core Data + CloudKit export, it is up to the system to decide when the operation should happen. That is for optimizing the overall system performance, and there is no way for developers to change the behavior. This is documented in the following API reference and technote respectively: transferFile(_:metadata:): The system attempts to send files as quickly as possible but may throttle delivery speeds to accommodate performance and power concerns. TN3164: Debugging the synchronization of NSPersistentCloudKitContainer The goal of implementing such a mechanism is to balance the use of system resources and achieve the best overall user experience on the devices. There is no API for apps to configure the timing for the synchronization. So even you have your watchOS app run in the background (for a period of time) using something like background workout processing or Hea

In CloudKit development environment, when your app creates a record, CloudKit automatically creates the record type, if it doesn’t exist. With that, if you ever persist (at least) an instance for each of your SwiftData type, and the instance is pushed to CloudKit, the CloudKit schema will have the record type for you. Otherwise, the record type will be missed. initializeCloudKitSchema(options:) works by creating a set of representative records, uploading them to CloudKit, and removing them. This may help if it is indeed that no instance of your new SwiftData type has ever been uploaded to CloudKit. Note that even initializeCloudKitSchema(options:) can miss something, and that is why I called out the following: After running the target, use CloudKit Console to ensure each Core Data entity and attribute has a CloudKit counterpart. See Reading CloudKit Records for Core Data for the mapping rules. The documentation discusses how NSPersistentCloudKitContainer maps a Core Data model to a CloudKit schema,