Hello everyone, I'm trying to adopt the new Staged Migrations for Core Data and I keep running into an error that I haven't been able to resolve. The error messages are as follows: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'Movie' so +entity is unable to disambiguate. warning: 'Movie' (0x60000350d6b0) from NSManagedObjectModel (0x60000213a8a0) claims 'Movie'. error: +[Movie entity] Failed to find a unique match for an NSEntityDescription to a managed object subclass This happens for all of my entities when they are added/fetched. Movie is an abstract entity subclass, and it has the error error: +[Movie entity] Failed to find which is unique to the subclass entities, but this occurs for all entities. The NSPersistentContainer is loaded only once, and I set the following option after it's loaded: storeDescription.setOption( [stages], forKey: NSPersistentStoreStagedMigrationManagerOptionKey ) The warnings and errors only appear after I fetch or save to context. It happens regardless of whether the database was migrated or not. In my test project, using the generic NSManagedObject with NSEntityDescription.insertNewObject(forEntityName: "MyEntity", into: context) does not cause the issue. However, using the generic NSManagedObject is not a viable option for my app. Setting the module to "Current Project Module" doesn't change anything, except that it now prints "claims 'MyModule.Show'" in the warnings. I have verified that there are no other entities with the same name or renameIdentifier. Has anyone else encountered this issue, or can offer any suggestions on how to resolve it? Thanks in advance for any help!

Our app saves its data to iCloud by default. In most cases, this is working as intended & the data can be synced across devices with no problems. But recently, in testing, we discovered a situation where it's possible to save data before the NSMetadataQuery finishes & starts downloading the cloud files. When this happens, the query will then finish, and return the NEW file (with no other versions or conflicts). Is there a way to ensure that writing a file (version A) to ubiquitous storage when another version (version B) exists in the cloud is treated as a conflict, rather than just stomping all over the other version? I've tried querying the file metadata for the file URL (NSURLIsUbiquitousItemKey, NSMetadataUbiquitousItemDownloadingStatusKey, NSURLUbiquitousItemDownloadRequestedKey, NSURLUbiquitousItemHasUnresolvedConflictsKey) before saving, but it just returns nil.

Hi all, I recently discovered that I forgot to deploy my CloudKit schema changes from development to production - an oversight that unfortunately went unnoticed for 2.5 months. As a result, any data created during that time was never synced to iCloud and remains only in the local CoreData store. Once I pushed the schema to production, CloudKit resumed syncing new changes as expected. However, this leaves me with a gap: there's now a significant amount of data that would be lost if users delete or reinstall the app. Before I attempt to implement a manual backup or migration strategy, I was wondering: Does NSPersistentCloudKitContainer keep track of local changes that couldn't be synced doe to the missing schema and automatically reattempt syncing them now that the schema is live? If not, what would be the best approach to ensure this "orphaned" data gets saved to CloudKit retroactively. Thanks in advance for any guidance or suggestions.

