“SwiftData inheritance relationship”

SwiftData + CloudKit integration uses NSPersistentCloutKitContainer under the hood, and it is intentional that the framework deletes the local data when the user turns off iCloud for the app in Settings. The behavior is discussed in this post. Feel free to follow up here with further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.

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