I'm trying to make a Swift Chart where 24 AreaMarks an hour apart on X axis over a day display a vertical gradient. The gradient is vertical and is essentially [Color.opacity(0.1),Colour,Color.opacity(0.1] The idea here is where the upper and lower points of each AreaMark are the same or close to each other in the Y axis, the chart essentially displays a line, where they are far apart you get a nice fading vertical gradient. However, it seems that the .alignsMarkStylesWithPlotArea modifier is always set for AreaMarks even if manually applying it false. Investigating further, I've learnt that with AreaMarks in a series, Swift Charts seems to only listen to the first foreground style set in. I've created some sample code to demonstrate this. struct DemoChartView: View { var body: some View { Chart { AreaMark(x: .value("Time", Date().addingTimeInterval(0)), yStart: .value("1", 40), yEnd: .value("2", 60)) .foregroundStyle(LinearGradient(colors: [.pink, .teal], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) AreaMark(x: .value("Time", Date().addingTimeInterval(3600)), yStart: .value("1", 44), yEnd: .value("2", 58)) .foregroundStyle(LinearGradient(colors: [.orange, .yellow], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) AreaMark(x: .value("Time", Date().addingTimeInterval(03600*2)), yStart: .value("1", 50), yEnd: .value("2", 90)) .foregroundStyle(LinearGradient(colors: [.green, .blue], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) } } } Which produces this: So here, all the different .foregroundStyle LinearGradients are being ignored AND the .alignsMarkStylesWithPlotArea(false) is also ignored - the amount of pink on the first mark is different to the second and third 🤷‍♂️ Has anyone encountered this. Are AreaMarks the correct choice or are they just not setup to create this type of data display. Thanks

I ran into a problem recently with my production app and an update for iOS 18. In this example I was using a new API added to the RC candidate of iOS 18.0, using this API as an example, I couldn't find a satisfactory way to avoid crashing on iOS 18.1 where the API was not available. I had plenty of users running the iOS 18.1 Beta and ultimately it's my fault if a version of my app did work, and then didn't after an update.... This code causes a crash on iOS 18.1 beta as the .appleSleepingBreathingDisturbances API doesn't seem to have made it's way into the beta: if #available(iOS 18.0, *), #available(watchOS 11, *) { healthKitTypesToRead.insert(HKQuantityType.quantityType(forIdentifier: .appleSleepingBreathingDisturbances)!) } I tried this but it still crashed on 18.1: if #available(iOS 18.0, *), #available(watchOS 11, *) { if let newQuantity = HKQuantityType.quantityType(forIdentifier: .appleSleepingBreathingDisturbances) { healthKitTypesToRead.insert(newQuantity) } } In the end the only way I could resolve this was the following: if #available(iOS 18.1, *){ // Do nothing } else if #available(iOS 18.0, *), #available(watchOS 11, *) { if let newQuantity = HKQuantityType.quantityType(forIdentifier: .appleSleepingBreathingDisturbances) { healthKitTypesToRead.insert(newQuantity) } } This seems like a poor solution and I'll have to ensure I release a new version of the app once iOS 18.1 has the available API added to enable support for the feature. How could I have checked availability for this API correctly without causing the app to crash? I'm asking this question more as a Swift language feature rather than issue with the specific API as I'm sure that will get resolved soon anyway. Thanks

I’m having an issue with my published iPad app on the App Store where a selection of users (but not all) are finding they are unable to download my app on their iPad. The app recently was updated to support only devices Running iOS/iPadOS 17 and also added iPad support as HealthKit is available there now. The App Store listing correctly shows it as compatible but for some reasons user still see incompatibility messages. This makes no sense as the app has been full built and tested on iPad and a lot of users are using it fine. All the iPads in question are running ipadOS 17 too. I can only assume this is a bug but I thought I’d post here in case maybe I had an Xcode build setting wrong or something. Thank You

Is there any approach or sample code available to use these APIs: .chartScrollableAxes(.horizontal) .chartScrollPosition(x: ...) .chartScrollPosition(initialX: ...) .chartScrollTargetBehavior(...) .chartXVisibleDomain(length: ...) Plus a gesture recognised or Pinch or Magnification to create a Swift Chart with an X axis that can be zoomed in or out with a pinch gesture? And when zoomed in at any level above 0, the chart can then be scrolled left to right along the X axis. I've had success using .chartScrollableAxes with .chartXSelection in parallel, so would also like to keep the ability to select X values too.

