I have an app that uses cloudKit in the app store. I have now realised that I should have deployed the schema to production before releasing the app. I reset the environment and now the app crashes on startup. Is there a way back from this? Any suggestions would be greatly appreciated as I'm no longer able to preview or install the app on a device.

I am trying to deduplicate data created by NSPersistentCloudKitContainer in my app. I have a universal app, with Share Extensions on both macOS and iOS. On each platform I share a store between the app and the extension with an App Group. The app and the extensions are both configured to sync to CloudKit. (This means local sharing is handled when offline, and a remote share extension will sync to CloudKit work when the main app is closed) This configuration is causing duplicates to be generated. I believe this is because when the macOS app is open, both it and the macOS share extension will try and (almost simultaneously) sync a newly shared object, resulting in two copies in CloudKit. On the macOS app, I can look through the persistent history and see the insertion 'author'. The first insertion is made by the extension "macOSShareExtension", the second is made by "NSCloudKitMirroringDelegate.import". I could easily make a choice to delete the second object. However, at the same time, on the iOS app, I will get two insertions, both with the author "NSCloudKitMirroringDelegate.import". I don't want to deduplicate only on the macOS app in this case. That would mean the the iOS app has duplicate objects until the deduplication propagates. If I use CKRecord's creationDate to keep the first syncd Object, can I guarantee that if one Object has an associated CKRecord and the other doesn't, the one with out will subsequently gain a record with a later creationDate? Should I be taking a different approach? Thank you.

I am wondering if Apple allows us to get access to iCloud Mail inbox and read user's messages in iOS application?  I did a lot of research but couldn't find a concrete answer.  For example, on Google, this is possible by using OAuth.

Is CloudKit HIPPA Compliant?

Situation I'm working on an app in which the user can manually enter in data. That data gets locally stored in a CoreData database and from there automatically synced (via NSPersistentCloudKitContainer) to the user private CloudKit database and I selected CloudKit encryption for every attribute. So as the developer I definitely can't access it, but it's stored on some remote server. Ambiguous Documentation The privacy site at https://developer.apple.com/app-store/app-privacy-details/ says stuff like: “Collect” refers to transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time. If you collect data about your app from Apple frameworks or services [such as MapKit, CloudKit, or App Analytics] you should indicate what data you collect and how you use it. You are not responsible for disclosing data collected by Apple. It's a bit unclear if Apple a third-party in this case? It get's stored in CloudKit permanently, but I (or Apple probably) can't really access it - or does that count? Problem So now I'm not sure, if I need to declare anything on the privacy label. I would know what to declare on it, if I needed to, but I just don't know, if I need to. Question Does anybody know that data needs to declared in this case? If it's not clear, I will declare it to be on the safe side, but I really would like to actually know.

I'm trying to modify a CloudKit record type on my dev env but every time I add a field all my indexes get deleted leaving only the basic ones. I have tried resetting multiple times (losing all the test data along with it, very annoying) but it just keeps deleting indexes and sometimes record fields too. This is preventing me to test on the dev environment, and since all the indexes get deleted it also prevents me from pushing the changes to the production environment without readding all the indexes back manually again. Is this a bug on CloudKit dashboard? How can I fix this?

After using CloudKit enabled CoreData app for a while, I have the following observation. I have been actively use a CloudKit enabled CoreData app, for 2 weeks. Then, I get another fresh device. Once I hook up the fresh device to internet, based on the UI updating sequence, it seems like CoreData is replaying the entire transaction history, starting from 2 weeks ago till now. So, my questions is, if we are using the CloudKit enabled CoreData app for 5 years. Then, when I get a fresh new device, will the CoreData replaying the entire transaction history starting from 5 years ago? Isn't that is highly inefficient, and cause the new device sync extremely slow? Is that is so, how can we avoid such slowness, when user is using the app long time enough, and then decide to sync to a newly bought device? Thank you

I followed along apples Article for relevant store changes, mainly for data deduplication. https://developer.apple.com/documentation/coredata/consuming_relevant_store_changes I also downloaded the Core Data / CloudKit Demo App which already has a deduplication process. https://developer.apple.com/documentation/coredata/synchronizing_a_local_store_to_the_cloud In the Demo project I observed that more often than not, Posts loose their relationship to Tags. After some investigation I assume that this happens, when a Tag which has a relationship to a Post, gets deleted during the deduplication process, before the relevant Post was synced to the device. When the Post now arrives on the device, its related Tag Object does no longer exist. Therefore it's also not possible to find the retained, deduped Tag-Object which should be connected to the Post. I'm wondering why this was implemented that way in the Demo Project, as this really causes critical data loss. I have also no Idea how to avoid it. In the Article, Apple recommends to use Core Datas tombstone to preserve some values of deleted objects. However, there is no further explaination. It's also not implemented in the Demo project. How do I restore lost relationships and how does the tombstone help with it? Example: Before it synced: After it synced:

I'm restarting my app using CoreData and CloudKit and want to implement testing before I get too far and it becomes unmanageable. Is there a good tutorial anyone has found for testing when using SwiftUI (macOS and iOS but not storyboards). Thanks. It seems overwhelming right now and I don't know where to start. :)

Hi, I made a mistake as I was trying to manage the storage on my iPhone. In Settings / myName / manage storage / swiftUI, I selected “erase data…” I realized afterwards that this was linked to the CloudKit container from an app I had developed for myself. This app keeps records of my purchases and consumption of wine bottles. All the content of this app has therefore vanished. it contained several years of data. This app uses CoreData and CloudKit. Does anyone know if there is any chance to recover my data ? On iCloud.com, I see no way to do such a thing. On CloudKit console, I don’t see any possibility. I have a backup of my iPhone on my computer; I guess that if I restore the iPhone, it will have some “CoreData” data, but not everything (images for example). And in that case, how to transfer back the data to the CloudKit container ? Thanks for your help ! Best regards Nicolas

I am using CloudKit to sync my app across devices. At first everything seems to work as expected but after a while CloudKit seems to get caught in an endless loop and the debug console throws tons of these messages (several thousands in serial): CoreData: debug: CoreData+CloudKit: -[PFCloudKitSerializer applyUpdatedRecords:deletedRecordIDs:toStore:inManagedObjectContext:onlyUpdatingAttributes:andRelationships:madeChanges:error:]_block_invoke(1018): Failed to find matching objectIDs for <CKRecordID: 0x60000330c000; recordName=1E0972A7-D9DD-44A7-88F9-3AD13B32A330, zoneID=com.apple.coredata.cloudkit.zone:defaultOwner> / <CKRecordID: 0x60000330c020; recordName=EE02B981-E54D-486B-95A1-AC0839671C27, zoneID=com.apple.coredata.cloudkit.zone:defaultOwner> in pending relationship: 0xe92e2f9c5a6d27e2 x-coredata://75AFDFFD-8E35-4B9F-AA61-C477073B435B/NSCKImportPendingRelationship/p8626 I guess the most important part is: Failed to find matching objectIDs for <CKRecordID: 0x60000330c000; ... It's just a standard CloudKit implementation without any fancy custom code. I am not able to find anything about it in documentation. Therefore I have no idea where to start to investigate or if this is expected behaviour. I feel like this is slowing down my CloudKit sync quite a lot when I let the app run, the debug messages never end to appear. Usually I'm expecting No more requests to execute. to appear at some point but even after hours this is not the case. Does someone have similar issues or any idea about that?

Hey, there There's a crash on Apple's document example here https://developer.apple.com/documentation/cloudkit/ckoperation And if we replacing self.container.add (modifyOp) with self.database.add (modifyOp)  it seem will not sync data from iCloud any more. More info: https://developer.apple.com/forums/thread/685863

Hi, I recently had an issue with one of my production apps that use Core Data and CloudKit where data wasn't syncing between devices, after a little bit of research I found out that the schema in the private CloudKit container needed to be initialized; which I never did. The part I'm still not 100% sure is when to run the initializeCloudKitSchema method after the app has been released to the AppStore. I see that Apple recommends running it when testing by using #if DEBUG, but... do you really want to run it every time you compile in Xcode? Here is how I understand it at this point... App release, call initializeCloudKitSchema() to match schemas between Core Data and CloudKit. Added or deleted an attribute, call initializeCloudKitSchema() to update the CloudKit schema. Renamed an attribute, call initializeCloudKitSchema() to update the CloudKit schema. Etc. If my assumption above is correct, calling the initializeCloudKitSchema() method during development would update the schema in CloudKit before the new app version is released in the AppStore, therefore creating an issue for existing users with previous versions of the app since they will not have the latest code but will be using the latest schema which contains the new attributes. Can someone please share their method of handling schema updates in CloudKit after the app has been released to the AppStore? Code: do { try container.initializeCloudKitSchema() } catch { print(error) }

