Hello, With Core Data, we can use the isConfiguration(withName:compatibleWithStoreMetadata:) method on an NSManagedObjectModel alongside metadata(for:) on NSPersistentStoreCoordinator to check if the on-disk store is up to date or not. Is this the way to do it too with SwiftData or do we have an easier way to check if the on-disk store will need to migrate? I want to inform my users in the UI when the app launches (or from widgets or app intents). Regards, Axel

I find these sample projects quite valuable: https://developer.apple.com/documentation/widgetkit/emoji-rangers-supporting-live-activities-interactivity-and-animations https://developer.apple.com/documentation/coredata/sharing-core-data-objects-between-icloud-users . Both use Swift 5, and it is not trivial to adopt Swift 6 with them. Any plans to update them? What is best approach for adopting Swift 6 on such sample code?

We've spent several days diagnosing a CoreData migration crash that is iOS 26-specific and reproducible 100% of the time. Posting here in case others have hit this and because we believe it's an Apple bug worth documenting. Upgrading from our App Store build (CoreData model v10) to our latest TestFlight build (model v11) crashes on iOS 26 with: NSCocoaErrorDomain / Code 134110 no such column: "Z_110GROUPITEMS1" The same upgrade path on iOS 17 and iOS 18 works perfectly. What v10→v11 changes Two new entities added alphabetically early in the alphabet One new optional boolean attribute on an existing entity One new optional to-many relationship on the same existing entity All changes are lightweight-migration compatible. We use shouldMigrateStoreAutomatically = true and shouldInferMappingModelAutomatically = true Here's what we observed Adding two entities alphabetically shifts Z_ENT numbers for all subsequent entities. A central entity (EntityA) moves from Z_ENT 110 (v10) to Z_ENT 112 (v11). It has many-to-many relationships with four other entities (EntityB, EntityC, EntityD, EntityE), all using the same inverse relationship name: groupItems. Because multiple join tables reference EntityA via the same inverse name, CoreData appends a disambiguation suffix (1, 2, etc.) to column names in each join table. In v10, the relevant join tables are Z_110ENTITYB and Z_110ENTITYC, each with a column named Z_110GROUPITEMS + a suffix. -com.apple.CoreData.SQLDebug 3 prints: ALTER TABLE Z_112ENTITYB RENAME COLUMN Z_110GROUPITEMS1 TO Z_112GROUPITEMS1 But the actual column in a fresh iOS 26 v10 store is Z_110GROUPITEMS2. Column not found → crash. iOS 17/18 is consistent: both code paths use suffix 1 for Z_110ENTITYB and 2 for Z_110ENTITYC. Migration succeeds. To confirm We opened the SQLite store from a fresh iOS 26 v10 install and inspected the schema: CREATE TABLE Z_110ENTITYB ( Z_110GROUPITEMS2 INTEGER, Z_112ENTITYB INTEGER, PRIMARY KEY (Z_110GROUPITEMS2, Z_112ENTITYB) ); Then we manually renamed Z_110GROUPITEMS2 → Z_110GROUPITEMS1 and Z_110ENTITYC.Z_110GROUPITEMS1 → Z_110GROUPITEMS2 in the SQLite file. Re-ran the app — migration succeeded. The suffixes are literally swapped between what iOS 26 creates on fresh install vs. what iOS 26's migration engine expects. Our database has over 50 entities and we never before faced such an issue. This is not the first lightweight migration we are releasing after iOS 26 and that's what puzzled us. Why now?

Are there good ways to guide an app to pause iCloud syncing if the app is busy with an intensive activity? Also, is there a way to suggest that it check iCloud for updates?

Hi there!, I have been developing an app where you can create a collection and I want to add a new feature where you can share an iCloud link from that collection and collaborate with your family or friends who you share the link to complete that collection. Like Apple does with the notes app or some other apps. The problem I have encountered is programming in swift does not allow you to do that and I need to do it I Core Data... Do you think with all the new stuff announced during the WWDC26 It could be done in Swift or I have to change coding?? Thanks community for any help

I'm attempting to create a feature where I can allow two levels of information

I’m investigating Core Data lightweight migration behavior with SQLite and ran into a performance issue. Scenario: Model V1: EntityA has one fetchIndex Model V2: EntityA adds a new optional attribute timestamp (Integer 64), with no changes to existing attributes or fetchIndex definitions From a SQLite perspective, this change should be handled by a simple: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER But I observe that Core Data rebuilds the existing index, which becomes a significant performance issue for large databases. CoreData: sql: DROP INDEX IF EXISTS Z_EntityA_id CoreData: sql: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER CoreData: sql: CREATE INDEX IF NOT EXISTS Z_EntityA_byID ON ZENTITYA Question: Is there any way to avoid or bypass index rebuilding for this kind of schema changes?

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!

