Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great. The problem: Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups. When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one. Could not cast value of type 'Swift.Optional<Any>' (0x20a676be0) to 'Swift.Array<App.CodableStructModel>' (0x207a2bc08). Where CodableStructModel is a Codable Value type inside Item. Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is "supported" by SwiftData by default, meaning that the developer has to actively either wholly opt out of undo support in their modelContainer setup or do it on a per action scale with the only thing I know of: modelContext.processPendingChanges() modelContext.undoManager?.disableUndoRegistration() ..... modelContext.processPendingChanges() modelContext.undoManager?.enableUndoRegistration() General rant on SwiftData: Random crashes, inconsistencies, random cryptic errors thrown by the debugger and general lack of production level stability. Each update breaks something new and there is very little guidance and communication from the Swift Data team on how to adapt and more importantly consideration for developers that have adopted Swift Data. If SwiftData is not ready for production, it would go a long way to clearly communicate that and mark it as Beta product.

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

I have made a Swift App for MacOS 15 under XCode 16.3, which runs fine. I also want to run it under the previous MacOS 14. Unfortunately it crashes without even starting up (it does not even reach the first log output statement on the first view) The crash reason is Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [2970] I have set the miminium deployment to MacOS 14.0 but to no effect. The XCode machine is a MacOS 15.4 on Arm M3 and the target machine is MacOS 14.7.5 on Intel (MacBook Air) I think it might be related to the compiler and linker settings.