I've been seeing warning like the following with my Apple Watch app: === AttributeGraph: cycle detected through attribute 140952 === === AttributeGraph: cycle detected through attribute 131640 === === AttributeGraph: cycle detected through attribute 131640 === === AttributeGraph: cycle detected through attribute 131640 === === AttributeGraph: cycle detected through attribute 131640 === === AttributeGraph: cycle detected through attribute 131640 === === AttributeGraph: cycle detected through attribute 131640 === I've done some debugging with Instruments and Xcode, I've determined that its caused by adding a .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { Label("Stop", systemImage: "xmark") } } to an item within my NavigationSplitView List Destination view. To aid reproduction of this issue even more, I've verified the same warning occurs with the Apple sample code from the WWDC23 Backyard Birds app. https://developer.apple.com/documentation/swiftui/backyard-birds-sample?changes=_9 If you take the Apple sample code, open it in Xcode 15.4 and run it in the Apple Watch WatchOS 10.5 simulator, then select the Bird Springs item, all is well. If you then add the above toolbar code to the BackyardSummaryTab file at the bottom of the VStack, you'll see the same AttributeGraph issues I'm seeing in my app. Is this a bug? I can't understand why adding a static ToolBarItem in WatchOS is causing this. I've seen this issue in the simulator and also on device.

It's fairly well know and stated that the Apple Health / HealthKit data store is unavailable when iPhone is locked. Since Lock Screen Widgets were introduced there's been a feature parity mismatch with Apple's own Fitness app which is able to display updating Activity Rings on the Lock Screen. Third party apps cannot do this and have to rely unlocking their device to then trigger an update. This means they often display stale and wrong Health data. With the release of iOS 18 beta, I see no changes to this... Is there anything I've missed? Currently for requesting the Timeline Updates on my Widget I have to just keep requesting updates as often as possible and hope that each time the iPhone might be unlocked.... This is inefficient and a waste of device resources. Even a Widget timeline reload API that let the developer say "Only call update if iPhone unlocked" would be useful.

How can I open the user's Health Privacy Settings directly from my app when I'd like them to review them? I believe similar questions have been asked before like this one: https://forums.developer.apple.com/forums/thread/730434 However, I'm wondering if the situation is changed for iOS 17 or if there's a way that works for Health permissions. This is directly possible in the Garmin Connect app for example which is a major app on the store.

I'm seeing problems with the new Apple Watch Modular Ultra Watch face... This is all using the latest WatchOS 10.1 and with WidgetKit complications. (Have also tested with the new WatchOS 10.2 beta in the simulator) The Graphic Circular (accessoryCircular) complications space the numbers differently sometimes causing maximum and minimum numbers to look like one long number (see small circular complications in screenshot) The exact same complication in the accessoryRectangular on the Modular Ultra face clips text when it doesn't on any other watch face I've filed feedback FB13344580 Hopefully the screenshots show the issue well.

My app's Widgets on iPhone rely on access to the Health Store to update. This makes them appearing in the new StandBy mode not a good experience as they never update. Is there a way to opt out of this mode but keep the options for my users to put Widgets on their home screen? Thanks

I'm having a problem in my app where when the use dismisses the side bar in a NavigationSplitView, the TabView on the detail view animates with a glitch to an offset page position. I've simplified the issue into a Single View which can be previewed in Xcode. This issue occurs on real hardware and in the simulator. This issue only occurs in landscape on iPad when dismissing the sidebar. Here is the code: struct ContentView: View { @State var pageIndex = 9 var body: some View { NavigationSplitView { Text("AppSidebarList") } detail: { TabView(selection:$pageIndex) { ForEach(0..<10, id:\.self) { i in ScrollView(.vertical, showsIndicators: false) { Text("Page \(i)").padding(.top,50) Rectangle().fill(Color.red) .frame(height:25).frame(maxWidth:.infinity) .padding() } } }.tabViewStyle(.page(indexDisplayMode: .never)) }.accentColor(Color.indigo) } } Here is the preview before selecting anything: This is then the expected behaviour after selecting the button top left to hide the sidebar: But instead the transition animation glitches and I get this: Note, the page is offset as indicated by the red bar. I've tried playing around with frame of maxWidth:.infinity. This issue does not happen if the iPad is in portrait, this seems to be because the sidebar in this mode overlays the detail view, where as in portrait they share the space and the detail view resizes to fill the space. Note the page index, it's the app behaviour that the TabView shows a selection of pages with the last one being the default and the user swiping backwards through. This issue does not occur if the default pageIndex is 0 Either this is a bug or there's a work around or I'm not using something correctly. It would be good to establish which. Many thanks