I am using SwiftData for my model. Until Xcode 15 beta 4 I did not have issues. Since beta 5 I am receiving the following red warning multiple times: 'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release This seems to be a CoreData warning. However, I am not using CoreData directly. I have no way to change the config of CoreData as used by SwiftData. My model just uses UUID, Int, String, Double, some of them as optionals or Arrays. I only use one attribute (.unique).

I have a medium sized schema which has nested maps which if flattened comes to about 20-25 separate fields. I want to know what is the industry approach and standard. Should it be saved flattened or should it be saved nested as binary data + codable. Also one more thing to keep in mind is we are trying to keep it similar across android and iOS

I'm experiencing an issue where the App Group shared container appears to be recreated (with a new creation date) during an app update, resulting in complete loss of locally stored data. Background My app uses UserDefaults, Realm, Core Data, and CloudKit, with all local data stored in the App Group container (FileManager.containerURL(forSecurityApplicationGroupIdentifier:)). The app has been available since 2016 and has a stable user base. Starting last year, I began receiving occasional reports from users saying all their data in the app had disappeared. To investigate, I added diagnostic logging that detects when an existing user's data appears to have been reset — specifically by checking the App Group container's file system creation date, and the existence and values of expected files. What the diagnostics revealed When the issue occurs, I observe the following: The App Group container has a recent creation date, far newer than the user's first launch date The Core Data store file's creation date is also immediately after the App Group container's recreation date I write the same values to both standard UserDefaults and the App Group version (UserDefaults(suiteName:)). Only the App Group version is reset — the standard side retains historical data The standard side still holds firstLaunchDate, initialVersion, and launchCount, confirming this is not a fresh install Here is a sample diagnostic log from an affected user: appGroupContainerCreationDate: 2026-03-30T18:44:10Z firstLaunchDate: 2025/01/05 4:00 initialVersion: 10.8.0 currentAppVersion: 10.14.14 previousVersion: 10.10.0 launchCount: 44 availableStorageMB: 46646 The container creation date (2026-03-30) is clearly inconsistent with the user's first launch date (2025-01-05) and launch count (44). The container creation date is obtained with the following code: let appGroupURL = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: "group.xxx.xxx" )! let attributes = try? FileManager.default.attributesOfItem(atPath: appGroupURL.path) let containerCreationDate = attributes?[.creationDate] as? Date Scale and pattern Reports began increasing in late November last year Over 85% of affected cases are on iOS 26 Most affected devices have plenty of available storage (46GB+ in the example above) This is likely occurring during a normal app update (not a fresh install or device restore) Ruled-out hypotheses Not a fresh install — firstLaunchDate, initialVersion, and launchCount are preserved in standard UserDefaults Not a storage issue — affected users typically have tens of GBs of free space, making it unlikely that iOS purged the data due to low storage Not an app-side code change — the App Group identifier and entitlements have not been changed Not triggered by silent notifications, background tasks, or widget activity — these processes do write to the App Group container, but the recreation does not appear to occur immediately after any of these operations Questions Has anyone else observed App Group containers being recreated (new creation date, empty contents) during a standard app update? Is there a known iOS behavior or bug that could cause this, particularly on iOS 26? Are there any recommended mitigations? Any insight would be greatly appreciated. This is a data loss issue affecting real users, and I'd like to understand whether this is an iOS-level problem or something I should be handling differently on my end.

I am planning a Core Data migration for a macOS app targeting macOS 12 and later and I would appreciate guidance on structuring the rollout to minimise risk. Context The app currently uses a SQLite store located at: ~/Library/Containers/com.company.AppName/Data/Library/Application Support/AppName I want to: Relocate the persistent store to an app group container: ~/Library/Group Containers/group.com.company.AppName Perform schema migration, including: Renaming attributes Deleting attributes Using a custom NSEntityMigrationPolicy subclass Adopt iCloud sync using NSPersistentCloudKitContainer Potentially leverage staged migration (macOS 14+) Additionally, I intend to port the app to iOS, so the end state needs to support an app group container and CloudKit with the latest schema from the outset. Questions Store relocation vs schema migration Is it advisable to perform store relocation and schema migration in a single step, or should these be separate releases? If combined, are there pitfalls when moving the SQLite file and running a migration in the same launch cycle? Custom migration policy Any best practices for structuring NSEntityMigrationPolicy when also relocating the store? Should migration policies assume the store has already been moved, or handle both concerns? Staged migration (macOS 14+) Is staged migration worth adopting when still supporting macOS 12–13? Would you gate it conditionally, or avoid it entirely for consistency? CloudKit adoption Is introducing NSPersistentCloudKitContainer in the same release as the above migrations too risky? Are there known issues when enabling CloudKit immediately after a migration? Release strategy Would you recommend: A single release handling everything Two phases: (1) store & schema migration, (2) CloudKit Or three phases: store relocation → schema migration → CloudKit Goal I want a smooth, reliable transition without data loss or duplication, particularly for existing users with non-trivial datasets. Any insights, practical experience, or recommended sequencing strategies would be very helpful.

