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've submitted a fresh feedback for this following discussions in a WWDC lab. FB13879899 🙏🙏 This might get picked up this summer.

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 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....

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!

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!

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!

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!

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

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.

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.

I think I originally didn't file the feedback as I assumed there would be a way to do the availability check and didn't see it as a "bug". There's also the slight problem not not getting responses to feedback 😕 In any case, It is now resolved in the latest iOS 18.1 beta 4 seed (although I'll have to wait a little for testers to update to is before changing my app code to support the API in iOS 18.1 - the crashes will still be my fault!) I have now also filed feedback FB15252677 😊

Pretty sure this is the same thing I first mentioned here 15 months ago 😕 https://developer.apple.com/forums/thread/732751

Similar thread now started here: https://developer.apple.com/forums/thread/763164

I would say post some screenshot examples of this. I'm fairly sure it's not possible with the existing APIs and they get around it by having the same background photo that you use for your home screen.