I'm looking to migrate my users ClockKit complications to WidgetKit in my next app update. I can only do this for WatchOS 10 users because the APIs are too limited for WatchOS 9 (eg. Widget corner round text not available). But I do need to do this for WatchOS 10 users in order to get in the Smart Stack. When I tried to mark my getWidgetConfiguration method in my ComplicationController.swift with: @available(watchOS 10.0, *) it complains and says: Protocol 'CLKComplicationWidgetMigrator' requires 'getWidgetConfiguration(from:completionHandler:)' to be available in watchOS 9.0 and newer I then tried modifying my WidgetKit extension to only support WatchOS 10. This seems to work for a while but at some point WatchOS 9 devices still try the migration and crash with symbolNotFound DYLD issues for the WidgetKit extension which shouldn't even be embedded in the WatchOS 9 builds! (all visible in iPhone Analytics data crashes) So I'm not sure what else to try. I've researched a lot in docs etc... but can find no official way to achieve this.

Anyone who has successfully migrated to using WidgetKit for their Apple Watch complications, your help would be greatly appreciated! I've migrated to WidgetKit for my Watch app. On the Apple Watch Face Editor, the new Widget names and options appear correctly. However, on the iPhone Apple Watch app, it offers both WidgetKit and old ClockKit complications... this should not be. I also have found rendering issues where Watch Faces on the main My Watch tab have blank gaps for WidgetKit complications, when selecting the Watch Face they then render (see photos) I've put in a feedback FB12460375 Have tried a full clear and reinstall of my app on both devices, no change. This issue occurs on WatchOS 9.5.2 / iOS 16.5.1 and WatchOS 10 Beta 2 / iOS 17 Beta 2 Any other ideas?

Relative Date labels on WatchOS complications do not update when in the .WidgetLabel section modifier. Am I missing anything? For example if I want a .accessoryCircular complication in the top centre middle of the Infograph Watch Face, I can have maybe an Icon for the app in the circular slot and then use the .WidgetLabel modifier to display text. However, the Text(Date(), style: .relative) will not update in the WidgetLabel area, but it will update in main area. This is a bug I suspect. This same problem also exists with the .accessory corner complications and the WidgetLabel. The best example of where this works fine currently in the WatchOS system is the Heart Rate complication. Here the WidgetLabel text shows the relative date. It also has formatting options for the date (like only showing minutes), none of this is available to third party developers. Have tested this on the latest public releases of iOS, WatchOS & Xcode as well as the new iOS 17, WatchOS 10 and Xcode 15 Beta releases. Example Code: import SwiftUI import WidgetKit struct WatchWidget: Widget { let kind: String = "WatchWidget" var body: some WidgetConfiguration { StaticConfiguration(kind: kind, provider: TimelineProvider()) { entry in Text(Date(), style: .relative) .widgetLabel { Text(Date(), style: .relative) } } .configurationDisplayName("WatchWidget") .description("WatchWidget") .supportedFamilies([.accessoryCircular, .accessoryCorner]) } }

I'm trying to ensure my watch app launches as quickly as possible. I'm using the @WKApplicationDelegateAdaptor because of needing to implement the BackgroundRefresh handlers. What I'm finding is that the time between the app calling the main init() and then the ExtensionDelegate calling applicationDidFinishLaunching is often > 2 seconds. I've tried using Instruments to profile the App launch but have never had any luck with the tool on a watch app. So I then created a blank project just with the elements needed to implement the same WKApplicationDelegateAdaptor and oslog calls, performance was the same... This is tested on WatchOS 9.5 & 9.5. This is on a Series 6 and Series 8 Apple Watch (FYI S6 == S7 == S8 for Apple Watch CPU performance) Interestingly, on the simulator, the time gap was less, more like 1 second between main init() and applicationDidFinishLaunching.... not sure why this would be this way. Anyway, for real world device usage, is this the best performance I can expect? Is there anything that can be done to improve this?

For Apple Watch complications displayed on tinted faced, developers can use: @Environment(\.complicationRenderingMode) var renderingMode to see if the watch face is tinted. You can then use the .complicationForeground() modifier to set elements of the complication to match that tint color. (I appreciate that .complicationForeground() is now deprecated in favour of .widgetAccentable() but I believe the behaviour is the same). However, this can only be applied to a view I believe. I'd like to display a Swift Chart where only certain elements of the chart have the .complicationForeground() rather than the whole chart. For example, in one case I'd like the LineMark to pop with the tinted color of the complication whilst the rest of the complication get the gray default tint. Is there a way to do with with the current APIs? Thanks