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!

"No records found" If I create a new record on the console, I can copy the record name. I can then query for recordName and get that individual record back. BUT no other queries work. I cannot query all records. I cannot query by individual property. Just returns "no records found" Seems like my indexes got messed up. Is there a way to reset indexes on prod? This is on a coredata.cloudkit managed zone.

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?

Greetings i have an app that uses three different SwiftData models and i want to know what is the best way to use the them accross the app. I though a centralized behaviour and i want to know if it a correct approach.First let's suppose that the first view of the app will load the three models using the @Enviroment that work with @Observation. Then to other views that add data to the swiftModels again with the @Environment. Another View that will use the swiftData models with graph and datas for average and min and max.Is this a corrent way? or i should use @Query in every view that i want and ModelContext when i add the data. @Observable class CentralizedDataModels { var firstDataModel: [FirstDataModel] = [] var secondDataModel: [SecondDataModel] = [] var thirdDataModel: [ThirdDataModel] = [] let context: ModelContext init(context:ModelContext) { self.context = context } }

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 reliably crashes with the following error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<DocumentTest.ChildItem> And before the app crashes, what always happens is that UndoManager stops removing/restoring instances of ChildItem (but continues to remove/restore instances of ParentItem). The issue goes away when I enclose the relevant code in ModelContext.transaction(block:). However, this shouldn't be necessary, as ModelContext.autosaveEnabled is true by default. 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 sample project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/13bCB1qRZ6273BI81zW2zUUBraSvv6p5w?usp=share_link Is this expected behavior or should I file a bug report in 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 add another ChildItem to it. Repeat steps 5–6 until you have 5 ParentItems with an additional 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 UndoManager stops removing/restoring the additional ChildItem, and continue repeating them until the app eventually crashes (you may have to repeat them 5–10 times before the issue occurs). If you uncomment the ModelContext.transaction(block:) at line 13 of ContentView.swift and repeat the same steps above, no ChildItems will go missing and the app will not crash. 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 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 */ for newChildItem in newChildItems { newParentItem.childItems.append( newChildItem ) newChildItem.parentItem = newParentItem } Adding an Additional ChildItem to ParentItem // Uncommenting this block fixes the crash // try! modelContext.transaction { // Create and insert the new ChildItem let newChildItem = ChildItem( index: parentItem.childItems.count ) modelContext.insert(newChildItem) // Establish relationship to parentItem parentItem.childItems.append(newChildItem) newChildItem.parentItem = parentItem // }

The NSMetadataUbiquitousItemDownloadingStatusKey indicates the status of a ubiquitous (iCloud Drive) file. A key value of NSMetadataUbiquitousItemDownloadingStatusDownloaded is defined as indicating there is a local version of this file available. The most current version will get downloaded as soon as possible . However this no longer occurs since iOS 18.4. A ubiquitous file may remain in the NSMetadataUbiquitousItemDownloadingStatusDownloaded state for an indefinite period. There is a workaround: call [NSFileManager startDownloadingUbiquitousItemAtURL: error:] however this shouldn't be necessary, and introduces delays over the previous behaviour. Has anyone else seen this behaviour? Is this a permanent change? FB17662379

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

