Thank you for the suggestions. Will file feedback for now. I think the MeshGradient route it too far from the Charts API I'm otherwise working with. The other suggestions would work but would create stepped data and not a smooth view. One for enhancement I think.

Thank you, good to know this is the problem and not my code! Hopefully it makes it's way to the Xcode beta release notes

I've had no updates in my bug report if that's what you're asking! ... and the issue still persists.

In your example, if I wrap scrollPosition in a withAnimation: Button("Set to 0") { scrollPosition = 0 } Button("Set to 0") { withAnimation { scrollPosition = 0 }} It has no effect. Is there a reason for this? I'm trying to animate scroll position in my chart? Thanks

Ok 😕 I have about 10 new feedbacks opened from WWDC24 and none of them have responses. Although if they still get looked at and fixed I don't mind 😊

Sure, feedback filed! IT's FB14049876. Thank you

Unfortunately I think this will not result in an experience the user is happy with. Essentially they will see the situation as "My widget is disappearing" and will assume (correctly!) that I've done something to break it. Some users may not even remember which widget they had from my app, only that it was there and then it wasn't.... So I really think a migration path is needed.

I second @codingLawyer comments that HRV sensor data from Apple Watch is really insufficient to have significant meaning in current WatchOS versions. It really needs to be much higher such as it is with the AFib History either by default or by user toggle. It's also an interesting omission that HRV is not included in the new WatchOS 11 Vitals app.... If this is all part of plans to bring such a feature to a new Apple Watch model and wrap it up in a stress tracking feature.... blink twice

In the ChartView I then just have the input declared: let value:[Model] ------- In your case where "Model" is the data type. For me its let value:[Double]

Same query here 🙋‍♂️

Understand. It's a little frustrating though as it still seems like the only supported Settings link takes the user to the app Settings, to access anything else they then have to go back, scroll up the top and then select the relevant menu. Unless you can think of a specific security or privacy benefit for this behaviour? I'll file a feedback anyway just in case 👍

🙏 This worked for me, Thank You! (I didn't need interactivity so can't comment on that)

@edford @Gong Just another update from me. With Xcode 15.3 and submitting an app update for all users I'm still seeing hundreds or even thousands of the same crash for users on WatchOS 9.6.3 I really don't believe this issue has been fixed, is there anything else that can be done to get this looked at. I've updated the feedback

Does this apply to "complications" on the watch face that use WidgetKit? This is all not clearly documented IMHO.

Did you get any further with this? I've had various issues implementing the privacySensitive behaviour. Cheers