Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

Reply to Async Data with iCloud
Given that you are already using Core Data, you can consider using NSPersistentCloudKitContainer. If the data you would synchronize is as simple as several values, you can consider using the CloudKit framework as well, which gives you more flexibility. You might want to start with looking into the above APIs, and follow up with your further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Feb ’25
Reply to NSMigrationManager.migrateStore with NSPersistentHistoryTrackingKey
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?
Feb ’25
Reply to NSMigrationManager.migrateStore with NSPersistentHistoryTrackingKey
The code path of lightweight migration, which does migration in place, is different from the one of running NSMigrationManager, and so I am not too surprised that the logs are different. If you can provide the logs generated by running NSMigrationManager for me to compare, I will be able to confirm. I'll be very surprised if NSMigrationManager doesn't checkpoint the data though. I don't see any way that can force Core Data to write to the -wal file. I think if you set up a Core Data stack with multiple persistent store coordinators and write a bigger data set simultaneously, you will more likely see data being witten to the -wal file. I don't expect the behavior being different for NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Feb ’25
Reply to WidgetKit and CoreData/CloudKit
@Engineer Thanks for sharing the sample project. It shows several examples how to use CloudKit, however, it doesn't include a Widget Extension or any references to WidgetKit. Is there another project that showcases this concrete use case, updating the same Core Data objects from both a Widget and an app? @Jordan wrote in 2022: Do note they also said NSPersistentCloudKitContainer does not support multi-process sync so only your app should be attempting to sync. And even if a widget were to attempt sync, it’ll never really be able to because iOS doesn’t give it enough time to execute, and widgets don’t run in the background they’re only running when they need to get more timeline entries for example, and widgets don’t get the app’s push notifications which is what enables background syncs to be scheduled. Your app will need to try to keep the widget up to date as opposed to the widget attempting to sync and keep itself up to date. Is this (still) correct (in 2025)? If so, then any attempt to update Cor
Mar ’25
Crash during batch deletion merge when positive fractional decimals are stored and used in a derived attribute
I am experiencing a crash when performing a batch delete and merging changes on a Core Data store that uses NSPersistentCloudKitContainer. The crash appears to be triggered when positive fractional Decimal values are stored in a TransactionSplit entity (those values are aggregated via a derived attribute in the AccountTransaction entity). If I store whole numbers or negative fractional decimals, deletion seems to work correctly. I suspect that the issue is related to the internal representation of positive fractional decimals in conjunction with a derived attribute. Data Model Setup: Account (1:N relationship → AccountTransaction) AccountTransaction (1:N relationship → TransactionSplit), which contains a derived attribute (e.g., “splits.amount.@sum”) that computes the sum over the “amount” attribute on its related TransactionSplit objects. TransactionSplit, which contains a stored Decimal attribute named “amount” (of type Decimal/NSDecimalNumber). Steps to Reproduce: Insert sample data where each Tra
4
0
610
Mar ’25
Reply to Crash during batch deletion merge when positive fractional decimals are stored and used in a derived attribute
This is pretty similar to an existing issue we know. Would you mind to try the following? Replace NSPersistentCloudKitContainer with NSPersistentContainer and verify that the issue is still there. This is to simplify the issue by ruling out CloudKit. Reproduce the issue, gather a crash report, and share here. I'd be able to confirm by reading the crash report. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Mar ’25
How to Delete Tips from CloudKit?
Hi! I use Tips with CloudKit and it works very well, however when a user want to remove their data from CloudKit, how to do that? In CoreData with CloudKit area, NSPersistentCloudKitContainer have purgeObjectsAndRecordsInZone to delete both local managed objects and CloudKit records, however there is no information about the TipKit deletion. Does anyone know ideas?
2
0
436
Mar ’25
Reply to How to force / wait for SwiftData sync on first app launch?
As of today, SwiftData + CloudKit is based on NSPersistentCloudKitContainer, and there is no API for apps to configure the timing for the synchronization. To observe the synchronization activities, you can use NSPersistentCloudKitContainer.Event. The following technotes provides the whole picture of how NSPersistentCloudKitContainer works: TN3164: Debugging the synchronization of NSPersistentCloudKitContainer. TN3163: Understanding the synchronization of NSPersistentCloudKitContainer. TN3162: Understanding CloudKit throttles. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Mar ’25
Sync an interactive widget's Core Data store with the main app (and iCloud)
Hi everyone! I have an app on the App Store that uses Core Data as its data store. (It's called Count on Me: Tally Counter. Feel free to check it out.) One of the app's core feature is an interactive widget with a simple button. When the button is tapped, it's supposed to update the entity in the store. My requirement is that the changes are then reflected with minimal latency in the main app and – ideally – also on other devices of the same iCloud user. And vice-versa: When an entity is updated in the app (or on another device where the same iCloud user is logged in), the widget that shows this entity should also refresh to reflect the changes. I have read multiple articles, downloaded sample projects, searched Stackoverflow and the Apple developer forums, and tried to squeeze a solution out of AI, but couldn't figure out how to make this work reliably. So I tried to reduce the core problem to a minimal example project. It has two issues that I cannot resolve: When I update an entity in the app, the widget i
4
0
370
Mar ’25
Reply to "BAD_REQUEST" in iCloudKit Telemetry
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
Mar ’25
Reply to How to provide visual feedback about iCloud sync status when the user reinstalls an app?
Yeah, if you are using NSPersistentCloudKitContainer, NSPersistentCloudKitContainer.Event is the API that provides you the activity status. If you are using the CloudKit framework, a CloudKit operation triggers its completion handler, and so you can get the status from there. Note that the status you get from the mentioned APIs doesn't tell whether your local cache is synchronized with the server or not, because it is perfectly possible that a new change has been made on the server version immediately before you get notified that an activity / operation is completed. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Mar ’25
Reply to Sync an interactive widget's Core Data store with the main app (and iCloud)
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
Mar ’25
Reply to Sync an interactive widget's Core Data store with the main app (and iCloud)
Dear Ziqiao Chen, thank you for your reply and the hints pointing me in the right direction. I managed to solve my problem no. 1 and now the sync works both between the app and the widget, but also between different devices. I had already observed the .NSPersistentStoreRemoteChange notification in my sample project, but it turns out that wasn't even necessary when automaticallyMergesChangesFromParent is set to true on the viewContext. The Problem with Syncing from a Widget Now the problem is the following: Regarding using Core Data + CloudKit (NSPersistentCloudKitContainer) in an extension, I'd like to suggest against doing that ⬆️ Your reply and the linked Technical Note both imply that syncing data with iCloud this way from both the app and its widget is not reliable as two NSPersistentCloudKitContainers pointing to the same persistent store can get in conflict (running on different threads) and throw the following error: CloudKit setup failed because there is another instance of this pers
Mar ’25