Thank you for the further information. It's good to know there's no specific availability clause I could have otherwise added. Regarding your comment: "Situations like this are exceedingly rare".... Apple increasingly likes withholding a few features from the annual iOS X.0 betas over the summer and then adding them in for RC candidates. (Who doesn't love a surprise!) This can also happen for iOS X.X releases if It coincides with a new feature from a product launch. Over the years with the existence of public betas there is greater percentage of users running beta OS versions. At the same time most major OS updates in beta through the summer have added additional beta branches (iOS 16, 17 & 18 have all added X.1 betas before X.0 was released). Beta users will blame third party apps for crashes that occur even in the post example where it's really to do with their OS "branch" for lack of a better term. Going forward it seems we do need a better way to check this availability in Swift or Apple needs to work to align beta updates of OS X.X to OS X.X+1 if that makes sense.... Otherwise this problem will reoccur with seemingly no way to avoid it. On this specific example, it's not fixed in iOS 18.1 Beta 4 or Xcode 16.1 Beta 2, but I haven't filed a feedback as it's almost impossible for it not to be fixed pre-release, many apps including the Health app would break if it wasn't.

Apologies, this isn't really that helpful but I've never seen this issue and I do a lot of developing with Swift Chart on WatchOS 9, 10 and 11. The only vaguely similar thing I've seen before was an issue when trying to render a SwiftUI chart as an image when it had the .chartXSelection API set for interaction. Otherwise, I'd just have a look if there's anything else fairly unique you're doing with the chart. Maybe posting some of it's code could help.

Unfortunately I'm 99% sure there's currently no API to detect this. I can only suggest filing feedback.

I've confirmed with an Apple DTS Engineer this is likely a bug. The workaround is to remove the healthkit value set for UIRequiredDeviceCapabililties in my Info.plist, hopefully this helps someone! I've since been able to update my app. Many thanks to @edford for helping here I've filed feedback FB14780645 to try and get this fixed for other users one day!

One thought comes to mind which I've seen a similar issue on when using Swift Charts in a TabView. You could try setting the .id() modifier on the chart maybe with the date of the day the chart is displaying. For myself this resolved an issue where I has a Swift Chart (actually showing Health data) for each day and the wrong days were displayed sometimes when scrolling through the TabView. Hope this helps, apologies if it doesn't!

Are you referring to data measured by Apple Watch? If so then my understanding (as of iOS 17 & WatchOS 10) is: Apple Watch records the users Heart Rate roughly every 4-6 minutes throughout the day when on the users wrist and not in low power mode These Heart Rate readings go to 10’s per minute during a Workout Apple Watch only generates one Resting Heart Rate value per day This single Resting value is updated during the day if needed rather than additional values being saved to Apple Health To answer your question on querying the data that makes up a Resting Heart Rate value, I don’t think this is specifically possible. Essentially Apple have created an algorithm which uses the raw Heart Rate data to generate the Resting Heart Rate value, this algorithm is not public to my knowledge, and it has also changed over the years (for example, it used to incorporate all HR data throughout the day, now it ignores HR measured during Sleep). You will need to query those individual readings as you are doing with a HKHeartbeatSeriesQuery. Hope this helps!

I thought I'd pick this up and test it with the new iOS 18 PointPlots. I setup this code to switch between a ForEach on the PointMarks and a Point Plot. import SwiftUI import Charts @available(iOS 18.0, *) struct ManyPointsChart: View { // Reduced data point count to 10,000 as 100,000 still V. poor performance let dataPoints: [DataPoint] = (0..<10_000).map { DataPoint(xValue: $0, yValue: Double($0)) } @State var selectedIndex:Int? var body: some View { Chart { if let selectedIndex { RuleMark(x: .value("selected", selectedIndex)) } // Original Method // ForEach(dataPoints) { dataPoint in // PointMark(x: .value("Index", dataPoint.xValue), // y: .value("Y Value", dataPoint.yValue)) // } //New in iOS 18 PointPlot( dataPoints, x: .value("Longitude", \.xValue), y: .value("Capacity density", \.yValue) ) } .chartXSelection(value: $selectedIndex) } } @available(iOS 18.0, *) #Preview { ManyPointsChart() } struct DataPoint: Identifiable { var id: Double { Double(xValue) } let xValue: Int let yValue: Double } Despite reducing the data points count to 10,000 I still found Selection performance very slow in Preview. (M3 Max MBP) Performance was improved with the PointPlot vs the PointMarks, but not quite as much as I hoped. I think I'm using the APIs correctly but would welcome any feedback if not!

I think you've summarised the problem very well. The Nil Coalescing blog "Using foregroundColor(), foregroundStyle() or tint() to set text color in SwiftUI" explains well the differences between .foregroundColor and .foregroundStyle and makes it clear that the reason .foregroundColor otherwise still works it because it still return Text rather than View. It would be great to get some official guidance from Apple on this given we're now approaching WatchOS 11, everything is WidgetKit etc....

UPDATE From testing on an Apple Watch Series 6 running WatchOS 11.0 Beta 1, it appears there are no significant changes to the availability of past Health data on Apple Watch. Unfortunately I've just found that in general you can only rely on the past 7 days of Health data being there. It could be that this changes in a later beta or it could be that the Series 6 Apple Watch (oldest supported by WatchOS 11) behaves differently to maybe 64GB Apple Watches such as the Ultra 2. Regardless, it's not something I would plan for or rely on in WatchOS 11. If you're still desperate for more Health data either consider a background task and caching it over time, or file a feedback and question how the new Vitals app and also Workout training loads achieve more Health access.

I've submitted a fresh feedback for this following discussions in a WWDC lab. FB13879899 🙏🙏 This might get picked up this summer.

Further to my previous post in May providing the crash log and following a WWDC24 discussion with a DTS Engineer, I've since determined the crash I see on iOS 17.4 & 17.5 is unrelated to others in this post. We've determined my issue is likely an iOS/SwiftUI issue/bug rather than something I am able to fix. I've submitted a feedback FB13904299

I haven't got round to doing any testing yet but have a look here: https://developer.apple.com/forums/thread/732468

Would something like this format help? import WidgetKit import SwiftUI @main struct AppWidgets { // Combine widgets in this way to prevent crashes. static func main() { if #available(iOSApplicationExtension 18.0, *) { WidgetsBundle18.main() } else { WidgetsBundle17.main() } } } @available(iOSApplicationExtension 18.0, *) struct WidgetsBundle18: WidgetBundle { var body: some Widget { NewWidget() } } struct WidgetsBundle17: WidgetBundle { var body: some Widget { OldWidget() } }

Just expanding on my previous comment... Apple Watch really lags behind in this area. Although it does record HRV data it simply doesn’t record enough to provide effective insights and trends to users. My app users are CONSTANTLY asking me how to record more HRV data, how to trigger a recording from my app and how to track it more effectively. This is all very difficult in WatchOS currently. I've filed a feedback FB13880126 and mentioned it at two WWDC labs. 🙏🙏 This might get picked up this summer.

With all the new Intent based push and APIs... this seems like a glaring omission for developers who originally made more straightforward StaticConfiguration widgets and now want to upgrade them to more advanced and configurable IntentConfiguration ones. It seems that if I keep the same “kind” String identifier for the widget, they do migrate but only after a restart of the iPhone…. Until that point they just freeze and hang. This isn't really something I can ask my users to do.... I've filed a feedback: FB13880020 🙏🙏 This might get fixed for iOS 18.