Hi everyone, I've recently implemented CKSyncEngine in my app, and I have two questions regarding its behavior: Duplicate FetchedRecordZoneChanges After Sending Changes: I’ve noticed that the engine sometimes receives a FetchedRecordZoneChanges event containing modifications and deletions that were just sent by the same device a few moments earlier. This event arrives after the SentRecordZoneChanges event, and both events share the same recordChangeTag, which results in double-handling the record. Is this expected behavior? I’d like to confirm if this is how CKSyncEngine works or if I might be overlooking something. Handling Initial Sync with a "Sync Screen": When a user opens the app for the first time and already has data stored in iCloud, I need to display a "Sync Screen" temporarily to prevent showing partial data or triggering abrupt, rapid UI changes. I’ve found that canceling current operations, then awaiting sendChanges() and fetchChanges() works well to ensure data is fully synced before dismissing the sync screen: displaySyncScreen = true await syncEngine.cancelOperations() try await syncEngine.sendChanges() try await syncEngine.fetchChanges() displaySyncScreen = false However, I’m unsure if canceling operations like this could lead to data loss or other issues. Is this a safe approach, or would you recommend a better strategy for handling this initial sync state?

The production macOS build is showing severe performance problems, while Mac_Dev performs normally. Observed behavior in production Mac build: Issue board scrolling becomes inconsistent or nearly unusable Changing an issue status in detail view is very slow Scrolling the status menu/options can be slow Typing in issue description/notes fields becomes sluggish Dragging issues between milestones/statuses on the board can lag badly Observed behavior in Mac_Dev: Board scrolling is smooth Status changes are immediate Typing in description fields is responsive Drag/drop between milestones works well Important comparison: Mac_Dev appears to run against an isolated local SwiftData store Production Mac app uses the normal CloudKit-backed store Because the same UI is fast in Mac_Dev, this does not look like a pure rendering problem Most likely cause is production store / CloudKit sync churn amplifying existing SwiftUI invalidation and save behavior Current hypothesis: The production app is saving or observing live Issue mutations too aggressively Detail view edits and some quick actions may be causing repeated saves / broad view invalidation Cloud-backed persistence likely makes the problem much worse than the isolated dev store The UI architecture may still need cleanup, but the production data lane is likely a major factor Any help in understanding how best to address this would be helpful.

Hello all Synopsis: document based SwiftData app breaks document handling after first save due to internal error saving the -shm file. Long: i am working on a small document based SwiftData app for macOS. The UI works well as long as the document was not saved. After saving the document and reopening it, I get an error consistently in console: BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: /Users/vrunkel/Library/Containers/de.ecoobs.CurtailmentAnalyzer/Data/tmp/TemporaryItems/NSIRD_CurtailmentAnalyzer_mrXKMs/NewDocument/StoreContent-shm So somehow the -shm file is still referenced to NewDocument created when the app opens an untitled document and resides in the temporary folder. I have saved the document to my documents folder. After reopening and the above error deletion or addition of items crashes the app with a long backtrace to view updating: Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. I am not creating any threads or do background work. If I do not save the document but work within the new untitled document no problems occur. Even closing the app and reopening the untitled new doc (happens automatically) all is fine. To rule out any influence of my existing view structure I have created the most simple test case - Xcode -> New Project -> macOS document based app configured to use SwiftData. Same behaviour. After saving a new document the addition/deletion of items causes the thread-induced crash and shows the error in console when opening the document. I am using latest versions of Xcode 15.0 and macOS 14.0 Any ideas? thx, volker

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?

