I've made a mistake while writing here and replaced my function that returns the NSStagedMigrationManager with only [stages]. It should have been NSStagedMigrationManager(stages). This is only an issue in the post and not in my code.

@DTS Engineer I've filed feedback detailing this issue, including links to both this thr ead and the sample project. FB18334791

@DTS Engineer Hi, Getting deleted records on the device that made the edits makes sense. It makes less sense to get them even after I fully deleted the app, but this would not be a problem if receiving the delete events and any other events were reasonably fast. As I mentioned in the post, I have removed all of the processing logic from my app and only logged the number of items per batch using Logger. I found that on average a batch contains about 200 items. In very few batches, it can reach 600 items, but then it stabilizes at around 200 per batch, with roughly one second between batches. This is true for batches containing modifications or deletions. With that, simple math matches my observations in the post: 62,000 items need to be synced, which is about 310 batches of 200 items each. 310 divided by 60 is approximately 5.17 minutes. If there is no way to increase the batch size or reduce the time between events, I believe there is nothing I can do to reduce the time it takes to sync everything on the device. Please do not think only in terms of deletions, as this is also true for modified items. Even with 62,000 items in CloudKit and zero deleted records, it would take roughly the same time to fetch all changes.

@DTS Engineer Thanks for the response. I have filed a feedback report with the details discussed in this thread. Feedback ID: FB21848143 I really hope there is some initiative inside Apple to improve this area. Apart from the initial sync performance issues with large datasets, CKSyncEngine is an amazing API and makes ongoing synchronization much simpler and cleaner than rolling custom CloudKit logic. It would be great to see it scale better for first launch scenarios as well. Thanks again for taking the time to reply. I am not really sure whether marking "file a feedback" as the accepted answer makes sense here, since it does not actually help with the problem or provide any workaround. Over the years I have filed quite a few feedback reports and only one was ever addressed, and that was a UI bug. Because of that, I am honestly not very optimistic about this changing, especially since this is not something that directly shows up as a user-facing bug.