I’m having an issue with an app I’ve developed where it grinds to a halt and freezes when using the TabView with a certain iOS Setting enabled. To simplify things, I can easily reproduce this with a demo project. Launch Xcode 12.5, start a new iOS project with swift, swiftUI lifecycle and SwiftUI interface. Then replace the Text code in the content view body with ithe following simple code: TabView { Text("Hello, world! Tab 1")       .tabItem {            Label("Tab 1", systemImage: "list.dash")         }     Text("Tab 2")        .tabItem {            Label("Tab 2", systemImage: "list.dash")         }   } If you launch and run this on device or on the simulator, it all works fine. You can click between the tabs etc… However, if you navigate to the iPhone settings (and this is available in the simulator) and go Accessibility -> Keyboards -> Full Keyboard Access and toggle this ON, it causes a problem. When re-opening the app we just made, as soon as you select a tab at the bottom, the app CPU usage jumps to 100%+ and grinds to a halt. The only fix is to force quite the app, but the issue persists on re-launches until you disable Full Keyboard Access.  Is this a bug? Or am I missing something? It seems to have been around throughout iOS 14’s life time. Thank you

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

Classically, the demo in the Meet WidgetKit video used a Calendar as an example, where clearly the times to update are simple to calculate based on when the users events will occur. I'd like to know about the Activity/Fitness Widget. There's no way to tell when a user will burn that next calorie and as far as I can tell, there's still no background observer in HealthKit you can use to call an update on changes. So, with that in mind, how often should I call to update? This same dilemma applies to ClockKit and WatchOS complications.

