“SwiftData inheritance relationship”

In CloudKit development environment, when your app creates a record, CloudKit automatically creates the record type, if it doesn’t exist. With that, if you ever persist (at least) an instance for each of your SwiftData type, and the instance is pushed to CloudKit, the CloudKit schema will have the record type for you. Otherwise, the record type will be missed. initializeCloudKitSchema(options:) works by creating a set of representative records, uploading them to CloudKit, and removing them. This may help if it is indeed that no instance of your new SwiftData type has ever been uploaded to CloudKit. Note that even initializeCloudKitSchema(options:) can miss something, and that is why I called out the following: After running the target, use CloudKit Console to ensure each Core Data entity and attribute has a CloudKit counterpart. See Reading CloudKit Records for Core Data for the mapping rules. The documentation discusses how NSPersistentCloudKitContainer maps a Core Data model to a CloudKi

I'm having the same issue, any updates on this? data: { type: subscriptionPromotionalOffers, attributes: { name: Tier2 50% off, offerCode: appoffTest01, duration: ONE_WEEK, offerMode: PAY_AS_YOU_GO, numberOfPeriods: 1 }, relationships: { subscription: { data: { type: subscriptions, id: 6751863227 } }, prices: { data: [ { type: subscriptionPromotionalOfferPrices, id: 1701cff0-c38d-4460-9845-43601292edbd } ] } } }, included: [ { type: subscriptionPromotionalOfferPrices, id: 1701cff0-c38d-4460-9845-43601292edbd, relationships: { subscriptionPricePoint: { data: { type: subscriptionPricePoints, id: eyJzIjoiNjc1MTg2MzIyNyIsInQiOiJBRkciLCJwIjoiMTAxMzIifQ } } } } ] } errors: [ { id: 659be9c5-3a02-4a78-bf51-e40bf5c96138, status: 409, code: ENTITY_ERROR.INCLUDED.INVALID_ID, title: The provided entity id is invalid, detail: The provided included entity id '1701cff0-c38d-4460-9845-43601292edbd' has invalid format, source: { pointer: /included/0/id } } ] }

You mentioned that the new model isn't listed as an indes. Does that mean your new model type does not show up as part of the CloudKit schema (and hence CloudKit Console sees no changes between your development and production schemas )? If yes, that will be the culprit – The framework will stop synchronizing data when detecting that the CloudKit schema doesn't match your SwiftData models. When changing your SwiftData model types, be sure that the change is pushed to the CloudKit development environment, which is eventually promoted to the production environment. How to push your change to the CloudKit development environment is described in Initialize the CloudKit development schema. The details in Create the CloudKit schema may help as well. Best, —— Ziqiao Chen  Worldwide Developer Relations.

BUT - I'm also not sure it isn't just developer error on my part. As top-level advice, take a look at the Trails sample app, as it does implement the App Intents StartWorkoutIntent and related APIs, so that you have a reference implementation to consult for what is possible on iOS and watchOS. Currently the StartWorkoutIntent only serves the Action button on the Watch Ultra. It cannot be used to register Shortcuts, nor does Siri respond to it. StartWorkoutIntent is available on iOS, and the sample above demonstrates that. As to using it with Siri, the sample is configured with that intent as an App Shortcut, so it is available through Siri. I can use objects inherited from AppIntent to create shortcuts, but this requires an additional permission to run a shortcut if a user starts a workout with Siri. Depending on a variety of factors controller by the system, a customer can sometimes be prompted for permission to run an intent. That is broadly true, and not specific to anything about workout intents

FB19957253 (Crash on Hierarchical List children access from SwiftData inherited model) Again, thank you so much! I hope I gave enough informations, feel free to ask if I can do anything.

That's most likely a bug happening when creating a hierarchical list using List(… children) + SwiftData. Would you mind to file a feedback report for us with your reproducible case, and share your report ID here? Thanks. Best, —— Ziqiao Chen  Worldwide Developer Relations.

It's probably related to whatever you are doing with adguard and vaultwarden. I don't know what any of that is, but when I search for your domain, it shows up on a couple of Github domain lists. I also don't know what those domain lists are for. But if you're going to play around with anything even remotely related to security, you should do that on a burner site. Otherwise, you effectively turn your site into a burner site. There is no differentiation on the internet between legal/illegal, safe or malicious. It's the internet. It's all illegal and malicious, unless proven otherwise. Google and others work hard to hide that from regular folks. But if you fall through the cracks, even by accident, it's your problem to solve. Nobody's going to help. This is a developer support forum. It's a place for questions about SwiftUI, APIs, NSURLSession, etc. You can ask anything you want, but if you're asking about something that isn't developer related, you probably won't get any answer. I can tell you that there is no

Even though this doesn’t provide a direct solution for cross-device real-time database persistence, it may simulate the behavior you’re looking for. If both devices are on the same network, you can leverage the MultipeerConnectivity framework to send data to other devices immediately and then persist it locally. This way you can achieve a “live update” experience within the Apple ecosystem, while still using SwiftData for storage.

The original post had been a year ago, and had run out of my radar since then, until this new post brought this back, thanks to @jenyalebid. If simply creating a SwiftData model container with CloudKit integration, which kicks off the initialization of NSPersistentCloudKitContainer under the hood, causes the hang, I'd suggest that you start with filing an actionable feedback report, because the initialization is not supposed to be a long task. SwiftData + CloudKit integration is based on NSPersistentCloudKitContainer, and so folks can follow the tips described in the following technote to analyze if there is anything goes wrong in the initialization phase: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer If somebody can share a minimal project, with detailed steps, that reproduces the issue, I'd be able to take a look as well. The orignal post does contain a link, but it has been a year, and I am not sure if the issue is the same. Best, —— Ziqiao Chen  Worldwide De

I don't have a lot to say about implementing a real-time data persistence system cross devices, but just to confirm that CloudKit isn't a real-time system, and so SwiftData / Core Data + CloudKit integration is not real time either, as you have found out. To optimize the overall experience, CloudKit even implemented a mechanism to throttle requests, if the rate is too high, as discussed in TN3162: Understanding CloudKit throttles. And yes, a custom data store will be the way to go, if you would use SwiftData. You need to take care the real-time synchronization part when going along this path. There is no system-provided framework specifically for that purpose. Best, —— Ziqiao Chen  Worldwide Developer Relations.