I have a SwiftUI app that uses CloudKit and Core data to sync data between devices. Everything works fine when testing on devices in Xcode but not in production in the App Store. Can someone explain the typical process when deploying an app that uses CoreData + CloudKit? Is there anything that needs to be done in code or in the CloudKit Console before the app is uploaded to the App Store? Again, my issue is that data doesn't sync when trying to sync data between multiple devices in production but works fine when testing in Xcode. Thanks

Suppose I start a request using the new async await with isLongLived set true: let config = CKOperation.Configuration() config.isLongLived = true let results = try await database.configuredWith(configuration: config) { db in try await db.modifyRecordZones(saving: [...], deleting: [...]) } try await processResults(results) — then assuming my application exits and the requests is continued through by the system: would these operations eventually end up in the container's allLongLivedOperationIDs() like a classic CKOperation? And a follow up question, assuming that the answer above is true: to "finish" these operations, we should we take the fetched long-lived operations, essentially insert our post-async await code into that completion block, and then add it to the database? I think that all makes sense, and I am going to test it out, but figured it'd be worth asking

Due to privacy concern, we wish to provide a toggle switch, so that user has the freedom, to choose whether to sync CoreData with iCloud. We can implement such a feature by following suggestion from https://developer.apple.com/forums/thread/118924?login=true However, we should not perform history tracking transactions purging, once user disables CloudKit sync Reason is that, if few months later/ few years later, user decides to turn on CloudKit sync again, lack of sufficient history tracking transactions, will cause CloudKit sync fail. This is causing a dilemma. If we never clean the history tracking transactions, will it cause disk full issue? If that is so, may I know, what is the correct way to handle history tracking transactions purging, if we allow users to enable/ disable CloudKit sync? Thank you.

Due to privacy concern, I believe some users prefer their data not to sync with iCloud. Hence, we plan to provide a switch option within the app, so that user can choose, whether to sync their data with iCloud. Such feature can be achieved via the implementation suggested at https://developer.apple.com/forums/thread/118924?login=true However, once user chooses to disable sync with iCloud, we should not perform purging on history tracking transactions. Reason is that, if few months later/ few years later, user decides to turn on sync with iCloud again, lack of sufficient history tracking transactions, will cause sync with iCloud operation fail. This is causing a dilemma. If we never clean the history tracking transactions, will it cause disk full issue? If that is so, may I know, what is the correct way, to handle history tracking transactions purging, if we intent to provide CloutKit sync enable/ disable feature? Thank you.

Some of my users are experiencing synchronization issues when using the NSPersistentCloudKitContainer in CoreData. This error only occurs in Apple Watch so far. I can not find any documents about this error. Does anyone know what this error code means?

Hi I noticed with CKModifyRecordsOperation, modifyRecordsResultBlock works differently from the now deprecated modifyRecordsCompletionBlock. When using a savePolicy of ifServerRecordUnchanged (which is the default), if the record on the server has been changed since it was downloaded, edited and saved again then modifyRecordsResultBlock unexpectedly does not error. But modifyRecordsCompletionBlock does error which is what I would expect. The kind of error in this case looks like this: "Server Record Changed" (14/2004); server message = "client oplock error updating record"; My question is, is this new behavior by design? By the way, I'm having to write my own async/await version of save records using withTaskCancellationHandler and withCheckedThrowingContinuation because the built-in one does not support task cancellation which I require to use with SwiftUI's .task modifier. Finally, modifyRecordsResultBlock and the other 2 new ones are missing its documentation because it hasn't used the correct DocC format, it's using old style comments which are not being picked up. FB10400023

I'd like to test how my app behaves when the user signs out of iCloud and my app is in memory. In the iOS Simulator, the "Sign Out" button for iCloud is grayed out so I can't use the simulator to test. I'm hesitant to use a real device tied to my Apple ID because signing out of iCloud System wide has side effects with many apps and I don't want to potentially lose any data. However, I did test on a real device by going the Settings app -> iCloud and disabled iCloud only for my app. When I do this, the system terminates my app and does not post a CKAccountChangedNotification. I only tested turning off the iCloud switch for my app. Does the system simply terminate apps when the user logs out of iCloud system wide too? In what cases is the CKAccountChangedNotification posted? Detecting sign out by listening for CKAccountChangedNotification would seem to be pointless if apps are terminated when the user signs out of iCloud.