Testing Environment: iOS 18.4.1 / macOS 15.4.1 I am working on an iOS project that aims to utilize the user's iCloud Drive documents directory to save a specific directory-based file structure. Essentially, the app would create a root directory where the user chooses in iCloud Drive, then it would populate user generated files in various levels of nested directories. I have been attempting to use NSMetadataQuery with various predicates and search scopes but haven't been able to get it to directly monitor changes to files or directories that are not in the root directory. Instead, it only monitors files or directories in the root directory, and any changes in a subdirectory are considered an update to the direct children of the root directory. Example iCloud Drive Documents (Not app's ubiquity container) User Created Root Directory (Being monitored) File A Directory A File B An insertion or deletion within Directory A would only return a notification with userInfo containing data for NSMetadataQueryUpdateChangedItemsKey relating to Directory A, and not the file or directory itself that was inserted or deleted. (Query results array also only contain the direct children.) I have tried all combinations of these search scopes and predicates with no luck: query.searchScopes = [ rootDirectoryURL, NSMetadataQueryUbiquitousDocumentsScope, NSMetadataQueryAccessibleUbiquitousExternalDocumentsScope, ] NSPredicate(value: true) NSPredicate(format: "%K LIKE '*.md'", NSMetadataItemFSNameKey) NSPredicate(format: "%K BEGINSWITH %@", NSMetadataItemPathKey, url.path(percentEncoded: false)) I do see these warnings in the console upon starting my query: [CRIT] UNREACHABLE: failed to get container URL for com.apple.CloudDocs [ERROR] couldn't fetch remote operation IDs: NSError: Cocoa 257 "The file couldn’t be opened because you don’t have permission to view it." "Error returned from daemon: Error Domain=com.apple.accounts Code=7 "(null)"" But I am not sure what to make of that, since it does act normally for finding updates in the root directory. Hopefully this isn't a limitation of the API, as the only alternative I could think of would be to have multiple queries running for each nested directory that I needed updates for.

When I used to do Migrations, I always used ETL and then push to a dev system to review/test before going production. The migration support is SwiftData is fine for a little tweak. I might as well just just use new schema and context and write the custom code than use the SwiftData migration support.

I have started from here: Apple's guide on the sharing core data objects between iCloud users and I have created a sample project that has Collections and Items. Everything works great while I stay on Swift 5, like with the initial project. I would like to migrate to Swift 6 (Default Actor Isolaton @MainActor, Approachable Concurrency: Yes) on the project and I am stuck at extension CDCollection: Transferable { ... }. When compiling with Swift 5, there is a warning: Conformance of 'NSManagedObject' to 'Sendable' is unavailable in iOS; this is an error in the Swift 6 language mode. After resolving almost all compile-time warnings I'm left with: Conformance of 'CDCollection' to protocol 'Transferable' crosses into main actor-isolated code and can cause data races. Which I don't think will work, because of the warning shown above. It can be worked around like: nonisolated extension CDCollection: Transferable, @unchecked Sendable Then there are errors: let persistentContainer = PersistenceController.shared.persistentContainer Main actor-isolated static property 'shared' can not be referenced from a nonisolated context. I've created the following class to have a Sendable object: struct CDCollectionTransferable: Transferable { var objectID: NSManagedObjectID var persistentContainer: NSPersistentCloudKitContainer public static var transferRepresentation: some TransferRepresentation { CKShareTransferRepresentation { collectionToExport in let persistentContainer = collectionToExport.persistentContainer let ckContainer = CloudKitProvider.container var collectionShare: CKShare? if let shareSet = try? persistentContainer.fetchShares( matching: [collectionToExport.objectID]), let (_, share) = shareSet.first { collectionShare = share } /** Return the existing share if the collection already has a share. */ if let share = collectionShare { return .existing(share, container: ckContainer) } /** Otherwise, create a new share for the collection and return it. Use uriRepresentation of the object in the Sendable closure. */ let collectionURI = collectionToExport.objectID .uriRepresentation() return .prepareShare(container: ckContainer) { let collection = await persistentContainer.viewContext .perform { let coordinator = persistentContainer.viewContext .persistentStoreCoordinator guard let objectID = coordinator?.managedObjectID( forURIRepresentation: collectionURI ) else { fatalError( "Failed to return the managed objectID for: \(collectionURI)." ) } return persistentContainer.viewContext.object( with: objectID ) } let (_, share, _) = try await persistentContainer.share( [collection], to: nil ) return share } } } } And I'm able to compile and run the app with this change: let transferable = CDCollectionTransferable( objectID: collection.objectID, persistentContainer: PersistenceController.shared .persistentContainer ) ToolbarItem { ShareLink( item: transferable, preview: SharePreview("Share \(collection.name)!") ) { MenuButtonLabel( title: "New Share", systemImage: "square.and.arrow.up" ) } } The app crashes when launched with libdispatch.dylib`_dispatch_assert_queue_fail: 0x1052c6ea4 <+0>: sub sp, sp, #0x50 0x1052c6ea8 <+4>: stp x20, x19, [sp, #0x30] 0x1052c6eac <+8>: stp x29, x30, [sp, #0x40] 0x1052c6eb0 <+12>: add x29, sp, #0x40 0x1052c6eb4 <+16>: adrp x8, 63 0x1052c6eb8 <+20>: add x8, x8, #0xa0c ; "not " 0x1052c6ebc <+24>: adrp x9, 62 0x1052c6ec0 <+28>: add x9, x9, #0x1e5 ; "" 0x1052c6ec4 <+32>: stur xzr, [x29, #-0x18] 0x1052c6ec8 <+36>: cmp w1, #0x0 0x1052c6ecc <+40>: csel x8, x9, x8, ne 0x1052c6ed0 <+44>: ldr x10, [x0, #0x48] 0x1052c6ed4 <+48>: cmp x10, #0x0 0x1052c6ed8 <+52>: csel x9, x9, x10, eq 0x1052c6edc <+56>: stp x9, x0, [sp, #0x10] 0x1052c6ee0 <+60>: adrp x9, 63 0x1052c6ee4 <+64>: add x9, x9, #0x9db ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: " 0x1052c6ee8 <+68>: stp x9, x8, [sp] 0x1052c6eec <+72>: adrp x1, 63 0x1052c6ef0 <+76>: add x1, x1, #0x9a6 ; "%sBlock was %sexpected to execute on queue [%s (%p)]" 0x1052c6ef4 <+80>: sub x0, x29, #0x18 0x1052c6ef8 <+84>: bl 0x105301b18 ; symbol stub for: asprintf 0x1052c6efc <+88>: ldur x19, [x29, #-0x18] 0x1052c6f00 <+92>: str x19, [sp] 0x1052c6f04 <+96>: adrp x0, 63 0x1052c6f08 <+100>: add x0, x0, #0xa11 ; "%s" 0x1052c6f0c <+104>: bl 0x1052f9ef8 ; _dispatch_log 0x1052c6f10 <+108>: adrp x8, 95 0x1052c6f14 <+112>: str x19, [x8, #0x1f0] -> 0x1052c6f18 <+116>: brk #0x1 The app still crashes when I comment this code, and all Core Data related warnings. I'm quite stuck now as I want to use Swift 6. Has anyone figured CloudKit, CoreData and Swift 6 for sharing between users?

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

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

I have several macOS applications that use CloudKit. I need to test and finds out what happens when the user signs out of their iCloud account. That's because the application may lose data after signing out and then signing in again. Every time I do that, it'll take 15, 20 minutes... I don't time it, but it takes quite a gigantic time to sign out as the spinner keeps rolling. Why does it take so long to just sign out? This sign out effect is untestable because it takes a long time to sign out of an iCloud account and then make changes to the code and then test again. In case you need to know, my system version is Sequoia 15.7.

I am working on a software where we want to add the feature to share the whole database with the other user. Database is iCloud combined with coredata. The other user(s) should be able to edit /delete and even create new objects in the share. I did this with this code witch directly from sample code let participants = try await ckConainer.fetchParticipants(matching: [lookupInfo], into: selectedStore) for participant in participants { participant.permission = .readWrite participant.role = .privateUser share.addParticipant(participant) } try await ckConainer.persistUpdatedShare(share, in: selectedStore) the other user gets invited and I can see this in iCloud database that the other user is invited with status invited. but the other user never gets a mail or something to accept and join the share. How does the other needs to accept the invitation ?

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

My client is using iCloud Mail with his custom domain and he communicated with many govt organizations which seem to all be using Barracuda Email Protection for their spam prevention. I have properly configured his SPF, DKIM & DMARC DNS records however his emails were still being rejected. (Email header below) I contacted Barracuda support with the email header and they replied saying that the emails were rejected becuase Apple Mail has missing PTR records. I have sent dozens of emails for testing and looking at all their headers I can see (ms-asmtp-me-k8s.p00.prod.me.com [17.57.154.37]) which does not have a PTR record. ----FULL EMAIL HEADER WITH 3RD PARTY DOMAINS REMOVED----- <recipient_email_address>: host d329469a.ess.barracudanetworks.com[209.222.82.255] said: 550 permanent failure for one or more recipients (recipient_email_address:blocked) (in reply to end of DATA command) Reporting-MTA: dns; p00-icloudmta-asmtp-us-west-3a-100-percent-10.p00-icloudmta-asmtp-vip.icloud-mail-production.svc.kube.us-west-3a.k8s.cloud.apple.com X-Postfix-Queue-ID: 8979C18013F8 X-Postfix-Sender: rfc822; sender_email_address Arrival-Date: Thu, 20 Mar 2025 12:30:05 +0000 (UTC) Final-Recipient: rfc822; @****** Original-Recipient: rfc822;recipient_email_address Action: failed Status: 5.0.0 Remote-MTA: dns; d329469a.ess.barracudanetworks.com Diagnostic-Code: smtp; 550 permanent failure for one or more recipients (recipient_email_address:blocked) Return-Path: <sender_email_address> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sender_domain; s=sig1; bh=CyUt/U7mIHwXB5OQctPjRH/OxLH7GsLR54JjGuRkj9Y=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To:x-icloud-hme; b=hwEbggsctiCRlMlEgovBTjB/0sPRCb2k+1wzHRZ2dZNrZdOqvFSNWU+Aki9Bl8nfv eEOoXz5qWxO2b2rEBl08lmRQ3hCyroayIn4keBRrgkxL1uu4zMTaDUHyau2vVnzC3h ZmwQtQxiu7QvTS/Sp8jjJ/niOPSzlfhphqMxnQAZi/jmJGcZPadT8K+7+PhRllVnI+ TElJarN1ORQu+CaPGhEs9/F7AIcjJNemnVg1cude7EUuO9va8ou49oFExWTLt7YSMl s+88hxxGu3GugD3eBnitzVo7s7/O9qkIbDUjk3w04/p/VOJ+35Mvi+v/zB9brpYwC1 B4dZP+AhwJDYA== Received: from smtpclient.apple (ms-asmtp-me-k8s.p00.prod.me.com [17.57.154.37]) by p00-icloudmta-asmtp-us-west-3a-100-percent-10.p00-icloudmta-asmtp-vip.icloud-mail-production.svc.kube.us-west-3a.k8s.cloud.apple.com (Postfix) with ESMTPSA id 8979C18013F8; Thu, 20 Mar 2025 12:30:05 +0000 (UTC) From: Marcel Brunel <sender_email_address> Message-Id: <2E8D69EA-FCA6-4F5D-9D42-22A955C073F6@sender_domain> Content-Type: multipart/alternative; boundary="Apple-Mail=_F9AC7D29-8520-4B25-9362-950CB20ADEC5" Mime-Version: 1.0 (Mac OS X Mail 16.0 (3826.400.131.1.6)) Subject: Re: [EXTERNAL] - Re: Brunel - 2024 taxes Date: Thu, 20 Mar 2025 07:29:27 -0500 In-Reply-To: <SA0PR18MB350300DE7274C018F66EEA24F2D82@SA0PR18MB3503_namprd18_prod_outlook_com> To: Troy Womack <recipient_email_address> References: <SA0PR18MB350314D0B88E283C5C8E1BB6F2DE2@SA0PR18MB3503_namprd18_prod_outlook_com> <9B337A3E-D373-48C5-816F-C1884BDA6F42@sender_domain> <SA0PR18MB350341A7172E8632D018A910F2D82@SA0PR18MB3503_namprd18_prod_outlook_com> <SA0PR18MB350300DE7274C018F66EEA24F2D82@SA0PR18MB3503_namprd18_prod_outlook_com> X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Proofpoint-ORIG-GUID: uqebp2OIbPqBr3dYsAxdFVkCNbM5Cxyl X-Proofpoint-GUID: uqebp2OIbPqBr3dYsAxdFVkCNbM5Cxyl X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1093,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-03-20_03,2025-03-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1030 suspectscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2503200077

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

I have the following struct doing some simple tasks, running a network request and then saving items to Core Data. Per Xcode 26's new default settings (onisolated(nonsending) & defaultIsolation set to MainActor), the struct and its functions run on the main actor, which works fine and I can even safely omit the context.perform call because of it, which is great. struct DataHandler { func importGames(withIDs ids: [Int]) async throws { ... let context = PersistenceController.shared.container.viewContext for game in games { let newGame = GYGame(context: context) newGame.id = UUID() } try context.save() } } Now, I want to run this in a background thread to increase performance and responsiveness. So I followed this session (https://developer.apple.com/videos/play/wwdc2025/270) and believe the solution is to mark the struct as nonisolated and the function itself as @concurrent. The function now works on a background thread, but I receive a crash: _dispatch_assert_queue_fail. This happens whether I wrap the Core Data calls with context.perform or not. Alongside that I get a few new warnings which I have no idea how to work around. So, what am I doing wrong here? What's the correct way to solve this simple use case with Swift 6's new concurrency stuff and the default main actor isolation in Xcode 26? Curiously enough, when setting onisolated(nonsending) to false & defaultIsolation to non isolating, mimicking the previous behavior, the function works without crashing. nonisolated struct DataHandler { @concurrent func importGames(withIDs ids: [Int]) async throws { ... let context = await PersistenceController.shared.container.newBackgroundContext() for game in games { let newGame = GYGame(context: context) newGame.id = UUID() // Main actor-isolated property 'id' can not be mutated from a nonisolated context; this is an error in the Swift 6 language mode } try context.save() } }

Hello, I recently published an app that uses Swift Data as its primary data storage. The app uses concurrency, background threads, async await, and BLE communication. Sadly, I see my app incurs many fringe crashes, involving EXC_BAD_ACCESS, KERN_INVALID_ADDRESS, EXC_BREAKPOINT, etc. I followed these guidelines: One ModelContainer that is stored as a global variable and used throughout. ModelContexts are created separately for each task, changes are saved manually, and models are not passed around. Threads with different ModelContexts might manipulate and/or read the same data simultaneously. I was under the impression this meets the usage requirements. I suspect perhaps the issue lies in my usage of contexts in a single await function, that might be paused and resumed on a different thread (although same execution path). Is that the case? If so, how should SwiftData be used in async scopes? Is there anything else particularly wrong in my approach?

Hi everyone, Im trying to set up CloudKit for my Unreal Engine 5.4 project but seem to be hitting some roadblocks on how to set up the Record Types. From my understanding I need to set up a "file" record type with a "contents" asset field - but even with this it doesn't seem to work :( Any unreal engine devs with some experience on this who could help me out? Thanks!

I'm implementing SwiftData with inheritance in an app. I have an Entity class with a property name. This class is inherited by two other classes: Store and Person. The Entity model has a one-to-many relationship with a Transaction class. I can list all my Entity models in a List with a @Query annotation without a problem. However, then I try to access the name property of an Entity from a Transaction relationship, the app crashes with the following error: Thread 1: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x96530ce28d41eb63 <x-coredata://DABFF7BB-C412-474E-AD50-A1F30AC6DBE9/Person/p4>))) with Optional(F07E7E23-F8F0-4CC0-B282-270B5EDDC7F3) From my attempts to fix the issue, I noticed that: The crash seems related to the relationships with classes that has inherit from another class, since it only happens there. When I create new data, I can usually access it without any problem. The crash mostly happens after reloading the app. This error has been mentioned on the forum (for example here), but in a context not related with inheritance. You can find the full code here. For reference, my models looks like this: @Model class Transaction { @Attribute(.unique) var id: String var name: String var date: Date var amount: Double var entity: Entity? var store: Store? { entity as? Store } var person: Person? { entity as? Person } init( id: String = UUID().uuidString, name: String, amount: Double, date: Date = .now, entity: Entity? = nil, ) { self.id = id self.name = name self.amount = amount self.date = date self.entity = entity } } @Model class Entity: Identifiable { @Attribute(.preserveValueOnDeletion) var name: String var lastUsedAt: Date @Relationship(deleteRule: .cascade, inverse: \Transaction.entity) var operations: [Transaction] init( name: String, lastUsedAt: Date = .now, operations: [Transaction] = [], ) { self.name = name self.lastUsedAt = lastUsedAt self.operations = operations } } @available(iOS 26, *) @Model class Store: Entity { @Attribute(.unique) var id: String var locations: [Location] init( id: String = UUID().uuidString, name: String, lastUsedAt: Date = .now, locations: [Location] = [], operations: [Transaction] = [] ) { self.locations = locations self.id = id super.init(name: name, lastUsedAt: lastUsedAt, operations: operations) } } In order to reproduce the error: Run the app in the simulator. Click the + button to create a new transaction. Relaunch the app, then click on any transaction. The app crashes when it tries to read te name property while building the details view.

I built a SwiftData App that relies on CloudKit to synchronize data across devices. That means all model relationships must be expressed as Optional. That’s fine, but there is a limitation in using Optional’s in SwiftData SortDescriptors (Crashes App) That means I can’t apply a SortDescriptor to ModelA using some property value in ModelB (even if ModelB must exist) I tried using a computed property in ModelA that referred to the property in ModelB, BUT THIS DOESN”T WORK EITHER! Am I stuck storing redundant data In ModelA just to sort ModelA as I would like???

Since running on iOS 14b1, I'm getting this in my log (I have Core Data logging enabled): error: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store at 'file:///private/var/mobile/Containers/Shared/AppGroup/415B75A6-92C3-45FE-BE13-7D48D35909AF/StoreFile.sqlite' As far as I can tell, it's impossible to open my store without that key set - it's in the init() of my NSPersistentContainer subclass, before anyone calls it to load stores. Any ideas?