“SwiftData inheritance relationship”

Just to confirm that @Attribute(.preserveValueOnDeletion) doesn't preserve relationships. It only works for attributes. Given that, I don't see anything in the SwiftData history that can help restore a relationship between two SwiftData objects after they are deleted. Best, —— Ziqiao Chen  Worldwide Developer Relations.

First, I wanted to apologize for not replying for a full month, as well as thank you very much for your reply. I was pulled away from this project for a couple weeks, and when I got back I was still spinning my wheels getting the driver installed. Not a problem at all. It was 67 characters and, apparently the maximum is 63. Seems like an arbitrarily short max in this day and age, and you'd think both XCode and the Developer Portal would catch that, but that's what it was. Sigh... I'm sorry I didn't think of that, as I'm aware of that limitation and actually posted about it here. FYI, you should also be aware of the version number limitation described here, which is another arbitrary restriction the kernel enforces. So, on to my current problem. The driver installs... but doesn't load. Probably because it's not matching. So I'm going to give more detailed information in the hope you can help me with this. If you haven't seen it already, I have a post here that does an extended run down of the matching and load

For a large dataset, the initial synchronization with CloudKit, which can happen in several cases, including on-boarding a new device, can indeed be slow, or even failed. A similar issue was discussed in this thread as well. Depending on your concrete use case, you might address the issue in the following way: Have your app functional before the dataset is fully synchronized. Synchronize the data in batches in the background, until the whole data set is done. As an example, an email app that is just installed on a new device allows users to compose a new email, while synchronizing existing emails in the background. When using the CloudKit framework, you control what kind and amount of data to be synchronized with CloudKit, and hence can implement the strategy, though the implementation can be quite involved. Now that you are using SwiftData + CloudKit integration, NSPersistentCloudKitContainer takes care the synchronization process. I don't really see anything to work around or mitigate the issue in

Same problem for me !!!! use SwiftData, build great apps and POC… Then when you'll need sharing rewrite everything with coredata (that you may not mastered). As an independent developer it is really a pain. At least If I was sure that the sharing feature is schedule!

The run loop itself doesn't actually turn at a predictable rate. Depending on how your app is architected and the overall app state, it's entirely possible for an app to go seconds or even minutes without the main thread ever running. Doesn't appear to be what's going on in this case. I made this dumb little test which can easily reproduce the issue (sorry can't get code to format well on these forums). +(MachoManURLTester*)sharedTester { static MachoManURLTester *sharedTester = nil; static dispatch_once_t token; dispatch_once(&token,^{ sharedTester = [[self alloc]init]; }); return sharedTester; } -(void)startURLTrashDance { NSAssert(NSThread.currentThread.isMainThread, @Main thread only.); NSFileManager *fm = [NSFileManager defaultManager]; NSURL *wrapperDir = [[NSURL fileURLWithPath:NSTemporaryDirectory() isDirectory:YES] URLByAppendingPathComponent:NSUUID.UUID.UUIDString isDirectory:YES]; if (![fm createDirectoryAtURL:wrapperDir withIntermediateDirectories:YES attributes:nil error:nil]) { NSLog(@Test f

The error message most likely happened because you changed the class name so the current SwiftData schema was different from what the existing store had used, as discussed here. I don't think that is the root cause of your issue. What catches my eyes is that you commented out the modelContext.save(). SwiftData supports auto-save, and yet, auto-save happens periodically. If you stop running your app before auto-save happens, the data will not be persisted. Other than that, I don't see any obvious issue in your code snippets. If you can share a runnable code that reproduces the issue, I may take another look. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Unrelated perhaps but why are you even using SwiftData for this, wouldn't it be better to use a CSV (or JSON) file for persisting your data? Maybe I am misreading the code but to me it looks like you only want to store a single instance of your model and then I believe SwiftData or any other database solution is overkill and that a simple file is more suitable.

I'm writing to express my frustration and disbelief that this critical bug is still present in production as of 2026. We just completed a major refactoring effort, migrating our application from iCloud-based static file storage to SwiftData with CloudKit sync. During this migration, we encountered this exact issue and was stunned to discover it was already documented in 2024. Here one of several specific scenarios: Logbook view structure: @Bindable var logbook: Logbook (where Logbook is a @Model class) The logbook.flights relationship array is not observed - changes to the array don't trigger view updates Attempted workaround using @Query var flights: [Flight] - still not observed This affects one of our primary user-facing views (flight logbook table) Why the suggested workaround doesn't work: The proposed solution of triggering refreshes on modelContext.didSave notifications is impractical for real-world applications: • Context saves can occur multiple times throughout the app's lifecycle

There is a WebDriver incubation effort ongoing with a standards proposal to be utilized in Web Platform Tests: https://github.com/WICG/aom/issues/203 https://github.com/web-platform-tests/wpt/pull/55784 Current test implementation PRs of the above are in Firefox/Gecko and Safari/WebKit, with interest indicated from the Chromium dev teams at Google/Chrome and Microsoft/Edge. There's a upcoming CSUN session about the above standards effort scheduled for 4:20 PM Pacific on Wednesday March 11. https://conference.csun.at/event/2026/session-schedule You can also review the WebKit Web Inspector, under Node > Accessibility to get parent/child relationships... https://webkit.org/blog/3302/aria-and-accessibility-inspector/ I do not recall if the WebKit Inspector JSON protocol used for those relationships is documented thoroughly anywhere, but the open source implementation pointer is: AccessibilityProperties in JavaScriptCore/inspector/protocol /DOM.json. https://github.com/WebKit/WebKit/blob/9602f

When the query has a filter, SwiftData currently doesn't have a way to determine if the predicate changes every time AddTestStageView.init is called (because Predicate is not Equatable), and so assumes a re-fetch. To avoid the potential performance issue, you can probably consider re-designing your SwiftUI view hierarchy so the change of TextField doesn't trigger AddTestStageView.init, if that change is not relevant to the view. I’d also suggest that you file a feedback report – If you do so, please share your report ID here. Best, —— Ziqiao Chen  Worldwide Developer Relations.