Overview I'm developing a document-based app for macOS using SwiftData. When I undo/redo changes using Command-Z/ Command-Shift-Z, the app randomly crashes with the following error: SwiftData/BackingData.swift:425: Fatal error: Failed to retrieve the identifier for \ChildItem.parentItem from KnownKeysDictionary:KnownKeysMap: ["parentItem": 2, "isModified": 1, "index": 0] values: [Optional(0), Optional(false), Optional(DocumentTest.ParentItem)] SwiftData._KKMDBackingData<DocumentTest.ChildItem> And sometimes, instead of the app crashing, my created @Model objects simply disappear. They do not reappear in the @Query on undo/redo. Both of these issues go away when I set modelContext.autosaveEnabled = false The issues are occurring with Xcode 26.4 (17E192) and macOS Tahoe 26.4 (25E246). I have modified the macOS Document App project template to showcase the issue. The project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/1aDO34QleTm_rB9BuvVGjzzAP6jDXOc-o?usp=share_link Has anyone else experienced this? I'd like to know if this is a bug in the autosave feature of SwiftData and if I should file a bug report via Feedback Assistant. Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file linked above. Open the extracted "DocumentTest" project in Xcode. Build and run the "DocumentTest" app. In the document selection window, click "New Document" at the bottom-left. In the app, click the "+" button at the top-right to add a ParentItem with ChildItems. Click on the added ParentItem's button to modify one of its ChildItems. Repeat steps 5–6 until you have 5 ParentItems with a modified ChildItem. Press Command-Z 10 times to undo all the changes. Press Command-Shift-Z 10 times to redo all the changes. Repeat steps 8–9 until either the app crashes or some of the 5 ParentItems go missing in the list (you may have to repeat them 10–20 times before the issue occurs). If you change line 43 of ContentView.swift to modelContext.autosaveEnabled = false and repeat the same steps above, the app will not crash and no ParentItems will go missing. Code ParentItem Model @Model final class ParentItem { var timestamp: Date @Relationship( deleteRule: .cascade, inverse: \ChildItem.parentItem ) var childItems: [ChildItem] = [] init(timestamp: Date) { self.timestamp = timestamp } } ChildItem Model @Model final class ChildItem { var index: Int var isModified = false var parentItem: ParentItem? init(index: Int) { self.index = index } } Creating, Inserting, and Linking ParentItem and ChildItem // Create and insert ParentItem let newParentItem = ParentItem( timestamp: Date() ) modelContext.insert(newParentItem) // Create and insert ChildItems var newChildItems: [ChildItem] = [] for index in 0..<Int.random(in: 2...8) { let newChildItem = ChildItem(index: index) newChildItems.append(newChildItem) modelContext.insert(newChildItem) } /* Establish relationship between ParentItem and ChildItems */ newParentItem.childItems = newChildItems Modifying ChildItem let firstChildItem = parentItem.childItems .sorted(by: { $0.index < $1.index }).first if let firstChildItem, !firstChildItem.isModified { firstChildItem.isModified = true }

I have developed an podcast app, where subscriped podcast & episodes synched with iCloud. So its working fine with iOS & iPad with latest os version, but iCloud not synching in iPod with version 15. Please help me to fix this. Thanks Devendra K.

After Xcode 26.1 was updated and installing the OS 26.1 simulators, my app started crashing related to transformable properties. When I checked my schema, I noticed that properties with array collection types are suddenly set with an option transformable with Optional("NSSecureUnarchiveFromData")], even though I do not use any transformable types. I verified the macros, no transformable was specified. This is causing ModelCoders to encode/decode my properties incorrectly. This is not an issue when I switch back to OS 26.0 simulators.

If Cloudkit is enabled, SwiftData @Query operation hangs when the View scenePhase becomes active. Seems like the more @Query calls you have, the more it hangs. This has been first documented some time ago, but in typical Apple style, it has not been addressed or even commented on. https://developer.apple.com/forums/thread/761434

I have a CoreData model with two configuration - but several problems. Notably the viewContext only shows data from the .private configuration. Here is the setup: The private configuration holds entities, for example, User and Course and the shared one holds entities, for example, Player and League. I setup the NSPersistentStoreDescriptions to use the same container but with a databaseScope of .private/.shared and with the configuration of "Private"/"Shared". loadPersistentStores() does not report an error. If I try container.initializeCloudKitSchema() only the .private configuration produces CKRecord types. If I create a companion app using one configuration (w/ all entities) the schema initialization creates all CKRecord types AND I can populate some data in the .private and a created CKShare. I see that data in the CloudKit dashboard. If I axe the companion app and run the real thing w/ two configurations, the viewContext only has the .private data. Why? If when querying history I use NSPersistentHistoryTransaction.fetchRequest I get a nil return when using two configurations (but non-nil when using one).

About 4 months ago, I shipped the first version of my app with 4 versioned schemas that, unintentionally, had the same versionIdentifier of 1.2.0 in 2 of them: V1: 1.0.0 V2: 1.1.0 V3: 1.2.0 V4: 1.2.0 They are ordered correctly in the MigrationPlan, and they are all lightweight. Migration works, SwiftData doesn't crash on init and I haven't encountered any issues related to this. The app syncs with iCloud. Questions, preferable for anybody with knowledge of SwiftData internals: What will break in SwiftData when there are 2 duplicate numbers? Not that I would expect it to be safe, but does it happen to be safe to ship an update that changes V4's version to 1.3.0, what was originally intended?