I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<ChildModel> I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test environment, so the model that's being deleted (or any other) is not being accessed by any other part of the application. However, problem looks the same in the real app. I also changed the target version of iOS from 18.0 to 26.0, but to no avail. My models look kind of like this: @Model final class ParentModel { var name: String @Relationship(deleteRule: .cascade, inverse: \ChildModel.parent) var children: [ChildModel]? init(name: String) { self.name = name } } @Model final class ChildModel { var name: String @Relationship(deleteRule: .nullify) var parent: ParentModel? init(name: String) { self.name = name } } I tried many approaches that didn't help: Fetching all children (via fetch) just to "populate" the context Accessing all children on parent model (via let _ = parentModel.children?.count) Deleting all children reading models from parent: for child in parentModel.children ?? [] { modelContext.delete(child) } Deleting all children like this: let parentPersistentModelID = parentModel.persistentModelID modelContext.delete(model: ChildModel.self, where: #Predicate { $0.parent.persistentModelID == parentPersistentModelID }, includeSubclasses: true) Removing @Relationship(deleteRule: .nullify) from ChildModel relationship definition I found 2 solution for the problem: To manually fetch and delete all children prior to deleting parent: let parentPersistentModelID = parentModel.persistentModelID for child in try modelContext.fetch(FetchDescriptor<ChildModel>(predicate: #Predicate { $0.parent.persistentModelID == parentPersistentModelID })) { modelContext.delete(child) } modelContext.delete(parentModel) Trying to run my code in child context (let childContext = ModelContext(modelContext.container)) All that sounds to me like a problem deep inside Swift Data itself. The first solution I found, fetching potentially hundreds of child models just to delete them in case I might need to rollback changes on some error, sounds like awful waste of resources to me. The second one however seems to work fine has that drawback that I can't fully test my code. Right now I can wrap the context (literally creating class that holds ModelContext and calls its methods) and in tests for throwing methods force them to throw. By creating scratch ModelContext I loose that possibility. What might be the real issue here? Am I missing something?

I have two different VersionedSchema accessed via two different and distinct in-memory ModelContainers. However, both schemas have a model named Item. LocalSchema.Item and RemoteSchema.Item have slightly different properties. If I create and save RemoteSchema.Item in one context then I cannot create and save LocalSchema.Item in a different context due to missing origin property. enum LocalSchema: VersionedSchema { static var versionIdentifier: Schema.Version = .init(1, 0, 0) static var models: [any PersistentModel.Type] = [ Item.self ] @Model class Item { @Attribute(.unique) var title: String var created: Date var modified: Date init(title: String, created: Date, modified: Date) { self.title = title self.created = created self.modified = modified } } } enum RemoteSchema: VersionedSchema { static var versionIdentifier: Schema.Version = .init(1, 0, 0) static var models: [any PersistentModel.Type] = [ Item.self ] @Model class Item { var title: String var created: Date var modified: Date var origin: String init(title: String, created: Date, modified: Date, origin: String) { self.title = title self.created = created self.modified = modified self.origin = origin } } } In the above example, saving RemoteSchema.Item will cause LocalSchema.Item to fail. The error message I see is *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<NSManagedObject 0xa120f3750> setValue:forUndefinedKey:]: the entity Item is not key value coding-compliant for the key "origin".' Test Code @Test func createLocalItemWithManualSave() async throws { let context = ModelContext(try localStore()) let item = LocalSchema.Item(title: "local", created: .now, modified: .now) context.insert(item) try context.save() } @Test func createRemoteItemWithManualSave() async throws { let context = ModelContext(try remoteStore()) let item = RemoteSchema.Item(title: "remote", created: .now, modified: .now, origin: "from space") context.insert(item) try context.save() } func localStore() throws -> ModelContainer { let schema = Schema(versionedSchema: LocalSchema.self) let config = ModelConfiguration("local", schema: schema, isStoredInMemoryOnly: true, allowsSave: true, cloudKitDatabase: .none) return try ModelContainer(for: schema, configurations: config) } func remoteStore() throws -> ModelContainer { let schema = Schema(versionedSchema: RemoteSchema.self) let config = ModelConfiguration("remote", schema: schema, isStoredInMemoryOnly: true, allowsSave: true, cloudKitDatabase: .none) return try ModelContainer(for: schema, configurations: config) } I have created FB22310365