In an iOS App that uses CKShare I have a many-to-many relationship that does not consistently sync between the share's N participants. The relationship is between Group and Player as group.players and player.groups. As an example, given 3 group each with 4 players (aka 4:4:4), some devices show CoreData (it is NOT a UI issue) with 4:2:3 or 3:4:4. (A deletion of CoreData from a device, forcing a full re-sync from CloudKit, seems to populate the group:player relationships consistently; but obviously that is impractical to resolving the issue). How do I avoid these sync-from-CloudKit inconsistencies? Note: AI agents generally suggest adding a CoreData 'join' entity - such as 'GroupPlayer'. Is that THE fix?

Hello, I have a iOS app I was looking at porting to Mac. I'm having an issue with both the Mac (Designed for iPad) and Mac Catalyst Destinations. I can't test Mac due to too many build issues. I'm trying to assign a new NSManagedObject into a NSPersistentStore. let object = MyObject(context: context) context.assign(object, to: nsPersistentStore) This works fine for iOS/iOS Simulator/iPhone/iPad. But on the Mac it's crashing with FAULT: NSInvalidArgumentException: Can't assign an object to a store that does not contain the object's entity.; { Thread 1: "Can't assign an object to a store that does not contain the object's entity."

I've been trying to build an example of NSStagedMigrationManager from some Core Data migration tests to replace a custom migration manager solution I'd constructed, without much success. The Core Data model has seven model versions. Most support lightweight migration, but two of the migrations in the middle of the sequence used NSMappingModel. In the first beta, just attempting to construct an NSStagedMigrationManager from the series of stages failed with an unrecognized selector. That no longer happens in b4, but I now get an error that "Duplicate version checksums across stages detected." If I restrict myself to just the first three versions of the model (that only require lightweight migration), I can build the migration manager. But if I attempt to use it to migrate a persistent store, it fails somewhere in NSPersistentStoreCoordinator with a nilError. The documentation is almost nonexistent for this process, and the WWDC session that introduced it isn't much more than a breezy overview. So maybe I'm holding it wrong? (And, yes: FB12339663)

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.

Hi, I’m looking for clarification on what concurrency and consistency guarantees Apple provides when multiple targets (main app + Widget extensions) access shared storage. Specifically: 1. UserDefaults (App Group / suiteName:) • If multiple processes (app + multiple widget instances) read and write the same shared UserDefaults, what guarantees are provided? • Is access serialized internally to prevent corruption? • Are read–modify–write operations safe across processes, or can lost updates occur? 2. Core Data (shared SQLite store in App Group container) • Is it officially supported for multiple processes to open and write to the same Core Data SQLite store? • Are there recommended configurations (e.g. WAL mode) for safe multi-process access? • Is Apple’s recommendation to have a single writer process? 3. FileManager (shared container files) • If two processes write to the same file in an App Group container, what guarantees are provided by the system? • Is atomic replaceItemAt the recommended pattern for safe cross-process updates? Additionally: • Do multiple widget instances count as separate processes with respect to these guarantees? • Is there official guidance on best practices for shared persistence between app and widget extensions? I want to ensure I’m following the correct architecture and not relying on undefined behavior. Thanks.

I've understood that SwiftData is not abled to share the whole content of a cloudkit database. So I'm trying to rewrite everything. Does someone knows id Sharing is coming on SwiftData at WWDC 26? Anyway, can someone can point me an example a a configured coredata stack that share all its content with other icloud users (with sharing pane and accept invitation code). At this step, on the owner side, I see some data in the default zone of my private container but nothing is visible on the shared zone. Maybe I don't understand where and when I should check shared data in cloudkit console. Need Help also here. See below by configuration stack: // Core Data container public lazy var container: NSPersistentContainer = { switch delegate.usage() { case .preview : return previewContainer() case .local : return localContainer() case .cloudKit : return cloudKitContainer() } }() private func cloudKitContainer() -> NSPersistentContainer { let modelURL = delegate.modelURL() let modelName = modelURL.deletingPathExtension().lastPathComponent guard let model = NSManagedObjectModel(contentsOf: modelURL) else { fatalError("Could not load Core Data model from \(modelURL)") } let container = NSPersistentCloudKitContainer( name: modelName, managedObjectModel: model ) let groupIdentifier = AppManager.shared.groupIdentifier guard let appGroupURL = FileManager.default.containerURL ( forSecurityApplicationGroupIdentifier: groupIdentifier ) else { fatalError("App Group not found: \(groupIdentifier)") } // MARK: - Private Store Configuration let privateStoreURL = appGroupURL.appendingPathComponent("\(modelName).sqlite") let privateStoreDescription = NSPersistentStoreDescription(url: privateStoreURL) // Persistent history tracking (MANDATORY) privateStoreDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) privateStoreDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) // CloudKit options for private database // Core Data automatically uses the default zone: com.apple.coredata.cloudkit.zone let privateCloudKitOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: delegate.cloudKitIdentifier()) privateCloudKitOptions.databaseScope = .private privateStoreDescription.cloudKitContainerOptions = privateCloudKitOptions // MARK: - Shared Store Configuration guard let sharedStoreDescription = privateStoreDescription.copy() as? NSPersistentStoreDescription else { fatalError("Create shareDesc error") } // The shared store receives zones that others share with us via CloudKit's shared database sharedStoreDescription.url = appGroupURL.appendingPathComponent("\(modelName)-shared.sqlite") // Persistent history tracking (MANDATORY) sharedStoreDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) sharedStoreDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) // CloudKit options for shared database // This syncs data from CloudKit shared zones when we accept share invitations let sharedCloudKitOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: delegate.cloudKitIdentifier()) sharedCloudKitOptions.databaseScope = .shared sharedStoreDescription.cloudKitContainerOptions = sharedCloudKitOptions // Configure both stores // Private store: com.apple.coredata.cloudkit.zone in private database // Shared store: Receives shared zones we're invited to container.persistentStoreDescriptions = [privateStoreDescription, sharedStoreDescription] container.loadPersistentStores { storeDescription, error in if let error = error as NSError? { fatalError("DB init error:\(error.localizedDescription)") } else if let cloudKitContiainerOptions = storeDescription.cloudKitContainerOptions { switch cloudKitContiainerOptions.databaseScope { case .private: self._privatePersistentStore = container.persistentStoreCoordinator.persistentStore(for: privateStoreDescription.url!) case .shared: self._sharedPersistentStore = container.persistentStoreCoordinator.persistentStore(for: sharedStoreDescription.url!) default: break } } let scope = storeDescription.cloudKitContainerOptions?.databaseScope == .shared ? "shared" : "private" print("✅ \(scope) store loaded at: \(storeDescription.url?.path ?? "unknown")") } // Auto-merge container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy do { try container.viewContext.setQueryGenerationFrom(.current) } catch { fatalError("Fail to pin viewContext to the current generation:\(error)") } return container }

Hello, I have 3 model versions and I'm trying to step through migration. Version 2 makes significant changes to v1. As a result, I've renamed the entities in question by appending _v2 to their name, as the data isn't important to retain. v3, remove's the appended version number from v2. Setting the .xcdatamodeld to v3 and the migrations steps array as follows causes the app to error [ NSLightweightMigrationStage([v1]), NSLightweightMigrationStage([v2]), NSLightweightMigrationStage([v3]), ] CoreData: error: <NSPersistentStoreCoordinator: 0x10740d680>: Attempting recovery from error encountered during addPersistentStore: 0x10770f8a0 Error Domain=NSCocoaErrorDomain Code=134110 "An error occurred during persistent store migration." An error occurred during persistent store migration. Cannot merge multiple root entity source tables into one destination entity root table. I find this odd because if I run the migration independently across app launches, the migration appears to drop the no longer used tables in v2, then re-add them back in v3. So it seems to me that something is not finishing completely with the fully stepped through migration. -- I'm also unable to understand how to use NSCustomMigrationStage I've tried setting it to migrate from v1, to v2, but I'm getting a crash with error Duplicate version checksums across stages detected

If I have two consecutive calls like to perform(schedule: .immediate) like so: func doSomething() async { await self.perform(schedule: .immediate) { // add log event 1 to data store } await self.perform(schedule: .immediate) { // add log event 2 to data store } } Can I be guaranteed that the block for log event 1 will happen after log event 2? "log event" here is just an example, so please ignore things like storing date, etc. Looking at the documentation here: https://developer.apple.com/documentation/coredata/nsmanagedobjectcontext/perform(schedule:_:) It's a little unclear whether any such guarantee is in place. However, given that the function returns the value from the block, it seems like I should be able to expect event 1 will always be executed before event 2 regardless of the schedule parameter?