Hi everyone, I’m facing an issue with CloudKit sync getting stuck during initial device migration in my SwiftData-based app. The app follows a local-first architecture using SwiftData + CloudKit sync, and works correctly for: ✔ Incremental sync ✔ Bi-directional updates ✔ Small datasets However, when onboarding a new device with large historical data, sync becomes extremely slow or appears stuck. Even after two hours data is not fully synced. ~6900 Transactions 🚨 Problem When installing the app on a new iPhone and enabling iCloud sync: • Initial hydration starts • A small amount of data syncs • Then sync stalls indefinitely Observed behaviour: • iPhone → Mac sync works (new changes sync back) • Mac → iPhone large historical migration gets stuck • Reinstalling app / clearing container does not resolve issue • Sync never completes full migration This gives the impression that: CloudKit is trickling data but not progressing after a certain threshold. The architecture is: • SwiftData local store • Manual CloudKit sync layer • Local-first persistence • Background push/pull sync So I understand: ✔ Conflict resolution is custom ✔ Initial import may not be optimized by default But I expected CloudKit to eventually deliver all records. Instead, the new device remains permanently in a “partial state”. ⸻ 🔍 Observations • No fatal CloudKit errors • No rate-limit errors • No quota issues • iCloud is available • Sync state remains “Ready” • Hydration remains “mostlyReady” Meaning: CloudKit does not report failure — but data transfer halts. ⸻ 🤔 Questions Would appreciate guidance on: Is CloudKit designed to support large initial dataset migration via manual sync layers? Or is this a known limitation vs NSPersistentCloudKitContainer? ⸻ Does CloudKit internally throttle historical record fetches? Could it silently stall without error when record volume is high? ⸻ Is there any recommended strategy for: • Bulk initial migration • Progressive hydration • Forcing forward sync progress ⸻ Should initial migration be handled outside CloudKit (e.g. via file transfer / backup restore) before enabling sync? ⸻ 🎯 Goal I want to support: • Large historical onboarding • Multi-device sync • User-visible progress Without forcing migration to Core Data. ⸻ 🙏 Any advice on: • Best practices • Debugging approach • CloudKit behavior in such scenarios would be greatly appreciated. Thank you!

Hi All, I work on a cross platform app, iOS/macOS. All devises on iOS could synchronize data from Coredata : I create a client, I see him an all iOS devices. But when I test on macOs (with TestFlight) the Mac app could not get any information from iOs devices. On Mac, cloud drive is working because I could download and upload documents and share it between all devices, so the account is working but with my App on MacOS, there is no synchronisation. idea????

Hey everyone, I have a question. When creating an app, how should I design a message table that involves personal privacy? The content is stored locally on the user's device, and then encrypted in the server database? How should I design it?

