“SwiftData inheritance relationship”

This topic is discussed in the following technote section: Avoid synchronizing a store with multiple persistent containers. The technote is about NSPersistentCloudKitContainer. As of today, SwiftData (DefaultStore) + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the content applies. Basically, the use case of sharing a CloudKit-back store between a main app and its extension and synchronizing with NSPersistentCloudKitContainer isn't quite supported, and so you might consider avoiding do that. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for the suggestion. 1 cent is not valueless when someone has nothing! This is my first venture into implementing dynamic member lookup. I'm at the stage where I believe I understand it – until I have to explain it, at which point I realise I really have no idea. Your suggestion gave me a momentary epiphany about a possible solution, so tried to understand the code better. At this stage, I'm thinking it still won't achieve my goal – having the compiler behave as though the method had been inherited by the subclasses, including auto-complete. FYI Following @DTS Engineer Quinn's suggestion, I've reposted the question at swift.org, but essentially given up on the approach I was hoping for. Having said that, your comment still feels worth exploring to see how far I can get.

Hello @Jir_253, Thanks for your questions. I’d recommend that you start by watching Set the scene with SwiftUI in visionOS from this year’s WWDC. Your “CWindow” sounds similar to the Tools window covered in this talk: WindowGroup(Tools, id: tools) { ToolsView() } .restorationBehavior(.disabled) .defaultLaunchBehavior(.suppressed) Similar to iOS where you cannot quit the application yourself, you cannot dismiss the last window of your application. When a user goes to close the main window when the secondary window is open, you cannot close this secondary window if it’s the only window group that is open in your application. Consider adding an affordance to the secondary window to reopen the main window in this case. There's no supported way for you to create parent/child window relationships with the APIs currently available. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number

Interesting thanks for that. If that is the case the log is indeed misleading and their might be something else that caused the performance issues we had with relationships. As we currently see a significant improvement compared to our initial implementation.

Indeed. I looked more closely into the SQLite debug log: CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZID, t0.ZSOMEPROPERTY, t0.ZSOMEPROPERTY2 FROM ZITEM t0 CoreData: annotation: sql connection fetch time: 0.0001s CoreData: annotation: total fetch execution time: 0.0002s for 4 rows. CoreData: sql: SELECT 0, t0.Z_PK FROM ZITEM1TO2LINK t0 WHERE t0.ZITEM = ? CoreData: annotation: sql connection fetch time: 0.0001s CoreData: annotation: total fetch execution time: 0.0001s for 4 rows. CoreData: annotation: to-many relationship fault itemLinks for objectID 0x904a44aa77e3d40d fulfilled from database. Got 4 rows ... The SQL to fetch the itemLinks relationship (SELECT 0, t0.Z_PK FROM ZITEM1TO2LINK t0 WHERE t0.ZITEM = ? ) is basically only for the primary key, and so I won't expect that has a significant performance impact. Best, —— Ziqiao Chen  Worldwide Developer Relations.

The log lines are actually misleading, it is NOT faulting in the related Models but gathering the related PersistentIdentifiers to use when the relationship is traversed.

Thanks for the replay. I did not create a feedback report yet but will create one. For now we moved away from relationships as this was having a big performance impact with our quite large data set. Instead our entities only store IDs of related entities. This prevents any loading of all the related entities, but adds a bit of manual work to handle the lazy loading.

There are two parts to questions like this: What’s technically feasible? What’s required by App Review? I don’t work for App Review, so I can’t offer definitive advice on their policies. I recommend that you review their published guidelines. I’m happy to wade into technical questions. And on that front, you wrote: [quote='795751021, maarten1987, /thread/795751, /profile/maarten1987'] I can not run this in sandbox mode. [/quote] Why not? In general, sandboxed apps are allowed to: Play and record audio Have embedded helper executables Spawn child processes Given that, I can’t see any fundamental reason why this won’t work. So I recommend that you dig further into the failure, because that’s likely to be a lot more fun than the alternatives. Note It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. [quote='852254022, Tomato, /thread/795751?answerId=852254022#852254022, /profile/Tomato'] you can have your users download the command-line tool

Could be the same issue. I tried reporting this directly to Apple with a request for Technical Assistance because I hadn't seen any other reports of this behavior. I had developed a SwiftData app that used CloudKit and therefore required all model relationships to be treated as optional. I was sorting an object using a relationship's title field (which was clearly optional) and this worked fine in all simulator and Xcode downloads with no issues. I didn't run into it until I tried using TestFlight to get some beta feedback and the app immediately crashed and the feedback was sparse so I took several months to finally track down what was causing it. I would certainly like to see this fixed because it creates limitations that only surface very late ih the app dev process which is very frustrating. If it shouldn't ever work then it should also crash in the simulator and any Xcode downloads IMHO.

Are you using the system-provided NSTextView, or are you writing your own custom text view using TextKit2? I've tested both during my investigation: Custom text view - inherits NSView & using TextKit2: I'm able to reproduce the issue mentioned above (Xcode 16.4 - macOS 15.6) Custom text view - inherits NSTextView & using TextKit2: I'm able to reproduce the issue mentioned above (Xcode 16.4 - macOS 15.6) System-provided NSTextView: OK (Xcode 16.4 - macOS 15.6) It really seems to be because of what value is returned by : enumerateTextLayoutFragments(from: documentRange.endLocation, options: [.reverse, .ensuresLayout]) { layoutFragment in ... layoutFragment.layoutFragmentFrame.maxY ... } For your own custom text view, you should be able to fix the issue by adjusting the viewport. This post provides a code snippet for that purpose. Please see if that helps. Yes indeed, I read this post and I can make a workaround with (OR without adjusting the viewport by ensuring a layout at appropriate

Just noticed that I hadn't responded this post. Sorry for that ... I tried the sample project (thanks to @dasdasda) and reproduced the issue on iOS 26 (Beta 4) – fetching Item indeed fetches its itemLinks relationship, even though the relationship is not accessed. Do you have a feedback report yet? If not, I’d suggest that you file one and share your report ID here. (I can file a report as well, but you represent the developer community. As an originator, you can get notified of the status change and follow up with it if that matters to you.) Best, —— Ziqiao Chen  Worldwide Developer Relations.