“SwiftData inheritance relationship”

The reason actually is because SwiftData doesn't support using TabView .init(selection:content:) with .tabItem. Instead, use TabView .init(content:) with Tab.

Bump. We need at least some guidance on this topic. Should we avoid codable structs in SwiftData models if trying to integrate with CloudKit? Maybe a flat structure for the data in the Models is the solution. But we have no idea

Hi, Thank you for the clarification request. You are correct in your assumption. 1. Daemon Clarification We are using the term daemon in the general sense of a persistent background helper process, not a system-wide launchd daemon (it is not registered in /Library/LaunchDaemons or managed by SMAppService). 2. Child Process (Python) Launch The Python process is launched directly as a child process of the main Swift application. As detailed in the Python Daemon Launch section of our document, we are using Swift's high-level Process API (which, as you noted, is layered on top of technologies like posix_spawn). The specific code used is: let process = Process() process.executableURL = URL(fileURLWithPath: pythonExecutablePath) // path is AthenaSentry.app/Contents/Helpers/AthenaSentry.app/Contents/MacOS/AthenaSentry process.environment = /* ... */ try process.run() 3. Parent Process (Swift) Launch The parent process is the main Swift wrapper application, AthenaSentry.app (Bundle ID com.athena.AthenaSentry). It is

Thank you! You raise a good point with regard to scoping an activity across suspension points. os_activity_scope_{enter,leave} likely requires being called on the same thread even if the activity is automatically propagated across threads inside the scope. For non-detached Tasks this is simple as I can scope/apply the activity around the synchronous creation of the Task and the activity will be carried into the task automatically. Inside an async context I would probably need to ensure that I'm entering and leaving the scope on the same thread and even then it would likely break if that thread is used to run other work in the meantime. Hopefully we get Swift-native and Swift Concurrency compatible support for creating OS activities at some point, because they already work very well once created. They are even correctly propagated across custom non-GCD based TaskExecutors from what I can see. Restricting my use to non-detached Tasks is fine for now though, they are much more frequent than detached ones anyway.

When using SwiftData, I typically consider the following pattern: Start with accessing the data store from the main actor (MainActor) and with mainContext. Use @Query to gather data that will be rendered in a SwiftUI view. That way, the query controller under the hood observes changes on the data store, and updates the view, as discussed in this post. When you have a heavy task that should be done in a background queue, create a ModelActor with your app's shared model container, and do the task with the isolated modelContext. Use a Sendable data type to exchange data between the model actor (step 3) and the main actor. A SwiftData model is not Sendable, but the model's persistentModelID is, and so can be passed across actors. With this pattern, light tasks run in the main actor; heavy tasks run in a model actor and use Sendable types to exchange data across actors; @Query observes the changes on the data store and updates the UI. No race condition will happen. The only issue is that you may

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

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.

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.