“SwiftData inheritance relationship”

This looks like it's fixed in iOS 26 Beta 1. If you use the extension workaround above you get a warning Conformance of 'Schema.Version' to protocol 'Sendable' was already stated in the type's module 'SwiftData' 'Schema.Version' declares conformance to protocol 'Sendable' here (SwiftData.Schema.Version)

[quote='843518022, brian-bcny, /thread/787469?answerId=843518022#843518022, /profile/brian-bcny'] I feel like I'm talking to a legend! [/quote] Yeah, I just wish I had better answers for you )-: Let’s start with the VM side of this. There’s been a bit of back’n’forth about using restricted entitlements in a VM. If you’re curious, I just updated this thread with a short history and the less-than-ideal current state of affairs. However, for the sake of this discussion let’s assume that’s been sorted out. Assuming that fix, the next roadblock is this: [quote='843518022, brian-bcny, /thread/787469?answerId=843518022#843518022, /profile/brian-bcny'] a fresh VM with a new UDID we'd easily blow through the registered device limits in the developer portal in no time [/quote] Indeed. There are a bunch of potential pitfalls here. There might be a way to skirt around them but I’d like to clarify one point with you. We only support macOS virtualisation on Mac hardware. Are you planning to run your own hardware? Or are yo

If you set the Default Actor Isolation to MainActor, which is the default value of a new project after Swift 6.2, the compiler will assume that your code runs on the main actor, unless you say otherwise. In the case you described, where your SwiftData models can run in a model actor (@ModelActor), you should explicitly annotate the model classes with nonisolated, as shown below: @Model nonisolated class MyCoolModel { var timestamp: Date ... } A model actor is an actor that has its own model context, and so you can use it as a normal actor, and mark its functions with nonisolated, if needed: @ModelActor actor MyTestModelActor { func updateTimestamp(identifier: PersistentIdentifier) throws { guard let model = modelContext.model(for: identifier) as? MyCoolModel else { return } model.timestamp = Date() try modelContext.save() } nonisolated func doSomethingNonisolated(...) {...} } Best, —— Ziqiao Chen  Worldwide Developer Relations.

The PersistentIdentifier is basically an abstraction over the DB primary key, it's a Struct consisting of the storeId, the entity name, and the primary key. You can normally use PersistentIdentifiers in SwiftData predicates, so you can do { post in post.persistentModelID == aModelIdIAmLookingFor } I cannot use the Category directly in the predicate, since it is an Optional. SwiftData predicates have problems comparing Optionals, such things only tend to work if you provide a default value before the comparison, e.g. (optionalString ?? ) == someNonOptionalString. After some debugging, I have discovered that what is causing the issue, is not the PersistentIdentifier itself, but the if-let clause with the PersistentIdentifier. Thus, performing the optional binding with Category instead of the PersistentIdentifier makes it work: if let cat = $0.category { return categoryIds.contains(cat.persistentModelID) }

The error message indicates that your model uses a non-codable type, which is not allowed in SwiftData, but if that is the case, your code shouldn't work in the previous system versions. It's hard to say anything more than that without looking into your schema. If you can provide a minimal project that contains only the relevant code, with detailed steps to reproduce the issue, I'll be happy to take a closer look. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for that. I asked over in the privacy/security section of the forums and the verdict seems to be that these types of properties don't get inherited because that's not how it works. However I was given the suggestion to possibly change the Java executable's Info.plist instead, although trying this didn't seem to successfully get Game Mode to activate (tested on macOS 15.5 (24F74)), unfortunately. (Is that expected behavior?) So looks like this won't work, as you thought. Though it is strange that Game Mode does work with apps like the Minecraft official launcher which use this architecture, which seems to imply there is some way this is done. I can't find a code-level way to implement this, but I do see that: If the launcher app is opened from Steam and then the launcher app opens the Java game, then fullscreening the Java game does activate Game Mode. So seems like children of Steam have some kind of special handling, though I'm not sure if that's the doing of Steam or the OS. If you change an

[quote='787774021, kthchew, /thread/787774, /profile/kthchew'] Can child processes inherit Info.plist properties of a parent app … ? [/quote] No. Info.plist properties are set in one of two ways: If the code is bundled, there’s an Info.plist file in that bundle. For a standalone executable, you can embed an Info.plist in the __TEXT / __info_plist section of the executable. Unlike entitlements, these properties are not directly tied to the process. Rather, some code in the system has to consult the properties. This is common done from within the process — code in a system framework gets the current processe’s bundle and fetches properties from that — but it can also be done from outside. Given that design, there’s no inheritance. If you want something to be effective, you have set it on that program’s Info.plist. And that makes the Java thing tricky because you don’t control it’s Info.plist. Having said that, Java isn’t built in to the system, so you could potentially build your own copy with

Since we are only configuring only 1 zone and the objective is to delete every record, would using modifyRecordZones(saving:deleting:) to simply delete the zone then start our app from the beginning have the same outcome ... That will work, if there is no synchronization activity happens in between the deletions of the local data and the remote data, which you can probably achieve by releasing the model container immediately after deleting the local data. But again, SwiftData doesn't expose any CloudKit thing, and so I am not quite sure if that is a guarantee. (and be more Swifty?) The APIs I mentioned have the Swift version. It seems that the documentation is broken, and so I can only find the links to the objective C version. Best, —— Ziqiao Chen  Worldwide Developer Relations.

SwiftData + CloudKit doesn't expose any CloudKit data structure, and so you will need to purge the data with your own code. Given that today's SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, I'd consider the following flow: Set up an NSPersistentCloudKitContainer instance and use it to load the SwiftData store. Fetch an object from the store, and retrieve the CloudKit record ID using recordIDForManagedObjectID:. From there, you can grab the record's zoneID. Call purgeObjectsAndRecordsInZoneWithID:inPersistentStore:completion: with the record zone ID to purge the local and remote data. Release all the Core Data objects. With that, you should be able to get an empty store, use it to set up a new SwiftData model container, and start your app from the beginning. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I have encountered this error before, but not with my new setup, but it’s possible that your new related models have not been saved to the store yet and SwiftData is enforcing constraints back to the ModelContext when it doesn’t exist in the store.