On my Watch app pre-WatchOS 9 I had code as follows: ` TabView { NavigationView { TodayView(model: delegate.model) .navigationBarTitleDisplayMode(.large) } NavigationView { SettingsView(model: delegate.model) } } .tabViewStyle(.page) However, for WatchOS 9 I'm using the new NavigationStack like this: ` NavigationStack { TabView { TodayView(model: delegate.model) .navigationBarTitleDisplayMode(.large) The issue is, with WatchOS 9 the title always displays as .inline and never large. I've tried embedding a list or scroll view. I've also tried placing a navigationView within the NavigationStack and TabView, that just makes duplicate titles. So, using the NavigationStack with a TabView on WatchOS 9, how do you get large titles? Thanks

New features in WatchOS 26 with configurable widgets make it more important than ever that apps adopt IntentConfiguration options where applicable. I develop an app with an Apple Watch complication/widget on many many user's Watch faces around the world. I've completed updating my code to support WidgetKit and remove ClockKit. However, I face huge issues adding support for users to configure their widget/complications. If I update a widget to go from StaticConfiguration to IntentConfiguration, even when keeping the "kind" string the same, the widget disappears from the Watch face. This is an unacceptable user experience meaning I can't proceed with the migration. The problem is users will expect me to offer configuration in the Watch face soon for their widget/complication. Currently this process is done in a sub-optimal way in the app itself. A similar issue exists on iOS where the widget will just "freeze" indefinitely is migrated. This issue still occurs on the iOS 26 and WatchOS 26 betas. So how to move this forward. This has been discussed previously here: https://developer.apple.com/forums/thread/661247 I've mentioned it at WidgetKit labs I've filed feedback last year: FB13880020 I've filed feedback this year: FB18180368 It seems really important this gets fixed for developers to adopt these new features, is there any other migration route I'm missing or a workaround that would mitigate this seemingly big problem.

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?

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.

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

In WatchOS 26 you can now configure Apple Watch Widgets that use AppIntents instead of having a preconfigured option via AppIntentRecommendation. This is demonstrated in the Weather Details Widget. In that, the Intent has been set up such that the options have icons for each parameter. How can I update my Intent code to offer this? struct DataPointsWidgetIntent: AppIntent, WidgetConfigurationIntent { static var title: LocalizedStringResource = "Data Points Widget Configuration" static var description = IntentDescription("Configure the individual data point display for Widgets.") static var isDiscoverable: Bool { return false} init() {} func perform() async throws -> some IntentResult { print("DataPointsWidgetIntent perform") return .result() } @Parameter(title: "Show Individual Data Points", default: true) var showDataPoints: Bool? @Parameter(title: "Trend Timescale", default: .week) var timescale: TimescaleTypeAppEnum? static var parameterSummary: some ParameterSummary { Summary("Test Info") { \.$showDataPoints \.$timescale } } } enum TimescaleTypeAppEnum: String, AppEnum { case week case fortnight static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Trend Timescale") static var caseDisplayRepresentations: [Self: DisplayRepresentation] = [ .week: "Past Week", .fortnight: "Past Fortnight" ] }

I'm looking to maximise my Watch app's widget to be as up to date as possible. If we imagined the app was a simple step counter, and we wanted to display the users count as up to date as possible. We can conclude: We don't care about widget timelines beyond the current entry as we can't predict the future! We need to refresh the count as often as possible The refresh should be very quick with a straightforward HealthKit query, no networking or heavy work needed. We will assume the user has the complication/widget on their active Watch face. With the standard WidgetKit APIs we can expire the timeline after 15 minutes and in my experimentation a Watch app can usually update its widget timeline at that frequency if it's on the Watch face. I'm experimenting with two methods to try and improve refreshes further A user's step count might not have recently changed when the timeline update is called. I was therefore looking into the HealthKit enableBackgroundDelivery API (which requires the HealthKit Background Delivery entitlement to be enabled) to get updates limited to once an hour from a HKObserverQuery, I can then call the WidgetCenter.shared.reloadAllTimelines() from there. WatchOS also support the BGAppRefreshTaskRequest(identifier:"") and .backgroundTask(.appRefresh) APIs. I can request updates once every 15 minutes here too and then call the WidgetCenter.shared.reloadAllTimelines(). With option 1, this update opportunity is great as it will specifically update when there's new steps so even once an hour this would be helpful (A real shame to be limited to once an hour even if this used up WidgetKit standard reload budgets: FB13879817, FB11677132, FB10016177). But I can't determine if this update takes away one of the standard timeline expiration updates that already run 4 times an hour? Could I observe additional Health types to get additional updates? Do I need the Background Modes Capability as well as the HealthKit Background Delivery for this in Xcode or just the HealthKit one? With option 2, I can't find a suitable option in the (short) list of supported background modes in Xcode. Does not selecting any mean my app will get 0 refreshes from this route and so should not be implemented in my use case?

New in iOS 26 and WatchOS 26 is a Sleep Score calculation for users based on Duration, Bedtime and Interruptions. Unfortunately I can't find any APIs for developers to tap into this metric. Yes, in theory it's all created off the same Sleep Analysis data already available with HealthKit but that makes it very hard to recreate in our apps. If the numbers don't match up exactly, users will understandably complain. Can anyone confirm that this is the case and I've not missed a Sleep Score API? I'll then file feedback. Hopefully this doesn't go the way of Heart Rate Zones where the Apple Watch iPhone app has generated them for years and provided no way for third party apps to access these values (yes many feedbacks provided previously).

I'm having problems with my released app with iOS & WatchOS 26 support. I've added AppIntentConfiguration support in the WatchOS app such that users can configure the complication. My complications also support multiple families and so I have slightly different configuration options available if its in the .accessoryRectangular slot or the .accessoryCircular one. This works fine on Apple Watch when editing the Watch face. Here you can then select the configuration options fine and they are correct for the different variants. However on iOS when configuring in the Apple Watch app on iPhone, the different complication size is ignored and the same configuration options are offered meaning they are wrong for one of them. I created a sample project, here is the app intent code: struct TestWidgetConfigurationIntent: AppIntent, WidgetConfigurationIntent { static var title: LocalizedStringResource = "New Widgets with Configuration" static var description = IntentDescription("Lots of stuff.") static var isDiscoverable: Bool { return false} init() {} func perform() async throws -> some IntentResult { return .result() } @Parameter(title: "Enable More Detail", default: true) var moreDetail: Bool @Parameter(title: "Enable Other Parameter", default: true) var otherParameter: Bool static var parameterSummary: some ParameterSummary { When(widgetFamily: .equalTo, .accessoryRectangular) { Summary("Test Info") { \.$moreDetail \.$otherParameter } } otherwise : { Summary("Test Info") { \.$moreDetail } } } } In WatchOS you get the correct configuration options: In iOS you do not, you get the same configuration option regardless of which family size you select: This could be a bug so I've filed feedback FB20328319. Otherwise if anyone has insights, it would be very appreciated. This is all tested on the current iOS 26.0 and WatchOS 26.0 versions. Thanks!

I'm trying to create a UI layout and navigation functionality similar to the Apple Fitness app on Apple Watch. This is all WatchOS 9 so no need for older API support, phew! I want to have NavigationTitle set for each view in a TabBar. I want each selected NavigationDestination to hide the TabBar controls and disable swiping when opened. I want the NavigationTitle and update to remain whilst navigating between Tabs and Childs. I've created this sample code based off the Building a productivity app for Apple Watch sample code from Apple and other examples on navigation with the new NavigationStack in WatchOS 9, iOS 16 etc... import SwiftUI @main struct Test_Watch_App_Watch_AppApp: App {     @SceneBuilder var body: some Scene {         WindowGroup {             TabView {                 NavigationStack {                     ScrollView {                         VStack {                             NavigationLink("Mint", value: Color.mint)                             NavigationLink("Pink", value: Color.pink)                             NavigationLink("Teal", value: Color.teal)                         }                     }                     .navigationDestination(for: Color.self) { color in                         Text("Hello").background(color)                     }                     .navigationTitle("Colors")                 }                 NavigationStack {                     ScrollView {                         VStack {                             NavigationLink("headline", value: Font.headline)                             NavigationLink("title", value: Font.title)                             NavigationLink("caption", value: Font.caption)                         }                     }                     .navigationDestination(for: Font.self) { font in                         Text("Hello").font(font)                     }                     .navigationTitle("Fonts")                 }             }.tabViewStyle(.page)         }     } } The problem here is, when selecting any of the Navigation Links, the child view still displays the Tab Bar page indicators and allows you to swipe between the tabs, I don't want this. The functionality as I'd like exists int eh Apple Fitness app on the Watch. The app launches in the Activity Tab. You can swipe across to Sharing, select a person, and in that view it's not then possible to swipe straight back to Activity. I've tried Embedding the whole TabView in a NavigationStack and removing the NavigationStacks per tab. This works as far as fixing the child views hiding the TabBar page indicator controls and swiping. However, it then breaks NavigationTitles on launch and when moving in and out of Childs, so I don't think it should be this way. Any help very appreciated.

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