CloudKit: Efficient way to get user's rank in leaderboard without fetching all records? I'm building a leaderboard feature using CloudKit's public database and need advice on the best approach to calculate a user's rank efficiently. Current Setup Record Structure: Record Type: LeaderboardScore Fields: period (String): "daily", "weekly", "monthly", "allTime" score (Int): User's score profile (Reference): Link to user's profile achievedAt (Date): Timestamp Leaderboard Display: Initially fetch first 15 users (sorted by score descending) Paginate to load more as user scrolls Show total player count Show current user's rank (even if not in top 15) The Challenge I can fetch the first 15 users easily with a sorted query, but I need to display the current user's rank regardless of their position. For example: User could be ranked #1 (in top 15) ✅ Easy User could be ranked #247 (not in top 15) ❌ How to get this efficiently? My Current Approach Query records with scores higher than the user's score and count them: // Count how many users scored higher let predicate = NSPredicate( format: "period == %@ AND score > %d", period, userScore ) // Rank = count + 1 Concerns For 1000+ users with better scores, this requires multiple paginated queries Even with desiredKeys: [], I'm concerned about performance and CloudKit request limits Questions Is there a CloudKit API I'm missing that can efficiently count records matching a predicate without fetching all the records and paginating? Is this approach acceptable for a leaderboard with 1K-10K users? Does fetching with desiredKeys: [] help significantly with performance? Are there any optimizations I should consider to make this more efficient? What's the recommended approach for calculating user rank in CloudKit at this scale? Current Scale Expected: 1,000-10,000 active users per leaderboard period Platform: iOS 17+, SwiftUI Any guidance on best practices for leaderboards usecase in CloudKit would be greatly appreciated!

I've spent a few months writing an app that uses SwiftData with inheritance. Everything worked well until I tried adding CloudKit support. To do so, I had to make all relationships optional, which exposed what appears to be a bug. Note that this isn't a CloudKit issue -- it happens even when CloudKit is disabled -- but it's due to the requirement for optional relationships. In the code below, I get the following error on the second call to modelContext.save() when the button is clicked: Could not cast value of type 'SwiftData.PersistentIdentifier' (0x1ef510b68) to 'SimplePersistenceIdentifierTest.Computer' (0x1025884e0). I was surprised to find zero hit when Googling "Could not cast value of type 'SwiftData.PersistentIdentifier'". Some things to note: Calling teacher.computers?.append(computer) instead of computer.teacher = teacher results in the same error. It only happens when Teacher inherits Person. It only happens if modelContext.save() is called both times. It works if the first modelContext.save() is commented out. If the second modelContext.save()is commented out, the error occurs the second time the model context is saved (whether explicitly or implicitly). Keep in mind this is a super simple repro written to generate on demand the error I'm seeing in a normal app. In my app, modelContext.save() must be called in some places to update the UI immediately, sometimes resulting in the error seconds later when the model context is saved automatically. Not calling modelContext.save() doesn't appear to be an option. To be sure, I'm new to this ecosystem so I'd be thrilled if I've missed something obvious! Any thoughts are appreciated. import Foundation import SwiftData import SwiftUI struct ContentView: View { @Environment(\.modelContext) var modelContext var body: some View { VStack { Button("Do it") { let teacher = Teacher() let computer = Computer() modelContext.insert(teacher) modelContext.insert(computer) try! modelContext.save() computer.teacher = teacher try! modelContext.save() } } } } @Model class Computer { @Relationship(deleteRule: .nullify) var teacher: Teacher? init() {} } @Model class Person { init() {} } @available(iOS 26.0, macOS 26.0, *) @Model class Teacher: Person { @Relationship(deleteRule: .nullify, inverse: \Computer.teacher) public var computers: [Computer]? = [] override init() { super.init() } }

Hi Writing an app in Swift on Xcode for my iPhone, all software is the latest version. If after making a minor change and re-building all the application data has disappeared, is there a way to see if it is still in the .modelContainer and just not showing up?

