Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

NSPersistentCloudkitContainer setup - merge behavior - contexts
Is it ok to use automaticallyMergesChangesFromParent to true for a managed object context that pins its query generation to current? I have heard from a few sources that in most cases, it’s not recommended to set automaticallyMergesChangesFromParent to true for a managed object context that pins its query generation to current. A source I have seen says: When you pin a managed object context to a specific query generation, you’re explicitly telling the context to view the data as it existed at the time of that generation token (often referred to as a snapshot). This ensures that the context is isolated from any subsequent changes made by other contexts or background tasks. But this may Conflict with Automatic Merging because: The purpose of setting automaticallyMergesChangesFromParent to true is to have the context automatically merge changes from the parent (e.g., background or main context) into itself whenever the parent context saves changes. This behavior conflicts with the concept of a pinned query gene
Topic: UI Frameworks SubTopic: General
0
0
289
Oct ’24
Reply to SwiftData iCloud sync breaks after disabling and re-enabling iCloud
... was cancelled because there is already a pending request of type 'NSCloudKitMirroringExportRequest... This message doesn't quite matter, as discussed in Execute the export. After some time the sync fails again for no obvious reason and here is the error that appears in the console for a Mac app To get to the bottom in this situation, you might still want to look into a sysdiagnose. The whole analysis process is discussed in TN3163: Understanding the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Oct ’24
Reply to SwiftData iCloud sync breaks after disabling and re-enabling iCloud
Thanks for filing the feedback report. Other than that, if you would like to figure out what really happens when synchronization fails, please follow this technote to capture and analyze a sysdiagnose: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer I am guessing that it is the system delaying or throttling the synchronization for some reason (reasonable or not), and am curious to see your findings. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Oct ’24
Reply to Does SwiftData currently supports data sharing among multiple users through iCloud?
SwiftData + CloudKit integration doesn’t support CloudKit sharing as of today. I haven’t tried to implement SwiftData + CloudKit sharing with my own effort, but based on my understanding on the technologies, if the object graph to be shared is relatively complicated, I'd consider sticking with NSPersistentCloudKitContainer (Core Data), because NSPersistentCloudKitContainer interacts with Core Data, and using SwiftData adds another layer of complexity. If the data to be shared is quite simple, such as a small set of values without relationships, and I have built my app with SwiftData, I might consider using CloudKit API directly to implement the sharing flow. That way, I completely control the synchronization and sharing process, and can share any data type, including SwiftData. For the first option, you can start with the following sample: Sharing Core Data objects between iCloud users The second option may turn out a bit involved. You can start with the technical resources mentioned in the
Oct ’24
Core Data modifications not saved in two of three tables
I'm a bit lost because of a problem I never experienced before: I create entries in 3 Core Data tables and link them. As long as the app is open, everything is fine, I can see the database entries in the three tables. Once the App is closed and restarted, however, the new entries in two of the three tables are gone. I use Core Data for data storage and DB Browser for SQLite for inspecting the database running in the Simulator. Here's the relevant function where all Core Data handling happens: /** Creates a new ComposedFoodItem from the ComposedFoodItemViewModel. Creates the related FoodItem and the Ingredients. Creates all relationships. - Parameter composedFoodItemVM: The source view model. - Returns: A Core Data ComposedFoodItem; nil if there are no Ingredients. */ static func create(from composedFoodItemVM: ComposedFoodItemViewModel, generateTypicalAmounts: Bool) -> ComposedFoodItem? { debugPrint(AppDelegate.persistentContainer.persistentStoreDescriptions) // The location of the .sqlite file let moc = A
1
0
376
Sep ’24
Reply to SwiftData ignore changes on App Intents
I open the app. Few seconds later I receive two new tokens (183 and 184) which are the mirroring of 180 & 181. They override 182. New state = 181 instead of 182. This is the bug. This does sound like a bug to me. I unfortunately don't see any workaround because the synchronization logic is all encapsulated in NSPersistentCloudKitContainer. I’d suggest that you file a feedback report for the Core Data + CloudKit folks to take a look – If you do so, please share your report ID here for folks to track. As discussed in Avoid synchronizing a store with multiple persistent containers though, I'd probably have the main app, and not its extension, do the CloudKit synchronization. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Sep ’24
Swift 6 and NSPersistentCloudKitContainer
Hello all! I'm porting a ios15+ swiftui app to be compatible with Swift 6 and enabling strict concurrency checking gave me a warning that will be an error when switching to swift 6. I'm initializing a persistence controller for my cloud kit container: import CoreData struct PersistenceController { static let shared = PersistenceController() let container: NSPersistentCloudKitContainer init() { container = NSPersistentCloudKitContainer(name: IBreviary) container.loadPersistentStores(completionHandler: { _, error in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } }) container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy container.viewContext.automaticallyMergesChangesFromParent = true } } The warning is on the merge policy: Reference to var 'NSMergeByPropertyObjectTrumpMergePolicy' is not concurrency-safe because it involves shared mutable state; this is an error in the Swift 6 language mode I have no idea how to make this concur
2
0
1k
Sep ’24
Reply to SwiftData ignore changes on App Intents
The SwiftData version of the Adopting SwiftData for a Core Data app does pretty much the same thing as what you described, except that it doesn't use CloudKit, and so you can probably start with checking if the sample demonstrates the same issue on your side. To figure out what really happens when the value changes, you can use the SwiftData history API to dump the history and analyze the update transaction (HistoryUpdate). The sample mentioned above demonstrates how to use the history API as well. If you are using SwiftData + CloudKit, which is based on NSPersistentCloudKitContainer today, in an extension, you might want to look at the following technote section: Avoid synchronizing a store with multiple persistent containers. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Sep ’24
Reply to Field recordName is not marked queryable
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.
Sep ’24
Reply to NSPersistentCloudKitContainer losing data
1. Are you suggesting that iCloud-sync should be enabled by default and if the users want to turn it off then they can do that from System Settings app? Yeah, that will be my choice. 2. Based on your answer, I think I agree that having toggle to enable/disable iCloud will not provide consistent experience. But then I don't understand how that can be fixed since iCloud is available only to the premium users in the app. The toggle is off and disabled for the free users of the app. I didn't think that you'd build your business model based on that. Thanks for bringing this up. I haven't thought from the business model perspective, but one idea is to consider creating a local store and a CloudKit store to manage the data separately. When users choose to opt in, you move the data from local store to the CloudKit one, and let NSPersistentCloudKitContainer take care the rest. By using a local store, you control when to move what data to the CloudKit store. For details about managing multiple stores with one
Sep ’24
Field recordName is not marked queryable
I'm using NSPersistentCloudKitContainer and in the CloudKit dashboards I have added indexes for all my records modifiedTimestamp queryable, modifiedTimestamp sortable and recordName queryable. But I'm still getting this warning message in the console. error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _importFinishedWithResult:importer:](1400): : Import failed with error: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate recoverFromError:](2312): - Attempting recovery from error: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _recoverFromError:withZoneIDs:forStore:inMonitor:](2622): - Failed to recover from error: CKErrorDomain:12 Recovery encountered the following error: (null):0 error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate resetAfterError:andKeepContainer:](612): - resetting internal state after error: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _requestAbortedNotInitialized:](2200): - Never successfully initialized and cannot execute request ' A3F
2
0
1k
Sep ’24
Reply to NSPersistentCloudKitContainer losing data
I see folks implement an in-app toggle to enable / disable CloudKit synchronization when using NSPersistentCloudKitContainer. I honestly don't see that a great idea. I know this is controversial, and so would layout my reasoning here: First, the system already provides a setting (Settings > Apple ID > iCloud) that allows users to turn on / off iCloud for an app. If a user turns off iCloud for an app with the setting, the app won’t be able to synchronize with CloudKit, even the in-app toggle is on. Secondly, for the toggle to work, the app needs to release the Core Data objects currently in use, and reload the Core Data stack. In your case, you achieve that by asking the user to restart the app, which is probably not a great experience. Last but probably more importantly, CloudKit implements access control on its data: only the store owner (the user who owns the login iCloud account when the store is created) can access a store associated with a CloudKit private or shared database, and only the
Sep ’24
NSPersistentCloudKitContainer losing data
Some users of my app are reporting total loss of data while using the app. This is happening specifically when they enable iCloud sync. I am doing following private func setupContainer(enableICloud: Bool) { container = NSPersistentCloudKitContainer(name: ) container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy guard let description: NSPersistentStoreDescription = container.persistentStoreDescriptions.first else { fatalError() } description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) if enableICloud == false { description.cloudKitContainerOptions = nil } container.loadPersistentStores { description, error in if let error { // Handle error } } } When user clicks on Toggle to enable/disable iCloud sync I just set the description.cloudKitContainerOptions to nil and then user is asked to restar
4
0
1.1k
Sep ’24