“SwiftData inheritance relationship”

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.

Indeed... The original issue, which was fixed in iOS 18.4, doesn't sort with an optional relationship. I see this crash a different issue. Do you have a feedback report yet? If not, would you mind to file one for us and share your report ID here? Thanks! Best, —— Ziqiao Chen  Worldwide Developer Relations.

That should be it. Thank you. But I urge you to re-read the canonical documentation in the headers. The difference you point out here (between PATH_TYPE_TARGET_LITERAL and PATH_TYPE_LITERAL) is not written there. The very simple distinction between the path of the executable creating the event and the path of the file which is the target of the event -- is simply not there. Yes, it could definitely be clearer on that point. It was fairly clear in the original API (when all you could block was by process), but when TARGET was added, it was documented in great detail, but we didn't go back and include a clear definition of the original constant. I just filed a bug asking for us to clarify the two roles in the enum definition comments. Having said that, this flowchart at line ~500 of ESClient.h does do a good job of describing what's going on, though it does not directly reference the specific constants involved: * The relationship between all three types of muting (proc,path,target-path) and how each c

@DTS Engineer the issue @Ches Beiner brought up is still an issue, as detailed in my post on the thread you linked to: SwiftData crash when using a @Query sort descriptor with a relationship

@DTS Engineer this is still an issue in iOS 26 when sorting on a property of an optional relationship. @Query(sort: Item.info?.endDate, order: .reverse) private var items: [Item] @Model final class Item { var info: ItemInfo? init(info: ItemInfo) { self.info = info } } @Model final class ItemInfo { var endDate: Date init(endDate: Date) { self.endDate = endDate } } SwiftData/DataUtilities.swift:85: Fatal error: Couldn't find Item.)>?.? on Item with fields [SwiftData.Schema.PropertyMetadata(name: info, keypath: Item.)>, defaultValue: nil, metadata: nil)] iOS Simulator 26.0 beta 4 (23A5297i) Xcode Version 26.0 beta 4 (17A5285i) I made a minimal fork of the project @Atletismo343 provided: https://github.com/coughski/swiftdata-crash

[quote='851343022, nkirby, /thread/795022?answerId=851343022#851343022, /profile/nkirby'] We split the application from a monolithic binary into separate GUI and daemon executables. [/quote] Oh, yeah, that makes sense now that I look back at the property lists in your first post. [quote='851343022, nkirby, /thread/795022?answerId=851343022#851343022, /profile/nkirby'] Is there a way to tell launchd about the change? [/quote] Not that I’m aware of. Just as an experiment, if you override the code signing identifier of the daemon to match that of the main app, does that fix this problem? If you’er using code, change the code signing identifier by setting the Other Code Signing Flags build setting to [ $(inherited), --identifier, org.mozilla.macos.FirefoxVPN]. IMPORTANT I see a lot of folks put a lot of weird stuff in the Other Code Signing Flags build setting. I recommend against that in general, but it is a reasonable way to override the code signing identifier in a program that has no bundle ID. Share

Did anyone have an update? I'm still facing the same issue. Not being able to do even trivial custom migrations seems like it makes SwiftData a complete non-starter.