I'm experiencing the following error with my SwiftData container when running a build: Code=134504 "Cannot use staged migration with an unknown model version." Code Structure - Summary I am using a versionedSchema to store multiple models in SwiftData. I started experiencing this issue when adding two new models in the newest Schema version. Starting from the current public version, V4.4.6, there are two migrations. Migration Summary The first migration is to V4.4.7. This is a lightweight migration removing one attribute from one of the models. This was tested and worked successfully. The second migration is to V5.0.0. This is a custom migration adding two new models, and instantiating instances of the two new models based on data from instances of the existing models. In the initial testing of this version, no issues were observed. Issue and Steps to Reproduce Reproduction of issue: Starting from a fresh build of the publicly released V4.4.6, I run a new build that contains both Schema Versions (V4.4.7 and V5.0.0), and their associated migration stages. This builds successfully, and the container successfully migrates to V5.0.0. Checking the default.store file, all values appear to migrate and instantiate correctly. The second step in reproduction of the issue is to simply stop running the build, and then rebuild, without any code changes. This fails to initialize the model container every time afterwards. Going back to the simulator after successive builds are stopped in Xcode, the app launches and accesses/modifies the model container as normal. Supplementary Issue: I have been putting up with the same, persistent issue in the Xcode Preview Canvas of "Failed to Initialize Model Container" This is a 5 in 6 build issue, where builds will work at random. In the case of previews, I have cleared all data associated with all previews multiple times. The only difference being that the simulator is a 100% failure rate after the initial, successful initialization. I assume this is due to the different build structure of previews. Lastly, of note, the Xcode previews fail at the same line in instantiating the model container as the simulator does. From my research into this issue, people say that the Xcode preview is instantiating from elsewhere. I do have a separate model container set up specifically for canvas previews, but the error does not occur in that container, but rather the app's main container. Possible Contributing Factors & Tested Facts iOS: While I have experienced issues with SwiftData and the complier in iOS 26, I can rule that out as the issue here. This has been tested on simulators running iOS 18.6, 26.0.1, and 26.1, all encountering failures to initialize model container. While in iOS 18, subsequent builds after the successful migration did work, I did eventually encounter the same error and crash. In iOS 26.0.1 and 26.1, these errors come immediately on the second build. Container Initialization for V4.4.6 do { container = try ModelContainer( for: Job.self, JobTask.self, Day.self, Charge.self, Material.self, Person.self, TaskCategory.self, Service.self, migrationPlan: JobifyMigrationPlan.self ) } catch { fatalError("Failed to Initialize Model Container") } Versioned Schema Instance for V4.4.6 (V4.4.7 differs only by versionIdentifier) static var versionIdentifier = Schema.Version(4, 4, 6) static var models: [any PersistentModel.Type] { [Job.self, JobTask.self, Day.self, Charge.self, Material.self, Person.self, TaskCategory.self, Service.self] } Container Initialization for V5.0.0 do { let schema = Schema([Jobify.self, JobTask.self, Day.self, Charge.self, MaterialItem.self, Person.self, TaskCategory.self, Service.self, ServiceJob.self, RecurerRule.self]) container = try ModelContainer( for: schema, migrationPlan: JobifyMigrationPlan.self ) } catch { fatalError("Failed to Initialize Model Container") } Versioned Schema Instance for V5.0.0 static var versionIdentifier = Schema.Version(5, 0, 0) static var models: [any PersistentModel.Type] { [ JobifySchemaV500.Job.self, JobifySchemaV500.JobTask.self, JobifySchemaV500.Day.self, JobifySchemaV500.Charge.self, JobifySchemaV500.Material.self, JobifySchemaV500.Person.self, JobifySchemaV500.TaskCategory.self, JobifySchemaV500.Service.self, JobifySchemaV500.ServiceJob.self, JobifySchemaV500.RecurerRule.self ] } Addressing Differences in Object Names Type-aliasing: All my model types are type-aliased for simplification in view components. All types are aliased as 'JobifySchemeV446.<#Name#>' in V.4.4.6, and 'JobifySchemaV500.<#Name#>' in V5.0.0 Issues with iOS 26: My type-aliases dating back to iOS 17 overlapped with lower level objects in Swift, including 'Job' and 'Material'. These started to be an issue with initializing the model container when running in iOS 26. The type aliases have been renamed since, however the V4.4.6 build with the old names runs and builds perfectly fine in iOS 26 If there is any other code that may be relevant in determining where this error is occurring, I would be happy to add it. My current best theory is simply that I have mistakenly omitted code relevant to the SwiftData Migration.

I am trying to save to cloud kit shared database. The shared database does not allow zones to be set up. How do I save to sharedCloudDatabase without a zone? private func addItem(recordType: String, name: String) { let record = CKRecord(recordType: recordType) record[Constances.field.name] = name as CKRecordValue record[Constances.field.done] = false as CKRecordValue record[Constances.field.priority] = 0 as CKRecordValue CKContainer.default().sharedCloudDatabase.save(record) { [weak self] returnRecord, error in if let error = error { print("Error saving record: \(record[Constances.field.name] as? String ?? "No Name"): \n \(error)") return } } } The following error message prints out: Error saving record: Milk: &lt;CKError 0x15af87900: "Server Rejected Request" (15/2027); server message = "Default zone is not accessible in shared DB"; op = B085F7BA703D4A08; uuid = 87AEFB09-4386-4E43-81D7-971AAE8BA9E0; container ID = "iCloud.com.sfw-consulting.Family-List"&gt;

I have a new app I am working on, it uses, a container id like com.me.mycompany.FancyApp.prod, the description in the app is My Fancy App. When I deploy the app via TestFlight on a real device, the sync seems to work, but when I view iCloud->Storage-List, I see my app icon, and the name "prod". Where did the name prod come from? It should be My Fancy App, which is the actual name of the App.

