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.

Just want to expand a bit on the answer here. Yes Widgets can access the Health store. However, you need other remember that the Health store is only available when the device is unlocked. I will list a few limitations that come to mind from this. There's currently no way to request widget timeline updates only when the device is unlocked. There's currently no way to get reliable updates for iPhone widgets mirrored on Mac that include Health data, these will only update when the user unlocks their iPhone. Widgets on the iPhone Lock Screen can only update their Health data when the device is unlocked, this means if you're displaying a step count for example, it won't update throughout the day automatically. The same also applies to widgets in the Standby mode on iPhone. I've previously posted multiple feedback regarding this. The latest one is FB13879739 although it was closed... maybe we'll see some improvements here one day.

I've filled a feedback for this after WWDC 23 and 24. Here's the latest one FB13879424 This is really important. Let's 🙏 for WWDC25

Is it possible that this isn't actually a TabView but instead a custom sheet that has the interactiveDismissDisabled(_:) and .presentationDetents() maybe? Just a thought anyway as the map behind is unchanged by selections on the bottom buttons.