Search results for

“SwiftData inheritance relationship”

4,980 results found

Post

Replies

Boosts

Views

Activity

Present User an error message when SwiftData save fails
Have a data model that sets certain fields as unique. If the user attempts to save a duplicate value, the save fails quietly with no indication to the user that the save failed. The program is on Mac OS 26.0.1 @Environment(.modelContext) var modelContext @Query private var typeOfContracts: [TypeOfContract] @State private var typeName: String = @State private var typeCode: String = @State private var typeDescription: String = @State private var contracts: [Contract] = [] @State private var errorMessage: String? = Data Entered @State private var showAlert: Bool = false var body: some View { Form { Text(Enter New Contract Type) .font(.largeTitle) .foregroundStyle(Color(.green)) .multilineTextAlignment(.center) TextField(Contract Type Name, text: $typeName) .frame(width: 800, height: 40) TextField(Contract Type Code, text: $typeCode) .frame(width: 800, height: 40) Text(Contract Type Description) TextEditor(text: $typeDescription) .frame(width: 800, height: 200) .scrollContentBackground(.hidden) .background(Col
10
0
311
Oct ’25
Reply to BGContinuedProcessingTask what's the point?
So, let me start by jumping to the immediate point here: This initial sync is rare from a user perspective. Some may never have initial syncs that will take 2-3 minutes. Question is: 2-3 minutes outside the use case for this new feature? No, not at all. We can't guarantee any specific time, but there isn't any artificial throttle on timing and, theoretically, a task could run for an hour+ under the right circumstances. On an idle device as you're describing, 2-3 min. should have been fine. The next step here is to figure out what duet logged when we expired the task. Huh. How long does it take to expire once you enter the background? What does the > console log show (particularly from duet) when your task is expired? It can be a few minutes. I haven't timed it. OK. So the key here is that it's long enough that the processing task is keeping your app alive, at least some of the time. As background context, what's the work you're actually doing? I'm curious to why this would make a difference. It is running
Oct ’25
Reply to BGContinuedProcessingTask what's the point?
Huh. How long does it take to expire once you enter the background? What does the console log show (particularly from duet) when your task is expired? It can be a few minutes. I haven't time it. As background context, what's the work you're actually doing? I'm curious to why this would make a difference. It is running a long initial sync of data loading data into CoreData from a server. It almost always dies when trying to load relationships into CoreData. We are talking about 7000 plus relationship connections. How fast is that progress in real-world terms? A minute or two. How long does it take to process one item? A fraction of a second, I don't have exact times. How often are you updating progress? Many times a second. if you reduce the work such that you make rapid progress, both in terms of how long you take to complete and how frequently you report progress? I can't reduce how long it takes to update CoreData, On an initial sync, it's all or nothing; otherwise data will be corrupted.
Oct ’25
Picker using SwiftData
I am attempting to impliment a a Picker that uses SwiftData to fill in the choices. I am missing something because I can get the picker to appear with the proper selections but the picker does not register my choice (no check mark appears and the text in the picker window is blank after I move to the next field. The model import Foundation 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 contra
3
0
193
Oct ’25
Reply to Picker using SwiftData
The selection parameter for the picker should be a single item and not an array @State private var contractType: TypeOfContract = // some default type also the type of the value passed to .tag() must be the same type as the property above. So this issue is not so much about SwiftData but instead understanding how a picker works.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Oct ’25
Reply to Picker using SwiftData
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
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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!
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’25
SwiftData and CloudKit not synching between devices
Hi, Not sure how to describe my issue best: I am using SwiftData and CloudKit to store my data. In the past, when I tested my app on different devices, the data would sync between the devices automatically. For whatever reason this has stopped now and the data no longer syncs. No matter what I do, it feels as if all the data is actually stored just locally on each device. How can I check if the data is actually stored in the cloud and what could be reasons, why its no longer synching between my devices (and yes, I am logged in with the same Apple ID on all devices). Thanks for any hint! Max
6
0
243
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’25
SwiftData: Unexpected backing data for snapshot creation
When deleting a SwiftData entity, I sometimes encounter the following error in a document based SwiftUI app: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData The deletion happens in a SwiftUI View and the code used to retrieve the entity is standard (the ModelContext is injected from the @Environment): let myEntity = modelContext.model(for: entityIdToDelete) modelContext.delete(myEntity) Unfortunately, I haven't yet managed to isolate this any further in order to come up with a reproducible PoC. Could you give me further information about what this error means?
3
0
255
Oct ’25
Reply to SwiftData: Unexpected backing data for snapshot creation
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.
Oct ’25
Present User an error message when SwiftData save fails
Have a data model that sets certain fields as unique. If the user attempts to save a duplicate value, the save fails quietly with no indication to the user that the save failed. The program is on Mac OS 26.0.1 @Environment(.modelContext) var modelContext @Query private var typeOfContracts: [TypeOfContract] @State private var typeName: String = @State private var typeCode: String = @State private var typeDescription: String = @State private var contracts: [Contract] = [] @State private var errorMessage: String? = Data Entered @State private var showAlert: Bool = false var body: some View { Form { Text(Enter New Contract Type) .font(.largeTitle) .foregroundStyle(Color(.green)) .multilineTextAlignment(.center) TextField(Contract Type Name, text: $typeName) .frame(width: 800, height: 40) TextField(Contract Type Code, text: $typeCode) .frame(width: 800, height: 40) Text(Contract Type Description) TextEditor(text: $typeDescription) .frame(width: 800, height: 200) .scrollContentBackground(.hidden) .background(Col
Replies
10
Boosts
0
Views
311
Activity
Oct ’25
Reply to BGContinuedProcessingTask what's the point?
So, let me start by jumping to the immediate point here: This initial sync is rare from a user perspective. Some may never have initial syncs that will take 2-3 minutes. Question is: 2-3 minutes outside the use case for this new feature? No, not at all. We can't guarantee any specific time, but there isn't any artificial throttle on timing and, theoretically, a task could run for an hour+ under the right circumstances. On an idle device as you're describing, 2-3 min. should have been fine. The next step here is to figure out what duet logged when we expired the task. Huh. How long does it take to expire once you enter the background? What does the > console log show (particularly from duet) when your task is expired? It can be a few minutes. I haven't timed it. OK. So the key here is that it's long enough that the processing task is keeping your app alive, at least some of the time. As background context, what's the work you're actually doing? I'm curious to why this would make a difference. It is running
Replies
Boosts
Views
Activity
Oct ’25
Reply to BGContinuedProcessingTask what's the point?
Huh. How long does it take to expire once you enter the background? What does the console log show (particularly from duet) when your task is expired? It can be a few minutes. I haven't time it. As background context, what's the work you're actually doing? I'm curious to why this would make a difference. It is running a long initial sync of data loading data into CoreData from a server. It almost always dies when trying to load relationships into CoreData. We are talking about 7000 plus relationship connections. How fast is that progress in real-world terms? A minute or two. How long does it take to process one item? A fraction of a second, I don't have exact times. How often are you updating progress? Many times a second. if you reduce the work such that you make rapid progress, both in terms of how long you take to complete and how frequently you report progress? I can't reduce how long it takes to update CoreData, On an initial sync, it's all or nothing; otherwise data will be corrupted.
Replies
Boosts
Views
Activity
Oct ’25
Picker using SwiftData
I am attempting to impliment a a Picker that uses SwiftData to fill in the choices. I am missing something because I can get the picker to appear with the proper selections but the picker does not register my choice (no check mark appears and the text in the picker window is blank after I move to the next field. The model import Foundation 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 contra
Replies
3
Boosts
0
Views
193
Activity
Oct ’25
Reply to Picker using SwiftData
The selection parameter for the picker should be a single item and not an array @State private var contractType: TypeOfContract = // some default type also the type of the value passed to .tag() must be the same type as the property above. So this issue is not so much about SwiftData but instead understanding how a picker works.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Oct ’25
Reply to Picker using SwiftData
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
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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!
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Oct ’25
SwiftData and CloudKit not synching between devices
Hi, Not sure how to describe my issue best: I am using SwiftData and CloudKit to store my data. In the past, when I tested my app on different devices, the data would sync between the devices automatically. For whatever reason this has stopped now and the data no longer syncs. No matter what I do, it feels as if all the data is actually stored just locally on each device. How can I check if the data is actually stored in the cloud and what could be reasons, why its no longer synching between my devices (and yes, I am logged in with the same Apple ID on all devices). Thanks for any hint! Max
Replies
6
Boosts
0
Views
243
Activity
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Oct ’25
Reply to SwiftData and CloudKit not synching between devices
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?
Replies
Boosts
Views
Activity
Oct ’25
Reply to macOS 15 (Sequoia): Endpoint Security client runs by hand, but LaunchDaemon fails with TCC “Full Disk Access” denial on unmanaged Macs
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
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Oct ’25
SwiftData: Unexpected backing data for snapshot creation
When deleting a SwiftData entity, I sometimes encounter the following error in a document based SwiftUI app: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData The deletion happens in a SwiftUI View and the code used to retrieve the entity is standard (the ModelContext is injected from the @Environment): let myEntity = modelContext.model(for: entityIdToDelete) modelContext.delete(myEntity) Unfortunately, I haven't yet managed to isolate this any further in order to come up with a reproducible PoC. Could you give me further information about what this error means?
Replies
3
Boosts
0
Views
255
Activity
Oct ’25
Reply to SwiftData: Unexpected backing data for snapshot creation
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.
Replies
Boosts
Views
Activity
Oct ’25