Hi, Not sure how to describe my issue best: I am using SwiftData and CloudKit to store my data. In the past, when I tested my app on different devices, the data would sync between the devices automatically. For whatever reason this has stopped now and the data no longer syncs. No matter what I do, it feels as if all the data is actually stored just locally on each device. How can I check if the data is actually stored in the cloud and what could be reasons, why its no longer synching between my devices (and yes, I am logged in with the same Apple ID on all devices). Thanks for any hint! Max

If an app is using top-level models, meaning they exist outside the VersionedSchema enum, is it safe to keep them outside of the VersionedSchema enum and use a migration plan for simple migrations. Moving the models within the VersionedSchema enum I believe would change the identity of the models and result in data being lost, although correct me if I'm wrong in that statement. The need presently is just to add another variable to the model and then set that variable within the init function: var updateId = UUID() The app is presently in TestFlight although I'd like to preserve data for users that are currently using the app. The data within SwiftData is synchronized with CloudKit and so I'd also like to avoid any impact to synchronization. Any thoughts on this would be greatly appreciated.

Hello, the last days I was trying to solve a bug in my Unit Tests related to the CoreData "NSManagedObjectContextObjectsDidChange" Notification. Im using some kind of Notification handler to save and abstract that for the UI and while the tests are running this notification was triggered with objects that doesn't exists anymore, which has resulted in a crash. After some debugging I have detected, that the objects in here are really old. The objects here was from few tests ago, where a Merge Conflict happened. In the meantime there was a plenty of resets and deletes of the whole db. I have also seen that the bad notification is the first in the stack trace of the main thread, which is in my opinion also not usual. So the real question is: The only difference what I have found for the bad notification to the real notification, was the existence of the key "NSObjectsChangedByMergeChangesKey" in the UserInfo dictionary of the ObjectsDidChange Notification. But this key is nowhere found in the documentation of Apple. Also the search engines does not produce any result. So what is this key and when is this key contained in this notification and when not? Maybe if I understand this, it helps me to understand the overall issue ...

Hi all I have a problem with core data, where when a new user login that is different from the previous user i delete all of core data by using "destroyPersistentStore". Then i recreate the persistent store, this works when i am testing. When it does not work for one of my users when she test. I am not sure why this should not work, i have added the code i use to destroy the persistent store below. This code is run after login but before the view changes away from my login view. // Retrieves the shared `AppDelegate` instance guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else { return } appDelegate.destroyDataSyncBackground() // Get a reference to a NSPersistentStoreCoordinator let storeContainer = appDelegate.persistentContainer.persistentStoreCoordinator // Delete each existing persistent store for store in storeContainer.persistentStores { if let url = store.url { do { try storeContainer.destroyPersistentStore( at: url, ofType: store.type, options: nil ) } catch { print("Failed to deleted all") } } else { print("Failed to deleted all") } } // Re-create the persistent container appDelegate.persistentContainer = NSPersistentContainer( name: "CueToCue" // the name of // a .xcdatamodeld file ) // Calling loadPersistentStores will re-create the // persistent stores appDelegate.persistentContainer.loadPersistentStores { (store, error) in // Handle errors let description = NSPersistentStoreDescription() description.shouldMigrateStoreAutomatically = true description.shouldInferMappingModelAutomatically = true appDelegate.persistentContainer.persistentStoreDescriptions = [description] } // Reapply context configuration let viewContext = appDelegate.persistentContainer.viewContext viewContext.automaticallyMergesChangesFromParent = true viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy do { try viewContext.save() appDelegate.recreateDataSyncBackground() } catch { print("Debug: saving delete all failed.") } } The function "destroyDataSyncBackground" just set the my sync class to nil so stop any changes to core data while the code is running. The function "recreateDataSyncBackground" recreate the sync class so fetch, post and patch requests is made again.

If use a SortDescriptor for a model and sort by some attribute from a relationship, in DEBUG mode it all works fine and sorts. However, in release mode, it is an instant crash. SortDescriptor(.name, order: .reverse) ---- works SortDescriptor(.assignedUser?.name, order: .reverse) ---- works in debug but crash in release. What is the issue here, is it that SwiftData just incompetent to do this?