The problem is that the iCloud Drive directory of my app does not appear in my iCloud Drive in Finder despite the (I think) correct settings in my info.plist file (see below). In Terminal, I can see the folder and it also contains .txt files. What can I do to make the folder visible in Finder and the Files app? <key>NSUbiquitousContainers</key> <dict> <key>iCloud.vmk.NewsSwiper</key> <dict> <key>NSUbiquitousContainerIsDocumentScopePublic</key> <true/> <key>NSUbiquitousContainerName</key> <string>RSS-Filter</string> <key>NSUbiquitousContainerIdentifier</key> <string>iCloud.vmk.NewsSwiper</string> <key>NSUbiquitousContainerSupportedFolderLevels</key> <string>Any</string> </dict> </dict>

I’m getting a 0xdead10cc crash in a basic CoreData/CloudKit application. I only have one CoreData save call and its made when the app is in the foreground and it's minor so I don't think its being caused by that. My best guess is that it's related to background syncing of CloudKit. Does anyone know how to fix it? I've been advised that adding the following code around any saves will fix it, but it seems weird that this is the solution. I would expect the inner CoreData/CloudKit engine to handle this. ProcessInfo().performActivity(reason: "Persisting to context") { // Save to context here } Here is the crashing thread Thread 7: 0 libsystem_kernel.dylib 0x00000001edc086f4 guarded_pwrite_np + 8 (:-1) 1 libsqlite3.dylib 0x00000001ca71b6e4 seekAndWrite + 456 (sqlite3.c:44287) 2 libsqlite3.dylib 0x00000001ca6d5df4 unixWrite + 180 (sqlite3.c:44365) 3 libsqlite3.dylib 0x00000001ca723b90 pagerWalFrames + 872 (sqlite3.c:67093) 4 libsqlite3.dylib 0x00000001ca6d5b14 sqlite3PagerCommitPhaseOne + 316 (sqlite3.c:70409) 5 libsqlite3.dylib 0x00000001ca6c6494 sqlite3BtreeCommitPhaseOne + 172 (sqlite3.c:81106) 6 libsqlite3.dylib 0x00000001ca6c605c vdbeCommit + 1136 (sqlite3.c:94124) 7 libsqlite3.dylib 0x00000001ca69f778 sqlite3VdbeHalt + 1340 (sqlite3.c:94534) 8 libsqlite3.dylib 0x00000001ca6c0618 sqlite3VdbeExec + 42648 (sqlite3.c:103922) 9 libsqlite3.dylib 0x00000001ca6b56c0 sqlite3_step + 960 (sqlite3.c:97886) 10 CoreData 0x00000001a459ab38 _execute + 128 (NSSQLiteConnection.m:4614) 11 CoreData 0x00000001a45fe004 -[NSSQLiteConnection commitTransaction] + 728 (NSSQLiteConnection.m:3278) 12 CoreData 0x00000001a469888c _executeGenerateObjectIDRequest + 388 (NSSQLCore_Functions.m:6021) 13 CoreData 0x00000001a46986a4 -[NSSQLGenerateObjectIDRequestContext executeRequestCore:] + 28 (NSSQLObjectIDRequestContext.m:42) 14 CoreData 0x00000001a45fb380 -[NSSQLStoreRequestContext executeRequestUsingConnection:] + 240 (NSSQLStoreRequestContext.m:183) 15 CoreData 0x00000001a45fb0a8 __52-[NSSQLDefaultConnectionManager handleStoreRequest:]_block_invoke + 60 (NSSQLConnectionManager.m:307) 16 CoreData 0x00000001a45fafe0 __37-[NSSQLiteConnection performAndWait:]_block_invoke + 48 (NSSQLiteConnection.m:755) 17 libdispatch.dylib 0x00000001a4357fa8 _dispatch_client_callout + 20 (object.m:576) 18 libdispatch.dylib 0x00000001a43677fc _dispatch_lane_barrier_sync_invoke_and_complete + 56 (queue.c:1104) 19 CoreData 0x00000001a45b5ba4 -[NSSQLiteConnection performAndWait:] + 176 (NSSQLiteConnection.m:752) 20 CoreData 0x00000001a45b5a68 -[NSSQLDefaultConnectionManager handleStoreRequest:] + 248 (NSSQLConnectionManager.m:302) 21 CoreData 0x00000001a45b5938 -[NSSQLCoreDispatchManager routeStoreRequest:] + 228 (NSSQLCoreDispatchManager.m:60) 22 CoreData 0x00000001a45b573c -[NSSQLCore dispatchRequest:withRetries:] + 172 (NSSQLCore.m:4044) 23 CoreData 0x00000001a46737b4 -[NSSQLCore _obtainPermanentIDsForObjects:withNotification:error:] + 1324 (NSSQLCore.m:2830) 24 CoreData 0x00000001a460ba98 -[NSSQLCore _prepareForExecuteRequest:withContext:error:] + 272 (NSSQLCore.m:2946) 25 CoreData 0x00000001a460a0f8 __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]_block_invoke.547 + 8988 (NSPersistentStoreCoordinator.m:2995) 26 CoreData 0x00000001a45d6660 -[NSPersistentStoreCoordinator _routeHeavyweightBlock:] + 264 (NSPersistentStoreCoordinator.m:668) 27 CoreData 0x00000001a45ded28 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1200 (NSPersistentStoreCoordinator.m:2810) 28 CoreData 0x00000001a4655988 -[NSManagedObjectContext save:] + 984 (NSManagedObjectContext.m:1593) 29 CoreData 0x00000001a46f47dc __52+[NSCKEvent beginEventForRequest:withMonitor:error:]_block_invoke_2 + 352 (NSCKEvent.m:76) 30 CoreData 0x00000001a45c28f0 developerSubmittedBlockToNSManagedObjectContextPerform + 476 (NSManagedObjectContext.m:3984) 31 libdispatch.dylib 0x00000001a4357fa8 _dispatch_client_callout + 20 (object.m:576) 32 libdispatch.dylib 0x00000001a43677fc _dispatch_lane_barrier_sync_invoke_and_complete + 56 (queue.c:1104) 33 CoreData 0x00000001a4615c34 -[NSManagedObjectContext performBlockAndWait:] + 308 (NSManagedObjectContext.m:4108) 34 CoreData 0x00000001a46f45ac __52+[NSCKEvent beginEventForRequest:withMonitor:error:]_block_invoke + 192 (NSCKEvent.m:66) 35 CoreData 0x00000001a4825e68 -[PFCloudKitStoreMonitor performBlock:] + 92 (PFCloudKitStoreMonitor.m:148) 36 CoreData 0x00000001a46f4394 +[NSCKEvent beginEventForRequest:withMonitor:error:] + 256 (NSCKEvent.m:61) 37 CoreData 0x00000001a47cc6ec __57-[NSCloudKitMirroringDelegate _performExportWithRequest:]_block_invoke + 260 (NSCloudKitMirroringDelegate.m:1433) 38 CoreData 0x00000001a47c9970 __92-[NSCloudKitMirroringDelegate _openTransactionWithLabel:assertionLabel:andExecuteWorkBlock:]_block_invoke + 72 (NSCloudKitMirroringDelegate.m:957) 39 libdispatch.dylib 0x00000001a4356248 _dispatch_call_block_and_release + 32 (init.c:1549) 40 libdispatch.dylib 0x00000001a4357fa8 _dispatch_client_callout + 20 (object.m:576) 41 libdispatch.dylib 0x00000001a435f5cc _dispatch_lane_serial_drain + 768 (queue.c:3934) 42 libdispatch.dylib 0x00000001a4360158 _dispatch_lane_invoke + 432 (queue.c:4025) 43 libdispatch.dylib 0x00000001a436b38c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 44 libdispatch.dylib 0x00000001a436abd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 45 libsystem_pthread.dylib 0x0000000227213680 _pthread_wqthread + 288 (pthread.c:2696) 46 libsystem_pthread.dylib 0x0000000227211474 start_wqthread + 8 (:-1)

Whilst all current answers to this question indicate the depreciation of CKModifyBadgeOperation, all of them had advised up until 2022 that it could still be used due to Apple not having a replacement Api. Upon running the following code: badgeReset.modifyBadgeCompletionBlock = { (error) -> Void in if error != nil { print("Error resetting badge: \(error!)") } } CKContainer.default().add(badgeReset) When run I receive the following error: Error resetting badge: <CKError 0x3001ddf50: "Invalid Arguments" (12/1017); "CKModifyBadgeOperation is no longer supported"> And from testing following this, the badge count incrementation issue continues, indicating that this has been completely invalidated and cannot be used at all. Even with UNUserNotificationCenter.current().setBadgeCount(0) this only clears the badge count temporarily. I'm aware of the proposed "workaround" of creating an extension that manually keeps track of notification count & sets the badge accordingly when a notification is received. However I'm trying to ascertain if as of this current point in time there is now no way whatsoever to clear the badge count on the Cloudkit sever level?

I have a requirement to get all records changed after a certain date. I have set modifiedTimestamp as Queryable, but when I attempt to do any query at all using the following operators: > < >= <= no results are returned. I have confirmed there are records that should be returned. The only operator that works is == and !=. I have tried the following: NSPredicate(format: "modificationDate > %@", lastFetched as NSDate) NSPredicate(format: "___modTime > %@", lastFetched as NSDate)

Hello, I'm using CoreData + CloudKit and I am facing the following error 134100 "The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store." All my schema updates are composed of adding optional attributes to existing entities, adding non-optional attributes (with default value) to existing entities or adding new entities Basically, only things that lightweight migrations can handle. Every time I update the schema, I add a new model version of xcdatamodel - who only has a single configuration (the "Default" one). And I also deploy the updated CloudKit schema from the dashboard. It worked up to v3 of my xcdatamodel, but started to crash for a few users at v4 when I added 16 new attributes (in total) to 4 existing entities. Then again at v5 when I added 2 new optional attributes to 1 existing entity. I'm using a singleton and here is the code: private func generateCloudKitContainer() -> NSPersistentCloudKitContainer { let container = NSPersistentCloudKitContainer(name: "MyAppModel") let fileLocation = URL(...) let description = NSPersistentStoreDescription(url: fileLocation) description.shouldMigrateStoreAutomatically = true description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) let options = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.com.company.MyApp") options.databaseScope = .private description.cloudKitContainerOptions = options container.persistentStoreDescriptions = [description] container.viewContext.automaticallyMergesChangesFromParent = true container.loadPersistentStores { description, error in container.viewContext.mergePolicy = NSMergePolicy(merge: .mergeByPropertyObjectTrumpMergePolicyType) if let error { // Error happens here! } } return container } I can't reproduce it yet. I don't really understand what could lead to this error.

SwiftData delete isn't working, when I attempt to delete a model, my app crashes and I get the following error: SwiftData/PersistentModel.swift:359: Fatal error: Cannot remove My_App.Model2 from relationship Relationship - name: model2, options: [], valueType: Model2, destination: Model2, inverseName: models3, inverseKeypath: Optional(\Model2.models3) on My_App.Model3 because an appropriate default value is not configured. I get that it's saying I don't have a default value, but why do I need one? Isn't @Relationship .cascade automatically deleting the associated models? And onto of that, why is the error occurring within the do block, shouldn't it be caught by the catch, and printed? I have put together a sample project below. import SwiftUI import SwiftData @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() .modelContainer(for: Model3.self) } } } @Model class Model1 { var name: String @Relationship(deleteRule: .cascade, inverse: \Model2.model1) var models2: [Model2] = [] init(name: String) { self.name = name } } @Model class Model2 { var name: String var model1: Model1 @Relationship(deleteRule: .cascade, inverse: \Model3.model2) var models3: [Model3] = [] init(name: String, model1: Model1) { self.name = name self.model1 = model1 } } @Model class Model3 { var name: String var model2: Model2 init(name: String, model2: Model2) { self.name = name self.model2 = model2 } } struct ContentView: View { @Query var models1: [Model1] @Environment(\.modelContext) var modelContext var body: some View { NavigationStack { List(models1) { model1 in Text(model1.name) .swipeActions { Button("Delete", systemImage: "trash", role: .destructive) { modelContext.delete(model1) do { try modelContext.save() //SwiftData/PersistentModel.swift:359: Fatal error: Cannot remove My_App.Model2 from relationship Relationship - name: model2, options: [], valueType: Model2, destination: Model2, inverseName: models3, inverseKeypath: Optional(\Model2.models3) on My_App.Model3 because an appropriate default value is not configured. } catch { print(error.localizedDescription) } } } } .toolbar { Button("Insert", systemImage: "plus") { modelContext.insert(Model3(name: "model3", model2: Model2(name: "model2", model1: Model1(name: "model1")))) } } } } }

I am attempting to migrate a cloudkit module that calls on manual cloudkit methods for fetching record zone changes, modifying records, etc to one that utilizes CKSyncEngine. I've got a basic implementation working with just a create method for one of my data models, however it seems like the sync engine keeps calling sync events on the same pending changes. Here is my current flow: The user will hit some button that lets them fill out a form to create a data model. The user saves the form. This triggers a method that takes the resulting data model and queues it to the sync engine's state (engine.state.add(pendingRecordZoneChanges: pendingChanges) I have my delegate method nextRecordZoneChangeBatch(_ context:...) implemented where it fetches the corresponding data model using the record ID and returns a batch containing the corresponding populated record from the data model. I have the handleEvent(_ event:...) delegate method implemented where I handle both .fetchRecordZoneChanges and .sentRecordZoneChanges. I have set up .sentRecordZoneChanges to merge the server record into my local record (and persisted locally) so that the record change tags are the same. After this last portion, it seems that the sync engine continues to keep pushing syncs/updates and I end up with numerous handleEvent(_ event:) calls that keep returning savedRecords (and occasionally failedRecordSaves). Am I missing some step to remove the record from the changes after the sync engine recognizes that I have properly saved the record to the server?

All of a sudden my app started getting this CloudKit error, and it happens to a lot of users. I had no changes to cloud sync for months and really surprised by seeing this. What confuses me even more, is that there is no information on the web about this kind of error. I have no idea what causes it and how to solve it. Would love to get any feedback from the CloudKit engineer. Client went away before operation 27761871408C460A could be validated; failing { "NSUnderlyingError": "<CKUnderlyingError 0x600002573f30: \"ClientInternalError\" (2005); \"Client went away before operation 27761871408C460A could be validated; failing\">", "CKErrorDescription": "Client went away before operation 27761871408C460A could be validated; failing", "NSDebugDescription": "CKInternalErrorDomain: 2005", "NSLocalizedDescription": "Client went away before operation 27761871408C460A could be validated; failing" } Seems to happen only on macOS.

I'm using SwiftData with CloudKit and have been trying to migrate from SchemaV1 to SchemaV2, but it seems reducing the Entities crashes my app. // Example of migrating from V1 to V2 // Dropping `Person` because it's no longer needed do { // SchemaV1: Person.self, Author.self // SchemaV2: Author.self let schema = Schema(versionedSchema: SchemaV2.self) return try ModelContainer( for: schema, migrationPlan: AppSchemaMigrationPlan.self, configurations: ModelConfiguration( cloudKitDatabase: .automatic) ) } catch { fatalError("Could not create ModelContainer: \(error)") } Is it possible to drop Entities in the Schema Migration Plan? How can I delete the Person model from my Schema and CloudKit?

In a CloudKit private database, the Owner creates a custom zone and performs the following actions: Creates CKRecord1 with CKShare1 and invites Participant1 to it. Creates CKRecord2 with CKShare2 and invites Participant2 to it. Creates CKRecordShared, which should be accessible to both Participant1 and Participant2. How can I achieve step 3? I observed that: Setting a regular reference from CKRecord1 (or CKRecord2) to CKRecordShared does not automatically make CKRecordShared accessible to Participant1 (or Participant2). CKRecordShared can only have one parent, so it cannot be directly linked via parent reference to both Participant1 and Participant2 at the same time. One potential solution I see is to have the Owner create a separate CKShare for CKRecordShared and share it explicitly with each participant. However, this approach could lead to user errors, as it requires careful management of multiple shares for each participant. Is there a better way to handle this scenario, ensuring that CKRecordShared is accessible to multiple participants without introducing unnecessary complexity or potential errors?

I have a bug I've come across since I've upgraded Xcode (16.0) and macOS (15.0 Sequoia) and figured I'd create a minimal viable example in case someone else came across this and help. I've noticed this in both the macOS and iOS version of my app when I run it. Essentially I have an area of my code that calls a class that has a step 1 and 2 process. The first step uses async let _ = await methodCall(...) to create some SwiftData items while the second step uses a TaskGroup to go through the created elements, checks if an image is needed, and syncs it. Before this worked great as the first part finished and saved before the second part happened. Now it doesn't see the save and thus doesn't see the insertions/edits/etc in the first part so the second part just isn't done properly. Those step one changes are set and shown in the UI so, in this case, if I run it again the second part works just fine on those previous items while any newly created items are skipped. I came across this issue when step one handled 74 inserts as each one didn't contain an image attached to it. When I switched the async let _ = await methodCall(...) to a TaskGroup, hoping that would wait better and work properly, I had the same issue but now only 10 to 30 items were created from the first step. Minimal Viable Example: to reproduce something similar In my minimal viable sample I simplified it way down so you can't run it twice and it's limited it creating 15 subitems. That said, I've hooked it up with both an async let _ = await methodCall(...) dubbed AL and a TaskGroup dubbed TG. With both types my second process (incrementing the number associated with the subissue/subitem) isn't run as it doesn't see the subitem as having been created and, when run with TaskGroup, only 12 to 15 items are created rather that the always 15 of async let. Code shared here: https://gist.github.com/SimplyKyra/aeee2d43689d907d7a66805ce4bbf072 And this gives a macOS view of showing each time the button is pressed the sub issues created never increment to 1 while, when using TaskGroup, 15 isn't guaranteed to be created and remembered. I'm essentially wondering if anyone else has this issue and if so have you figured out how to solve it? Thanks

Hi, when using CKSynEgine it is the responsibility of the app to implement CKSyncEngineDelegate. One of the methods of CKSyncEngineDelegate is nextFetchChangesOptions. The implementation of this method should return a batch of CKRecords so that CKSyncEngine can do the syncing whenever it thinks it should sync. A simple implementation might look like this: func nextRecordZoneChangeBatch( _ context: CKSyncEngine.SendChangesContext, syncEngine: CKSyncEngine) async -> CKSyncEngine.RecordZoneChangeBatch?{ await CKSyncEngine.RecordZoneChangeBatch(pendingChanges: syncEngine.state.pendingRecordZoneChanges) { recordID in // here we should fetch to local representation of the value and map it to a CKRecord } } The problem I am having is as follows: If the CKRecords I am returning in a batch have dependencies between each other (using CKRecord.Reference or the parent property) but are not part of the same batch, the operation could fail. And as far as I understand, there is no way to prevent this situation because: A: The batch I can return is limited in size. If the number of CKRecords is too large, I have to split them into multiple batches. B: Splitting them is arbitrary, since I only have the recordID at this point, and there is no way to know about the dependencies between them just by looking at the recordID. So basically my question is: how should the implementation of nextRecordZoneChangeBatch look like to handle dependencies between CKRecords?

iOS 18.2, Swift, Xcode 16.2 I have a Core Data model with two entities - WarehouseArea (of which there is only one object) and StockReeipt (of which there are a couple of hundred thousand). Each StockReceipt must be linked to a WarehouseArea, and a WarehouseArea can be linked to zero, one or many StockReceipts. My problem is that when I create and add one more StockReceipt, the Core Data save takes over 3 seconds to complete. I don't understand why this is so slow. Saving the initial 200,000 StockReceipts only takes 5-6 seconds. When I enable SQL logging I can see that when the WarehouseArea attribute is being set on a StockReceipt, Core Data fetches all of the other StockReceipts (I don't know why) but that only takes 0.2 seconds and none of those StockReceipts are modified, so there shouldn't be any need to process them when saving the context. I have prepared a test project which can be found at https://github.com/DaleReilly/CoreDataSaveTester . Running the project will produce NSLog output showing the times before and after the slow save. Please help me understand what is going on in the background and tell me if there is any way I can speed this up?

I'm using NSPersistentCloudKitContainer to sync CoreData to CloudKit public database but I have the problem that canUpdateRecord always returns true even for objects created by another iCloud user with _icloud role permission set to Read only. Am I missing something?

Hi, Before the iOS 17.2 update the saving behavior of SwiftData was very straightforward, by default it saves to persistence storage and can be configured to save in memory only. Now it saves to memory by default and to make it save to persistence storage we need to use modelContext.Save(). But if we don't quit the App the changes will be saved after a while to persistence storage even without running modelContext.Save() ! How confusing can that be for both developer and the user ! Am I missing something here ? -- Kind Regards

I'm working through the Develop In Swift tutorial at page [https://developer.apple.com/tutorials/develop-in-swift/navigation-editing-and-relationships-conclusion)] The tutorial has a one to many relationship between Friend and Movie (each friend can have at most one favorite movie and each movie can be the favorite for zero or more friends). An exercise left to the student is to use an .onDelete on the movie detail page to delete that movie as favorite. I modified the Form Form { TextField("Movie title", text: $movie.title) DatePicker("Release date", selection: $movie.releaseDate, displayedComponents: .date) if !movie.favoritedBy.isEmpty { Section("Favorited by") { ForEach(sortedFriends) { friend in Text(friend.name) } .onDelete(perform: deleteFavorites(indexes:)) } } } by adding the .onDelete clause I added private func deleteFavorites(indexes: IndexSet) { for index in indexes { context.delete(movie.favoritedBy[index]) } } to the view. This does delete the favorite movie, but it also deletes the friend. My assumption is that the selected friend should then have no favorite movie rather than being deleted There is an if in the Form that doesn't display the FAVORITED BY section if no friend has that movie as a favorite, but if I delete all the friends who had this movie as a favorite, the section remains (but is empty), until I exit the MovieDetail view and reload it There is no answer for these exercises, so I could be doing it wrong. EDIT: If I delete a movie using the app function to delete a movie, friends that have that movie as a favorite are not deleted and have their favorite movie set to None

I am trying to read and write a text file from an App written in Swift in XCode directly to the "iCloud Drive" folder in Files on the iPhone. The app worked readlly reading and writing to the Documents folder in the App container, and then readily to the "On My iPhone" folder in Files after adding 2 lines to the plist that I found in a search online. But I have been unable to get to the iCloud Drive folder. I found an item called "Enabling Document Storage in iCloud Drive" in "iCloud Design Guide" with additional plist entries that states "These settings allow iCloud Drive to provide public access to the files stored in your app’s container": NSUbiquitousContainers iCloud.com.example.MyApp NSUbiquitousContainerIsDocumentScopePublic NSUbiquitousContainerSupportedFolderLevels Any NSUbiquitousContainerName MyApp I think I changed the MyApp items appropriately. I have enabled iCloud in my App and the XCode General, and Signing entries. But this does not work. There are no error messages and no "Steps" shown in the "Capabilities" entry in Xcode. A little help? :-)

I got a preview crash info as this: *** crashed due to fatalError in PersistentModel.swift at line 559. This KeyPath does not appear to relate RecordInfo to anything - \RecordInfo.<computed 0x00000001921dfb4e (Array<SomeInfo>)> If I change preview device to iPhoneSE, It is no crash. I think the reason is I have some dirty data in iPhone16 Pro preview device. If I'm right and how to delete it? Model of RecordInfo like this: @Model class RecordInfo { @Relationship(deleteRule: .cascade) var someInfo:[SomeInfo] } @Model class SomeInfo { var date: Date var info: String }

I'm sorta baffled right now. I am trying to wonder how I might detect a updated SQL Store in an older app. have a baseline app, and create a SQL-based repository in an updated app, change the model and verify that you can see the updated model version. Using lightweight migration re-run the older app (which will inherit the newer SQL repository). YIKES - no error when creating the NSPersistenStoreCoordinator! Nothing in the metadata to imply the store is newer than the model: [_persistentStoreCoordinator metadataForPersistentStore:store] My question: is there any way to detect this condition? David

Dear Apple Developer Forum As the title suggests, I have an issue with Swift Data when I want to modify a property of a recursive model class instance. Please consider the following sample project: import SwiftUI import SwiftData @main struct ISSUEApp: App { var sharedModelContainer: ModelContainer = { let schema = Schema([ Item.self, ]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: true) do { return try ModelContainer(for: schema, configurations: [modelConfiguration]) } catch { fatalError("Could not create ModelContainer: \(error)") } }() var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) } } @Model final class Item { var name: String? var parent: Item? init(name: String?, parent: Item?) { self.name = name self.parent = parent } } struct ContentView: View { @Environment(\.modelContext) private var context @Query private var items: [Item] @State private var itemToMove: Item? @State private var count: Int = 0 @State private var presentMoveView: Bool = false var body: some View { NavigationStack() { List(items, id: \.id) {item in Button(action: { itemToMove = item }, label: { Text("Id: \(item.name ?? "ERROR") and my parent iD is \(item.parent?.name ?? "root")") .bold(itemToMove == item) .italic(itemToMove == item) }) } .sheet(isPresented: $presentMoveView, content: { MoveView(toMove: self.itemToMove!) }) .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button(action: { let i = Item(name: "\(count)", parent: nil) context.insert(i) try? context.save() count += 1 }, label: { Text("Add an item") }) } ToolbarItem(placement: .navigationBarLeading) { Button(action: { presentMoveView.toggle() }, label: { Text("Move selected item") }) } } } } } struct MoveView: View { @Environment(\.modelContext) private var modelContext @Environment(\.dismiss) private var dismiss @Query private var items: [Item] @Bindable var toMove: Item @State private var selectedFutureParent: Item? var body: some View { NavigationStack(){ List(items, id: \.id) {item in Button(action: { selectedFutureParent = item }, label: { Text("Id: \(item.name ?? "ERROR") and my parent iD is \(item.parent?.name ?? "root")") .bold(selectedFutureParent == item) .italic(selectedFutureParent == item) }) } .toolbar(){ ToolbarItem{ Button("Move", action: { toMove.parent = selectedFutureParent dismiss() }) } } } } } #Preview { ContentView() .modelContainer(for: Item.self, inMemory: true) } Please launch the preview of this app, add items (as many as you'd like), select one and click on the "Move selected item" button. Select the new parent of the item. As you may have noticed, both selected items (moved item and new parent) are modified, whereas only one equality is used. This issue seems to be independent from the @Bindable property wrapper. I tried many things, such as using index instead of direct elements; using local let constant for the parent but the constant is still modified (very weird...) Thank you in advance for your help ! Best regards