The ReadingProgress struct on the Book model is causing it for me. Resetting development Cloudkit environment does not help. Next step for me is to install Xcode 26.0 beta 7, but I'm doubtful on that being the fix

I created a GitHub repository for the minimal project that I was testing previously. It only uses a single Book model. A simple README.md is included: Bookworm I've been resetting the CloudKit schema many times to see if that was the problem. But I still get the error logging. FYI, the sync between devices still works as expected even with the error. I just don't want to run into problems later.

I'll try updating Xcode to that beta version and try to provide a sample project I know encounters the error log when running the app. It might take some time before I can get to this. Did you wait some time to make sure the error didn't pop up? It might take a minute or two. Try inserting a record then re-running and waiting a few minutes. If you want.

im viewing from my phone I may have missed that you have a third field that you were testing. That’s what I was lhoping to test. all good. it might take some fiddling around to see the error log. Like you should insert one, relaunch the app, wait a few minutes, try again

was hoping to use this thread because this is my minimal project which is very simple with one Model. Your code in my other thread is using just a Date and Data field which I expect to work. My minimal project here is trying to get at the underlying issue: Should I ignore the error and assume Apple still supports enums and codable structs when using SwiftData with CloudKit?

I can provide a GitHub link for this simple app

Thanks, I probably will go with the Data with Transient approach. I just submitted Feedback ID: FB20097625

@DTS Engineer I was trying to make it clear that the dto was Sendable, that's okay. Does your approach assume that all LabResults are in the SwiftData store? I wanted to combine the manually entered labs (swiftdata) with HealthKit Clinical Lab results in my views like I originally stated. But maybe I should keep the HealthKit Clinical labs sync'd in swiftdata so I have a source of truth. It would just increase the complexity a little, I think

@FPST Although, I think your idea to add a service or view model layer on top would work. That way the views aren’t talking to the actor or HealthKit directly, they’re just observing whatever results that layer publishes. That would still align with @jenyalebid 's comment. So I think that would work.

@FPST Does this go against @jenyalebid comment? If I place in a separate layer or not I would still categorize that as a ModelActor populating the UI. Maybe it is fine, though?

Ok, so it's not just me. I was hoping to avoid having to repeat my code in each view that needs the combined results

After reading your post on iOS Background Execution Limits it sounds like I can't rely on BGAppRefreshTaskRequest to ensure a scheduled dose window of 2 weeks for my users. That is because "... there are common scenarios where it won’t grant you any background execution time at all!". How does Apple's Medications app ensure this 2 week window along with Local Notifications? Do they have access to an api that I don't to make it possible?

After reading your post on iOS Background Execution Limits it sounds like I can't rely on BGAppRefreshTaskRequest to ensure a scheduled dose window of 2 weeks for my users. That is because "... there are common scenarios where it won’t grant you any background execution time at all!". How does Apple's Medications app ensure this 2 week window along with Local Notifications? Do they have access to an api that I don't to make it possible?

After reading your post on iOS Background Execution Limits it sounds like I can't rely on BGAppRefreshTaskRequest to ensure a scheduled dose window of 2 weeks for my users. That is because "... there are common scenarios where it won’t grant you any background execution time at all!". How does Apple's Medications app ensure this 2 week window along with Local Notifications? Do they have access to an api that I don't to make it possible?

After reading reading your post on iOS Background Execution Limits it sounds like I can't rely on BGAppRefreshTaskRequest to update the user's dosing schedule window of 2 weeks. This is because there are "common scenarios where it won’t grant you any background execution time at all!". My question is: How does Apple Health's Medications app keep a rolling 2 week schedule window? Maybe they have access to a private api for performing more reliable background execution?