“SwiftData inheritance relationship”

The model appears to have not pasted correctly, I used the code block. So here it is again. import SwiftData //Model one: type of contract, i.e. Firm Fixed Price, etc @Model final class TypeOfContract { var contracts: [Contract] @Attribute(.unique) var typeName: String @Attribute(.unique) var typeCode: String var typeDescription: String init(contracts: [Contract], typeName: String = , typeCode: String = , typeDescription: String = ) { self.contracts = contracts self.typeName = typeName self.typeCode = typeCode self.typeDescription = typeDescription } } //Model two: the Contract @Model final class Contract { var contractType: TypeOfContract? var costReports: [CostReport] @Attribute(.unique) var contractNumber: String @Attribute(.unique) var contractName: String var startDate: Date var endDate: Date var contractValue: Decimal var contractCompany: String var contractContact: String var contactEmail: String var contactPhone: String var contractNotes: String init(contractType: TypeOfContract? = nil, costR

Intel · macOS 15.6 (two machines): FDA toggle for our app-bundled daemon flips Off (immediately or after leaving the pane). OK, that makes things clearer. This kind of thing happens because something failed during the grant process and the UI reset to the existing state. A few things to look at: First off, this isn't actually about your daemon. There isn't any special marker that differentiates daemons from other apps. Whatever is failing is tied to your app bundle, NOT the fact you're a daemon. Reproduce the issue, capture a sysdiagnose, then go see what happened. Anytime the system does something like this, it would have logged. Create a basic sample app unrelated to your existing and grant it FDA. When it appears On, the daemon still behaves as if FDA isn’t granted. I suspect it wasn't granted and the UI lagged in some way. What does the UI show if you relaunch settings.app and/or reboot the machine? When you say “adopt SMAppService,” could you point me to the exact steps or a minimal example of setting th

Hi Kevin — thanks for clarifying. Current state Intel · macOS 15.6 (two machines): FDA toggle for our app-bundled daemon flips Off (immediately or after leaving the pane). When it appears On, the daemon still behaves as if FDA isn’t granted. Apple Silicon · macOS 15.6: Works. Loaded via launchctl load /Library/LaunchDaemons/... from a shell script run by another daemon. Follow-ups When you say “adopt SMAppService,” could you point me to the exact steps or a minimal example of setting this up so the daemon inherits FDA? I’m unfamiliar with the specifics you’re proposing. What’s the simplest way to enable tccd diagnostics to see why the grant is being dropped (just the key commands/flags you recommend)? If you’d like a Feedback Assistant report, what minimal artifacts make it most actionable? If you want a bug report, what would I need to include? Do you want us to try 15.7.1? Thanks!

Intel – macOS 15.6 ONLY: Broken. Have you tested this on: Multiple Intel machines. and/or A clean system reinstall, either by erasing the machine or by using a VM. Have you tested this on 15.7.1 (the current release)? Shifting to here: Is there a known Intel-only regression in 15.6 where FDA toggles for app-bundled daemons fail to persist? I'm not aware of any such issue and I'd expect a general FDA failure to cause significant problems. Having it be “Intel only is also quite odd, as everything that manages FDA state is at a high enough level of the system that the CPU architecture shouldn't matter. However, what I this is more likely is that there might be issues on a specific machine which would prevent FDA from sticking. Lastly, have you filed a bug on this and, if so, what's the bug number? Does launching the daemon immediately after install (triggered by a separate LaunchDaemon running an install.sh) interact with TCC/FDA persistence on Intel 15.6 specifically? Note inherently, though how it's launched m

Hi Kevin — thanks for the detailed reply. Quick confirmations We’re already shipping the ES daemon as an app-bundled executable (signed, hardened, notarized). FDA is being granted through System Settings → Privacy & Security → Full Disk Access to the app bundle (per your #1), not to a bare exe. ES entitlement is present; Gatekeeper/SPCTL and codesign checks are clean. What we’re actually hitting (repro matrix) Apple Silicon (M-series) – macOS 15.6: Works. FDA toggles on and persists. ES daemon runs fine at boot. Intel – macOS ≤ 15.5: Works. Intel – macOS 15.6 ONLY: Broken. In Full Disk Access, turning the toggle On either immediately flips back Off, or appears On but flips Off after navigating away and back. When it “looks” On, the ES daemon still behaves as if FDA is not granted. This behavior is consistent across multiple Intel machines and fresh user profiles. Extra notes about launch The daemon is launched by launchd (system domain) as usual. Our installer (run by another LaunchDaemon’s install.sh) re

Thanks for all the advice! I just checked in the dashboard and even there I cannot even see the schema or any record types of my SwiftData model. The only record type that exists is Users. I have already created a new container but that does not seem to make any difference. What could the reason be that not even the data model is pushed to CloudKit?

Our ES client launches and functions when started manually (terminal). FYI, this is almost certainly because you previously granted Terminal.app FDA, which your client then inherited. Terminal.app does not have any unique/privileged access to the file system. We can’t find a supported way to grant Full Disk Access (SystemPolicyAllFiles) to a system daemon on unmanaged Macs (no MDM). The supported way to do this is for the user to grant your daemon FDA through System Setting-> Privacy & Security-> Full Disk Access. You may have already tried this and found that the interface wouldn't let you select this bare executable: /Library/Application Support///Platform/ However, the direct solution to that is simply embed your daemon executable inside an app bundle, as described here. However, this would also be a great time to adopt SMAppService, which would change some of the requirements/behavior here. Covering some specifics: On macOS 14/15, is Full Disk Access for system daemons strictly MDM-only

The error happens when SwiftData tries to create a snapshot for a model and the backing data doesn't have the right type, which ... doesn't quite explain anything... What system version do you use to see the issue? Did you ever try with the current latest public release (26.0.2) and Beta (26.1 Beta 4)? If you find a reproducible case and don't mind to share, I may be able to take a closer look. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Just to add that SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the technotes my colleague mentioned apply to your topic. Specifically, you can use CloudKit Console to determine if the data is synchronized to CloudKit. From there, you can determine if the issue happens on the exporting or importing side, and go ahead to capture and analyze a sysdiagnose, as described in the Capture and analyze a sysdiagnose section. Best, —— Ziqiao Chen  Worldwide Developer Relations.

So, let me start here: Why are all logs attributed to the kernel? Because that's where the logs came from. More specifically, the os_log function you are calling in DriverKit is not the same os_log function that exists in userspace. It actually does IPC into the kernel, which then logs out through the kernel’s logging infrastructure. Why would logs from 100% user-space code like ExternalMethod and StaticPingPong be attributed to the kernel process? I think the term user-space is deeply misleading when it comes to DriverKit. While it’s true in the basic technical sense, it is DEEPLY misleading when it comes to the practical relationship a DEXT has with the rest of the system. Practically speaking, your DEXT has very little connection to the larger system. It talks the kernel through the underlying DEXT infrastructure and it talks to user space through IOUserClient. That's ALL that exists, so the direct answer is that it's logging through the kernel because that's the only way it can log. WHY it works

entity is a selector on NSManagedObject and you have smashed it with a relationship to one of your entities. That's not a valid managed object model (none of your PersistentModel classes can have a property named entity).

Yeah, that is what I mentioned above, and it's because a too-many relationship is expressed as a set (NSSet) in Core Data, which is used by SwiftData default store. I don't think the behavior is formally documented. If you don't mind, please file a feedback report. Best, —— Ziqiao Chen  Worldwide Developer Relations.