Search results for

“NSPersistentCloudKitContainer”

601 results found

Post

Replies

Boosts

Views

Activity

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
383
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
1.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
1.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.3k
Sep ’24
Reply to Help with 2 way relationships with classes (SwiftData / cloudkit)
The error message you provided, “container not found errors“, doesn't seem to indicate anything related to your data model. If you can provide full description of the error, and also how you trigger the error, I may be able to comment. SwiftData's CloudKit integration is based on NSPersistentCloudKitContainer. You can also follow the following technotes to understand and debug any synchronization issue: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer. TN3164: Debugging the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Sep ’24
Reply to SwiftData & CloudKit: getting info about current updates
SwiftData + CloudKit integration is based NSPersistentCloudKitContainer as of today, and so you can observe the synchronization events using eventChangedNotification with the following steps: Observe the eventChangedNotification notification. In your notification handler, use eventNotificationUserInfoKeyto retrieve the the event from notification.userInfo. Look into the event type, startDate, and endDate to understand the state of the event. For a runnable sample, please see Sharing Core Data objects between iCloud users. It is a Core Data sample, but the way to observe eventChangedNotification can be applied to SwiftData. Note that eventChangedNotification tells you the state of an individual export or import event, and not that the whole Core Data store is synchronized with the CloudKit server (or not), because there may have new changes happening on the CloudKit server while the event is being handled. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Sep ’24
Strange behavior with 100k+ records in NSPersistentCloudKitContainer
I have been using the basic NSPersistentContainer with 100k+ records for a while now with no issues. The database size can fluctuate a bit but on average it takes up about 22mb on device. When I switch the container to NSPersistentCloudKitContainer, I see a massive increase in size to ~150mb initially. As the sync engine uploads records to iCloud it has ballooned to over 600mb on device. On top of that, the user's iCloud usage in settings reports that it takes up 1.7gb in the cloud. I understand new tables are added and history tracking is enabled but the size increase seems a bit drastic. I'm not sure how we got from 22mb to 1.7gb with the exact same data. A few other things that are important to note: I import all the 100k+ records at once when testing the different containers. At the time of the initial import there is only 1 relation (an import group record) that all the records are attached to. I save the background context only once after all the records and the import group have been made and
3
0
849
Sep ’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
Replies
Boosts
Views
Activity
Oct ’24
NSPersistentCloudKitContainer's canUpdateRecord always returns true.
I'm using NSPersistentCloudKitContainer to sync CoreData to CloudKit public database but I have the problem that canUpdateRecord always returns true even for objects created by another iCloud user with _icloud role permission set to Read only. Am I missing something?
Replies
2
Boosts
0
Views
846
Activity
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
Replies
1
Boosts
0
Views
383
Activity
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.
Replies
Boosts
Views
Activity
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
Replies
2
Boosts
0
Views
1.1k
Activity
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.
Replies
Boosts
Views
Activity
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.
Replies
Boosts
Views
Activity
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
Replies
Boosts
Views
Activity
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
Replies
2
Boosts
0
Views
1.1k
Activity
Sep ’24
Reply to CloudKit is not accessible from iOS extension targets
I saw that you were trying to use NSPersistentCloudKitContainer in an extension, and would like to give you a warning that it may not work that well. This topic is discussed a bit in the following technote: Avoid synchronizing a store with multiple persistent containers. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Replies
Boosts
Views
Activity
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
Replies
Boosts
Views
Activity
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
Replies
4
Boosts
0
Views
1.3k
Activity
Sep ’24
Reply to Help with 2 way relationships with classes (SwiftData / cloudkit)
The error message you provided, “container not found errors“, doesn't seem to indicate anything related to your data model. If you can provide full description of the error, and also how you trigger the error, I may be able to comment. SwiftData's CloudKit integration is based on NSPersistentCloudKitContainer. You can also follow the following technotes to understand and debug any synchronization issue: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer. TN3164: Debugging the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Replies
Boosts
Views
Activity
Sep ’24
Reply to SwiftData & CloudKit: getting info about current updates
SwiftData + CloudKit integration is based NSPersistentCloudKitContainer as of today, and so you can observe the synchronization events using eventChangedNotification with the following steps: Observe the eventChangedNotification notification. In your notification handler, use eventNotificationUserInfoKeyto retrieve the the event from notification.userInfo. Look into the event type, startDate, and endDate to understand the state of the event. For a runnable sample, please see Sharing Core Data objects between iCloud users. It is a Core Data sample, but the way to observe eventChangedNotification can be applied to SwiftData. Note that eventChangedNotification tells you the state of an individual export or import event, and not that the whole Core Data store is synchronized with the CloudKit server (or not), because there may have new changes happening on the CloudKit server while the event is being handled. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Replies
Boosts
Views
Activity
Sep ’24
Strange behavior with 100k+ records in NSPersistentCloudKitContainer
I have been using the basic NSPersistentContainer with 100k+ records for a while now with no issues. The database size can fluctuate a bit but on average it takes up about 22mb on device. When I switch the container to NSPersistentCloudKitContainer, I see a massive increase in size to ~150mb initially. As the sync engine uploads records to iCloud it has ballooned to over 600mb on device. On top of that, the user's iCloud usage in settings reports that it takes up 1.7gb in the cloud. I understand new tables are added and history tracking is enabled but the size increase seems a bit drastic. I'm not sure how we got from 22mb to 1.7gb with the exact same data. A few other things that are important to note: I import all the 100k+ records at once when testing the different containers. At the time of the initial import there is only 1 relation (an import group record) that all the records are attached to. I save the background context only once after all the records and the import group have been made and
Replies
3
Boosts
0
Views
849
Activity
Sep ’24