I'm running into a problem in my attempt to clear CKAssets on the iCloud server. The documentation for CKAsset says: If you no longer require an asset that’s on the server, you don’t delete it. Instead, orphan the asset by setting any fields that contain the asset to nil and then saving the record. CloudKit periodically deletes orphaned assets from the server. I'm deleting image file assets which are properties on an ImageReference type (largeImage and thumbNailImage properties). When I delete an image, I am setting those properties to nil and sending the record for the ImageReference to iCloud using the async CKDatabase.modifyRecords method. This always results in an error: <CKError 0x600000d92a60: "Asset File Not Found" (16/3002); "open error: 2 (No such file or directory)"> And of course the assets still appear in the CloudKit dashboard. What is the proper way of orphaning the assets on the CloudKit server?

Hey everyone, I found a possible SwiftData Release-only issue with nested sort descriptors on an optional relationship. In a minimal repro, sorting a @Query by a nested optional relationship key path like: SortDescriptor(\InvestigationPhotoAsset.imageAnalysis?.overallAestheticsScore, order: .reverse) works in Debug, but crashes at runtime in Release. The surprising part is that the crash depends on file layout: if the active SwiftData models and the sort logic are kept in the same Swift file, the app works if the same models are split into separate files, the Release build crashes, 'Debug' will also work The repro was reduced to just two SwiftData models: InvestigationPhotoAsset InvestigationImageAnalysis So this looks less like an app-modeling issue and more like a SwiftData/compiler/codegen issue related to nested sort metadata in optimized builds. If useful, I can also give you a slightly more formal version with a title and code snippet block. Please check out the code example here Has anyone faced something similar? Bug is reported as FB22173905

I accidentally deleted all CloudKit containers from the CloudKit Database console, and now I'm unable to create new containers. Both the CloudKit Console website and Xcode are not allowing me to create any new containers. Is there a way to restore the deleted containers? How can I create a new CloudKit container if the console website is not responding? Thank you.

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."

Hi forum! I’m currently following a series of videos about SwiftData. In the WWDC23 Build an app with SwiftData video, it mentions that you can follow up with a demo project. However, I’m encountering an issue (at least in my case) where there’s no link on the entire page to download the project. I can download the video and other resources (even using the Developer’s App), but there’s no link for the project. Does anyone else face this issue? Is it possible that the project has been removed? I’m using my developer (single user) account, by the way. Any guidance would be greatly appreciated!

I currently have a schema in production (cloudKit and local files) containing non-optional transformable values, e.g. @Attribute(.transformable(by: TestTransformer.self)) var number: TestTransformable = TestTransformable.init(value: 100) Unfortunately, this is preventing any migration from succeeding (documented at length in FB22151570). Briefly summarized, any migration from a Schema containing non-optional transformable values fails between willMigrate and didMigrate with the error "Can't find model for source store". This occurs for all migrations, including lightweight with a migration plan, lightweight without a plan, and custom migrations. Worst of all, this also prevents migration to optional transformable values, or the elimination of the transformable value entirely, leaving us completely stuck. (note: optional transformable values only work when they have a default value set to nil, otherwise even these have issues migrating) We already have features being blocked by this issue, and would like to preserve user-data while restoring our ability to move forwards with database. Are there any known workarounds for using SwiftData (+CloudKit) when schema migration is non-operational?

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.

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 }

I'm trying to understand the terminology around forward vs backward references in CloudKit. Say I have two record types: User LeaderboardScore (a score belongs to a user) The score record stores a user reference: score["user"] = CKRecord.Reference( recordID: userRecordID, action: .deleteSelf ) So: LeaderboardScore → User The user record does not store any references to scores From a data-model perspective: Is this considered a forward reference (child → parent)? Or a back reference, since the score is "pointing back" to its owner? My use case is having leaderboard in my app and so i have created a user table to store all the users and a score table for saving the scores of each user of the app.