When I query, an existing database with over 10,000 records from an Objective C app (i.e. CKQueryOperation) I get only N x 100 records returned where N varies each time between 0 and about 10 (i.e. never more than 1000 records and always an even multiple of 100). When I do a “Query Records” on the CloudKit Dashboard I get a similar number of pages of records downloaded (i.e. 0-10). If I tap “Query Records” multiple times I will get more pages of records until the full 10,000 are downloaded. This had been working fine until recently, both from the app and the Dashboard. There are multiple Record Types in the database. Only one Record Type is erroring. The other Record Types continue to work both from the app and the Dashboard. In particular, the Users Record Type has many many records and they all download to many pages with a single tap of “Query Records”. I have posted this to the Feedback Assistant under FB22358865. Here is my code: NSPredicate *predicate =[NSPredicate predicateWithFormat:@"modificationDate>%@",dateLastSynched]; CKRecordType theRecordName=[NSString stringWithString:@"Notices”]; // I also try this for @“Links” and @“Messages” and @“EventMessages" CKQuery *query = [[CKQuery alloc] initWithRecordType:theRecordName predicate:predicate]; CKQueryOperation *theOperation=[[CKQueryOperation alloc] initWithQuery:query]; [self startAQueryOperation:(CKQueryOperation *)theOperation theName:(NSString *)recordName]; -(void)startAQueryOperation:(CKQueryOperation *)theOperation theName:(NSString *)recordName{ theOperation.recordFetchedBlock=^(CKRecord *theRecord){ NSLog(@"XXXjust downloaded a %@",recordName); }; theOperation.queryCompletionBlock=^(CKQueryCursor *theCursor, NSError *error){ if(error){ NSLog(@"XXXerror %@",error); } if(theCursor){ CKQueryOperation *anotherOperation=[[CKQueryOperation alloc] initWithCursor:theCursor]; [self startAQueryOperation:anotherOperation theName:recordName]; } }; CKDatabase *publicDatabase = [[CKContainer defaultContainer] publicCloudDatabase]; [publicDatabase addOperation:theOperation]; } When I run this code in the app I get no “XXXerror” from the NSLogs. I get the expected number of “XXXjust downloaded a” EventMessages (435) and Messages (594) and Links (15) but I get varying amounts, 100 or 400 or 500 “xxjust downloaded a” for the Notices when I should get 10,118 records. Thinking that 10,000 records is too much, if I alter “dateLastSynched” for Notices I still get only 100 or 200, not the expected number. Note that the number is always a multiple of 100. This seems to be consistent with the typical number of records I get on the CloudKit dashboard each time I tap “Query Records”.

When creating a new project in Xcode 26, the default for defaultIsolation is MainActor. Core Data creates classes for each entity using code gen, but now those classes are also internally marked as MainActor, which causes issues when accessing managed object from a background thread like this. Is there a way to fix this warning or should Xcode actually mark these auto generated classes as nonisolated to make this better? Filed as FB13840800. nonisolated struct BackgroundDataHandler { @concurrent func saveItem() async throws { let context = await PersistenceController.shared.container.newBackgroundContext() try await context.perform { let newGame = Item(context: context) newGame.timestamp = Date.now // Main actor-isolated property 'timestamp' can not be mutated from a nonisolated context; this is an error in the Swift 6 language mode try context.save() } } } Turning code gen off inside the model and creating it manually, with the nonisolated keyword, gets rid of the warning and still works fine. So I guess the auto generated class could adopt this as well? public import Foundation public import CoreData public typealias ItemCoreDataClassSet = NSSet @objc(Item) nonisolated public class Item: NSManagedObject { }

I'm testing CloudKit Sharing (CKShare) in my app. My app uses CloudKit Sharing to share private data between users (this is not App Store Family Sharing or purchase sharing, it's app-level sharing via CKShare). To properly test this, I need three or four Apple Accounts with distinct roles in my app. This means I need three/four separate iCloud accounts signed in on test devices. Simulators are probably ok: two acting as "parents" (share owner and participant): parent1.sandbox@example.com parent2.sandbox@example.com, one or two as a "child" (participant) child1.sandbox@example.com child2.sandbox@example.com except obviously using my domain name. I attempted to create Sandbox Apple Accounts in App Store Connect, but these don't appear to work with CloudKit Sharing. I then created several standard Apple Accounts, but I've now hit a limit — I believe my mobile number (used for two-factor authentication on the test accounts) has been flagged or rate-limited for account creation, and I can no longer create or verify new accounts with it. It's also blocked the email addresses associated with those accounts from being used for new account creation. Can Apple or anyone advise on the recommended approach for testing CloudKit Sharing with multiple participants? are Sandbox accounts supposed to work for CKShare, or do I need full Apple Accounts? How do i create and verify these in the correct way to avoid hitting these limits or breaking terms of service?

Hi, I am building an iOS app with SwiftUI and SwiftData for the first time and I am experiencing a lot of difficulty with this error: Thread 44: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(<ID> <x-coredata://<UUID>/MySwiftDataModel/p1>)), backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(<ID> <x-coredata://<UUID>/MySwiftDataModel/p1>)) with Optional(<UUID>) I have been trying to figure out what the problem is, but unfortunately I cannot find any information in the documentation or on other sources online. My only theory about this error is that it is somehow related to fetching an entity that has been created in-memory, but not yet saved to the modelContext in SwiftData. However, when I am trying to debug this, it's not clear this is the case. Sometimes the error happens, sometimes it doesn't. Saving manually does not always solve the error. Therefore, it would be extremely helpful if someone could explain what this error means and whether there are any best practices to do with SwiftData, or some pitfalls to avoid (such as wrapping my model context into a repository class). To be clear, this problem is NOT related to one area of my code, it happens throughout my app, at unpredictable places and time. Given that there is very little information related to this error, I am at a loss at how to make sure that this never happens. This question has been asked on the forum here as well as on StackOverflow, Reddit (can't link that here), but none of the answers worked for me. For reference, my models generally look like this: import Foundation import SwiftData @Model final class MySwiftDataModel { // Stable cross-device identity @Attribute(.unique) var uuid: UUID var someNumber: Int var someString: String @Relationship(deleteRule: .nullify, inverse: \AnotherSwiftDataModel.parentModel) var childModels: [AnotherSwiftDataModel] init(uuid: UUID = UUID(), someNumber: Int = 1, someString: String = "Some", childModels: [AnotherSwiftDataModel] = []) { self.uuid = uuid self.someNumber = someNumber self.someString = someString self.childModels = childModels } func addChildModel(model: AnotherSwiftDataModel) { self.childModels.append(model) } func removeChildModel(by id: PersistentIdentifier) { self.childModels = self.childModels.filter { $0.id != id } } } and the child model: import Foundation import SwiftData @Model final class AnotherSwiftDataModel { // Stable cross-device identity @Attribute(.unique) var uuid: UUID var someNumber: Int var someString: String var parentModel: MySwiftDataModel? init(uuid: UUID = UUID(), someNumber: Int = 1, someString: String = "Some") { self.uuid = uuid self.someNumber = someNumber self.someString = someString } } For now, you can assume I am not using CloudKit - i know for a fact the error is unrelated to CloudKit, because it happens when I am not using CloudKit (so I do not need to follow CloudKit's requirements for model design, such as nullable values etc). As I said, the error surfaces at different times - sometimes during assignments, a lot of times during deletions of related models, etc. Could you please explain what I am doing wrong and how I can make sure that this error does not happen? What are the architectural patterns that work best for SwiftData in this case? Do you have any examples of things I should avoid? Thanks

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????

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?

Environment visionOS 26 Xcode 26 Issue I am experiencing crash when trying to access a [String] from a @Model data, after dismissing an immersiveSpace and opening a WindowGroup. This crash only occurs when trying to access the [String] property of my Model. It works fine with other properties. Thread 1: Fatal error: This backing data was detached from a context without resolving attribute faults: PersistentIdentifier(...) Steps to Reproduce Open WindowGroup Dismiss window, open ImmersiveSpace Dismiss ImmersiveSpace, reopen WindowGroup Any guidance would be appreciated! @main struct MyApp: App { var body: some Scene { WindowGroup(id: "main") { ContentView() } .modelContainer(for: [Item.self]) ImmersiveSpace(id: "immersive") { ImmersiveView() } } } // In SwiftData model @Model class Item { var title: String = "" // Accessing this property works fine var tags: [String] = [] @storageRestrictions(accesses: _$backingData, initializes: _tags) init(initialValue) { _$backingData.setValue(forKey: \. tags, to: initialValue) _tags =_ SwiftDataNoType() } get { _$observationRegistrar.access(self, keyPath: \.tags) **return self getValue(forkey: \.tags)** // Crashes here }

Hello 👋, I encounter the "This model instance was invalidated because its backing data could no longer be found the store" crash with SwiftData. Which from what I understood means I try to access a model after it has been removed from the store (makes sense). I made a quick sample to reproduce/better understand because there some case(s) I can't figure it out. Let's take a concrete example, we have Home model and a Home can have many Room(s). // Sample code @MainActor let foo = Foo() // A single reference let database = Database(modelContainer: sharedModelContainer) // A single reference @MainActor class Foo { // Properties to explicilty keep reference of model(s) for the purpose of the POC var _homes = [Home]() var _rooms = [Room]() func fetch() async { let homes = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home } print(ObjectIdentifier(homes[0]), homes[0].rooms?.map(\.id)) // This will crash here or not. } // Same version of a delete function with subtle changes. // Depending on the one you use calling delete then fetch will result in a crash or not. // Keep a reference to only homes == NO CRASH func deleteV1() async { self._homes = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home } await database.delete() } // Keep a reference to only rooms == NO CRASH func deleteV2() async { self._rooms = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home }[0].rooms ?? [] await database.delete() } // Keep a reference to homes & rooms == CRASH 💥 func deleteV3() async { self._homes = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home } self._rooms = _homes[0].rooms ?? [] // or even only retain reference to rooms that have NOT been deleted 🤔 like here "id: 2" make it crash // self._rooms = _homes[0].rooms?.filter { r in r.id == "2" } ?? [] await database.delete() } } Calling deleteV() then fetch() will result in a crash or not depending on the scenario. I guess I understand deleteV1, deleteV2. In those case an unsaved model is served by the model(for:) API and accessing properties later on will resolve correctly. The doc says: "The identified persistent model, if known to the context; otherwise, an unsaved model with its persistentModelID property set to persistentModelID." But I'm not sure about deleteV3. It seems the ModelContext is kind of "aware" there is still cyclic reference between my models that are retained in my code so it will serve these instances instead when calling model(for:) API ? I see my home still have 4 rooms (instead of 2). So I then try to access rooms that are deleted and it crash. Why of that ? I mean why not returning home with two room like in deleteV1 ? Because SwiftData heavily rely on CoreData may be I miss a very simple thing here. If someone read this and have a clue for me I would be extremely graceful. PS: If someone wants to run it on his machine here's some helpful code: // Database let sharedModelContainer: ModelContainer = { let schema = Schema([ Home.self, Room.self, ]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false) debugPrint(modelConfiguration.url.absoluteString.replacing("%20", with: "\\ ")) return try! ModelContainer(for: schema, configurations: [modelConfiguration]) }() extension Database { static let shared = Database(modelContainer: sharedModelContainer) } @ModelActor actor Database { func insert() async { let r1 = Room(id: "1", name: "R1") let r2 = Room(id: "2", name: "R2") let r3 = Room(id: "3", name: "R3") let r4 = Room(id: "4", name: "R4") let home = Home(id: "1", name: "My Home") home.rooms = [r1, r2, r3, r4] modelContext.insert(home) try! modelContext.save() } func fetch() async -> [PersistentIdentifier] { try! modelContext.fetchIdentifiers(FetchDescriptor<Home>()) } @MainActor func delete() async { let mainContext = sharedModelContainer.mainContext try! mainContext.delete( model: Room.self, where: #Predicate { r in r.id == "1" || r.id == "4" } ) try! mainContext.save() // 🤔 Calling fetch here seems to solve crash too, force home relationship to be rebuild correctly ? // let _ = try! sharedModelContainer.mainContext.fetch(FetchDescriptor<Home>()) } } // Models @Model class Home: Identifiable { @Attribute(.unique) public var id: String var name: String @Relationship(deleteRule: .cascade, inverse: \Room.home) var rooms: [Room]? init(id: String, name: String, rooms: [Room]? = nil) { self.id = id self.name = name self.rooms = rooms } } @Model class Room: Identifiable { @Attribute(.unique) public var id: String var name: String var home: Home? init(id: String, name: String, home: Home? = nil) { self.id = id self.name = name self.home = home } }

Hello everyone, I am experiencing a persistent authentication error when querying a custom user profile record, and the error message seems to be a red herring. My Setup: I have a custom CKRecord type called ColaboradorProfile. When a new user signs up, I create this record and store their hashed password, salt, nickname, and a custom field called loginIdentifier (which is just their lowercase username). In the CloudKit Dashboard, I have manually added an index for loginIdentifier and set it to Queryable and Searchable. I have deployed this schema to Production. The Problem: During login, I run an async function to find the user's profile using this indexed loginIdentifier. Here is the relevant authentication code: func autenticar() async { // ... setup code (isLoading, etc.) let lowercasedUsername = username.lowercased() // My predicate ONLY filters on 'loginIdentifier' let predicate = NSPredicate(format: "loginIdentifier == %@", lowercasedUsername) let query = CKQuery(recordType: "ColaboradorProfile", predicate: predicate) // I only need these specific keys let desiredKeys = ["password", "passwordSalt", "nickname", "isAdmin", "isSubAdmin", "username"] let database = CKContainer.default().publicCloudDatabase do { // This is the line that throws the error let result = try await database.records(matching: query, desiredKeys: desiredKeys, resultsLimit: 1) // ... (rest of the password verification logic) } catch { // The error always lands here logDebug("Error authenticating with CloudKit: \(error.localizedDescription)") await MainActor.run { self.errorMessage = "Connection Error: \(error.localizedDescription)" self.isLoading = false self.showAlert = true } } } The Error: Even though my query predicate only references loginIdentifier, the catch block consistently reports this error: Error authenticating with CloudKit: Field 'createdBy' is not marked queryable. I know createdBy (the system creatorUserRecordID) is not queryable by default, but my query isn't touching that field. I already tried indexing createdBy just in case, but the error persists. It seems CloudKit cannot find or use my index for loginIdentifier and is incorrectly reporting a fallback error related to a system field. Has anyone seen this behavior? Why would CloudKit report an error about createdBy when the query is explicitly on an indexed, custom field? I'm new to Swift and I'm struggling quite a bit. Thank you,

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 have implemented CKSyncEngine synchronization, and it works well. I can update data on one device and see the changes propagate to another device quickly. However, the initial sync when a user downloads the app on a new device is a significant issue for both me and my users. One problem is that the sync engine fetches deletion events from the server. On a new device, the local database is empty, so these deletions are essentially no-ops. This would not be a big problem if there were only a few records or if it was fast. I measured the initial sync and found that there are 150 modified records and 62,168 deletions. Counting these alone takes over five minutes, even without processing them. The deletions do nothing because the local database has nothing to delete, yet they still add a significant delay. I understand that the sync engine ensures consistency across all devices, but five minutes of waiting with the app open just to insert a small number of records is excessive. The problem would be worse if there were tens of thousands of new records to insert, since downloading and saving the data would take even longer. This leads to a poor user experience. Users open the app and see data being populated for several minutes, or they are stuck on a screen that says the data is being synchronized with iCloud. I am wondering if there is a way to make the sync engine ignore deletion events when the state serialization is nil. Alternatively, is there a recommended method for handling initial synchronization more efficiently? One idea I considered is storing all the data as a backup in iCloud Documents, along with the state serialization at that point in time. When a user opens the app for the first time, I could download the file, extract the data, and set the state serialization to the saved value. I am not sure if this would work. I do not know if state serialization is tied to the device or if it only represents the point where the sync engine left off. My guess is that it might reference some local device storage. I am not sure what else to try. I could fetch all data using CloudKit, create the sync engine with an empty state serialization, and let it fetch everything again, but that would still take a long time. My records are very small, mostly a date when something happened and an ID referencing the parent. Since the app tracks watched episodes, I only store the date the user watched the episode and the ID of that episode.

Greetings my fellow engineers, I use SwiftData in my iOS app. The schema is unversioned and consists of a single model. I've been modifying the model for almost two years now and relying on automatic database migrations. I had no problems for all that time, but now trying to add a property to the model or even remove a property from the model results in an error which seems like SwiftData is no longer capable of performing an automatic migration. The log console has things like the following: CoreData: error: NSUnderlyingError : Error Domain=NSCocoaErrorDomain Code=134190 "(null)" UserInfo={reason=Each property must have a unique renaming identifier} CoreData: error: reason : Can't find or automatically infer mapping model for migration CoreData: error: storeType: SQLite CoreData: error: configuration: default CoreData: annotation: options: CoreData: annotation: NSMigratePersistentStoresAutomaticallyOption : 1 CoreData: annotation: NSInferMappingModelAutomaticallyOption : 1 CoreData: annotation: NSPersistentStoreRemoteChangeNotificationOptionKey : 1 CoreData: annotation: NSPersistentHistoryTrackingKey : 1 CoreData: error: <NSPersistentStoreCoordinator: 0x7547b5480>: Attempting recovery from error encountered during addPersistentStore: 0x753f8d800 Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model." Have you ever encountered such an issue? What are my options?

I have the following code running on macOS and iOS: CKQuerySubscription *zsub = [[CKQuerySubscription alloc] initWithRecordType:ESS_CLOUDCONTROLLER_RECORDTYPE_PUSHNOTE predicate:[NSPredicate predicateWithFormat:@"TRUEPREDICATE"] subscriptionID:@"pushZSub" options:CKQuerySubscriptionOptionsFiresOnRecordUpdate|CKQuerySubscriptionOptionsFiresOnRecordCreation|CKQuerySubscriptionOptionsFiresOnRecordDeletion]; zsub.zoneID = zid; CKNotificationInfo *inf = [[CKNotificationInfo alloc] init]; inf.shouldSendContentAvailable = YES; inf.desiredKeys = @[ESS_PN_RECORDFIELD_KEY_OVERALLDATE]; zsub.notificationInfo = inf; CKModifySubscriptionsOperation *msop = [[CKModifySubscriptionsOperation alloc] initWithSubscriptionsToSave:@[zsub] subscriptionIDsToDelete:nil]; msop.qualityOfService = NSQualityOfServiceUserInitiated; msop.modifySubscriptionsCompletionBlock = ^(NSArray<CKSubscription *> * _Nullable savedSubscriptions, NSArray<CKSubscriptionID> * _Nullable deletedSubscriptionIDs, NSError * _Nullable operationError) { dispatch_async(dispatch_get_main_queue(), ^{ if (savedSubscriptions.count == 1) { //works also when already created. compH(YES, nil); } else { compH(NO, nil); } }); }; [self.database addOperation:msop]; (code synopsis: after i create a custom zone (not shown in code), I add a ckquerysubscription to it for a specific record type, configured as a silent notification) When I change the according record in my Mac app, I get an immediate silent push on iOS. On macOS, however, after I change the record in my iOS app, I don't get one. Sometimes, one silent push makes it through every now and then a minute+ late or so, and after that, it's going missing again. What's the deal? Everything's set up correctly (com.apple.developer.aps-environment is set, container-identifiers are the same, icloud services are the same, ubiquity-kvstore-identifier are the same). I obviously register for remote notifications in both apps. I see all the records and subscriptions and zones in both the Mac and iOS app. I tried setting alertBody to an empty string, or soundName to an empty string, or both to an empty string: no difference I tried having different subscriptions for my Mac and iOS app, since they use different bundle ids, but that was merged into one subscription server-side, so I'm thinking that's not it I tried making it not-silent by setting contentAvailable to NO and adding a full alertBody, title and subtitle. Again, worked on iOS, not on macOS. This has been going on since macOS 14 Sonoma (when I first got reports of this. Now running on macOS 26.3). Before Sonoma, it worked just fine. Now I thought perhaps it's because I had a subscription on the default zone, and not a custom one, so I tried subscribing to changes on a record in a custom zone (see code above), but that did not change anything either. It's all working fine, only the push notifications are not making it through to the Mac app. If I sudo killall apsd (kill the push service daemon), the last push notification suddenly miraculously makes it through, by the way. At this point, I'm out of ideas and would very much appreciate pointers as to how to debug this. Polling every 30 seconds for changes is so 1990s. Speaking of which, this is a rather long-time-running app (started in 2011). Could my CloudKit database be “too old” or “corrupted” or whatever? Thank you kindly, – Matthias