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

This is great news. I would just like to clarify one part of this. Specifically, your last statement, providing an update to my app for customers on WatchOS 9 will resolve the issue. Does this need to be built with a specific version of Xcode or the SDKs? Only because I've done an update within the past month and am still seeing the issue for WatchOS 9 users. Or is it part of one of the latest WatchOS 9.6.X updates? (Which if it is I can direct customers to it)

I did try a DTS (3791480) and never got a response after an initial further debugging email.... replied several times too and was charged for the DTS

@developer555 This is exactly what I send to my users with problems: Change the complications that are not working to different apps. Reboot your Apple Watch. Launch the <my_app> watch app. Go back to your watch face and move the complications back to the ones you want. They should now update (fingers crossed). This works about 80% of times, I'm not sure this will ever be fixed as Apple are all WidgetKit only which is silly because my WatchOS 8 & 9 users are still on ClockKit and having problems