“SwiftData inheritance relationship”

Thank you @DTS Engineer , this is what the rest of the enum cases, and its computed properties, look like: enum FilterItem: Hashable { case work(isSelected: Bool) case family(isSelected: Bool) case health(isSelected: Bool) case social(isSelected: Bool) case energetic(isSelected: Bool) case tired(isSelected: Bool) case restless(isSelected: Bool) case heavy(isSelected: Bool) case numb(isSelected: Bool) case calm(isSelected: Bool) case tense(isSelected: Bool) case light(isSelected: Bool) case racing(isSelected: Bool) case focused(isSelected: Bool) case confused(isSelected: Bool) case overthinking(isSelected: Bool) case blank(isSelected: Bool) case reflective(isSelected: Bool) case head(isSelected: Bool) case neck(isSelected: Bool) case chest(isSelected: Bool) case shoulders(isSelected: Bool) case arms(isSelected: Bool) case solarPlexus(isSelected: Bool) case stomach(isSelected: Bool) case lowerAbdomen(isSelected: Bool) case legs(isSelected: Bool) case wholeBody(isSelected: Bool) var filterName: String { switch s

Check out the talk for SwiftData to get some insight on when you should harness Class Inheritance: https://developer.apple.com/videos/play/wwdc2025/291/ As for the depth and width of your Model Graph, it really depends on the full Schema and how the data is partitioned for the particular use cases.

In SwiftData, there are local changes and remote changes. Local changes are made from the same model container (ModelContainer); remote changes are made from a different model container. This is covered in the WWDC25 session: SwiftData: Dive into inheritance and schema migration (starting at 13:54). Your main app and its widget use different model containers (because they run in a different process). For your main app, a change made from your widget is remote, and isn't observable. If a view in your main app observes a SwiftData model, or a result set that you fetch from a SwiftData store, it won't get updated for any remote change. If you use @Query, however, the query controller under the hood observes the remote changes, and so a query-back SwiftUI view is supposed to get updated for a remote change. This is clearly described in the mentioned WWDC25 session. If you see otherwise, I’d suggest that you file a feedback report with a reproducible case, and share you

For the moment I recommend that you hold on on trying to use QUIC with the new Network framework API that we introduced at WWDC 2025. The relationship between that API and multiplexed protocols is still evolving. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Don't mind me, just necro'ing an old thread. I'm running into this issue as well, and followed the same advice of omit the @Relationship macro from the child item and (of course) it resolves the compiler errors, but is this manual setting of the parent relationship intended? It's clearly not the best developer experience.

If Getting into visionOS and metal for creating games - Is there any tips or optimal apis/framework/tools that you would recommend? Easiest way to start on visionOS is with RealityKit. The GameController framework supports lots of controllers for different types of games. 200GB of Background Assets available for content rich games. Are there standard methods of achieving synchronization of state between players (specifically using VisionOS here) or is it a roll-your-own situation? For synchronizing objects in a Shared spatial environment, consider using TableTopKit, which is compatible with GKMatch in the GameKit framework. If you’re using RealityKit, you can use SynchronizationService to coordinate shared physically simulated objects. We also recommend the WWDC session: Share visionOS experiences with nearby people. Which official Metal docs or sample projects best support teams moving a CPU-centric CAD kernel to GPU-accelerated workflows on Apple Silicon The Performing Calculations on a GPU sample code show

@Jerome_Donfack There are two main requirements to use transformer in SwiftData: The type returned by transformedValueClass needs to correspond to the type you declare in the model, so it needs to be changed to NSArray.self transformedValue can only be encoded as NSData, and in CoreData, we can encode into any supported type, such as NSNumber, NSString Override class func transformedValueClass() -> AnyClass { Return NSArray.self // change to NSArray } BTW: If it is not to be compatible with your other custom data, SwiftData will use the built-in transaformer to encode [String] without using transformable