Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

Reply to How to "Keep on My iPhone" after disabling iCloud for my app using Core Data
However, on my device when I go to Settings > Apple Account > iCloud > Saved to iCloud and switch off my app, all the data saved to Core Data is removed. I suspected this working as intended. Yeah, this is an as-designed behavior. Basically, NSPersistentCloudKitContainer removes the local data from the device in that case for privacy reason, and it doesn't expose any API for developers to configure the behavior. I discussed the behavior NSPersistentCloudKitContainer responds to user switching in the following post: NSPersistentCloudKitContainer losing data From user's perspective, switching to a new user may be different from disabling the Saved to iCloud setting, but CloudKit doesn't handle the two cases in a different way, as far as I know. Having said that, if you believe that NSPersistentCloudKitContainer shouldn't behave that way, please file a feedback report with your concrete use case – If you do so, please share your report ID here. Best, —— Ziqiao Chen 
Nov ’24
How to "Keep on My iPhone" after disabling iCloud for my app using Core Data
I have Core Data setup with a NSPersistentCloudKitContainer as my container, I've added a container identifier and I see my data on CloudKit's database here when I use Act As iCloud Account. Here's what I have under capabilities in Xcode However, on my device when I go to Settings > Apple Account > iCloud > Saved to iCloud and switch off my app, all the data saved to Core Data is removed. I suspected this working as intended. When I switch it back on, all the data comes back. However (x2), the support page here says it should remain on the device: When you turn it off, the app no longer connects with iCloud, so your data exists only on your device Am I missing something in how I integrated Core Data in Xcode? Do I need to explicitly configure something with Apple's SDK to get the behavior described in the support page? I've noticed for some of Apple's apps, when you switch off iCloud there's an action sheet asking what you'd like to do with the local data. I figured this was Apple's magic wi
1
0
1k
Nov ’24
Reply to Core Data CloudKit stops syncing after incomprehensible archive error
This error message your post provided indicates that Core Data failed to unarchive the import request (NSCloudKitMirroringImportRequest). Archiving / unarchiving an import / export request is a Core Data internal logic, and so I agree your assessment that it is not about your code. The feedback report you filed (FB10392936) doesn't mention the error message, and so I'd suggest that you file a new one to specifically report the error – If you do so, please share your report ID here for folks to track. Regarding FB10392936, you most likely hit CloudKit throttles. For more information of this topic, see the following documentations: TN3162: Understanding CloudKit throttles Understand system throttles. When uploading a big data set and hitting CloudKit throttles, the only thing you can do is to lower the CloudKit operation rate. When using Core Data + CloudKit, however, you don't control how NSPersistentCloudKitContainer synchronizes data. Based on today's API, the only thing you can do is to somehow con
Oct ’24
SwiftData ModelConfigurations always sync to iCloud if one of them has iCloud enabled
I'm facing a weird issue with SwiftData. I want to have one database that's local to the device and one that syncs to iCloud. In this example, LTRLink should be synced via iCloud while LTRMetadata should stay on-device only. I've it configured like the following: let schema = Schema([LTRLink.self, LTRMetadata.self]) let cloudkitConfiguration = ModelConfiguration(Remote, schema: schema, url: FileManager.remoteDatabaseFolderURL.appending(path: Remote.sqlite), cloudKitDatabase: .private(iCloud.com.xavimoll.abyss3)) let localConfiguration = ModelConfiguration(Local, schema: schema, url: FileManager.localDatabaseFolderURL.appending(path: Local.sqlite), cloudKitDatabase: .none) return try ModelContainer(for: schema, configurations: [cloudkitConfiguration, localConfiguration]) For some reason, when I create the iCloud schema, both models end up appearing as records on iCloud. I create the schema like this: let schema = Schema([LTRLink.self, LTRMetadata.self]) let cloudkitConfiguration = ModelConfiguration(Remote, sc
1
0
652
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
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
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
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
Nov ’25
CloudKit is not accessible from iOS extension targets
Hi! I'm using CoreData + CloudKit. It works well both on macOS and iOS, however, I can't make it work with extensions (share, action, keyboard). I get Invalid bundle ID for container error: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _recoverFromPartialError:forStore:inMonitor:](2812): : Error recovery failed because the following fatal errors were found: { = ; } I checked everything 10x: profiles, bundle ids, entitlements, etc. I even removed all local provisioning profiles and recreated them, I also tried setting different CloudKit container, but nothing helps. I tested it on a real device. My setup: main app bundle id: com.org.App.dev keyboard bundle id: com.org.App.dev.App-Keyboard action extension bundle id: com.org.App.dev.Action-Extension CloudKit container id: iCloud.com.org.app.dev I keep the CoreData database in the app group container, but I also tried locally and it doesn't really matter. This is how I setup my CoreData: self.persistentContainer = NSPersistentCloudKitContainer
3
0
787
Sep ’24