iOS 27 adds a second stage to HealthKit read authorization. After picking data types, the user chooses "Past 30 Days and Future Data" or "All Recorded Data and Future Data", with Allow disabled until one is selected. Every user of every health app now makes this call, in the first seconds of onboarding, with no real context about what the app needs. I don't think the scale of this has landed yet. A meaningful share of users will pick 30 days. multi-year health trends, month to month comparisons, all-time records: with 30 days these features don't get worse, they stop existing. And it breaks silently. The user sees empty charts and a app that doesn't do what the screenshots promised. They won't connect that to a sheet they tapped through on day one — they'll connect it to the app. That's the reckoning: a wave of one-star reviews and support mail for a decision the developer never saw and can't inspect. Because we can't inspect it .authorizationStatus(for:) deliberately hides read authorization and getRequestStatusForAuthorization only says whether prompting would show UI, so a 30-day grant and a genuinely new Apple Watch user look identical from the query layer. A callback when Health permissions change for a type — even without disclosing the new state — would go a long way here. And we can't route users to the fix. UIApplication.openSettingsURLString opens the app's own Settings page, which has no Health section. The real control sits at Settings › Privacy & Security › Health › — four levels deep, unreachable from any public API. My suggestion is a URL constant scoped to the calling app, the way openNotificationSettingsURLString (iOS 15.4+) and openDefaultApplicationsSettingsURLString (iOS 18.3+) already work. But that's just my idea; if there's a better mitigation, or something already planned, I'd like to hear it. Worth saying the privacy gain looks thin either way: the app keeps all future data indefinitely, so a 30-day grant becomes a full-history grant in thirty days for anyone who keeps the app. The window limits what's readable today, not what accumulates. iOS 27 release is approaching... I think this will cause problems 😞 Filed as FB24398048 and FB24398031

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.

In the WWDC 2019 session "Extended Runtime for WatchOS apps" the video talks about an entitlement being required to use the HR sensor judiciously in the background. It provides a link to request the entitlement which no longer works: http://developer.apple.com/contect/request/health-monitoring The session video is also quite hard to find these days. Does anyone know why this is the case? Is the API and entitlement still available? Is there a supported way to run, even periodically, in the background on the Watch app (ignoring the background observer route which is known to be unreliable) and access existing HR sensor data

Apologies, if I've missed the answer already here, I've searched around but can't find it. Foundation models and Private Cloud Compute require Apple Intelligence to be enabled in Settings as mentioned here. At the same time it says that Foundation Models PCC calls are supported on all Apple Watch models that run WatchOS 27. So, will there be a seperate Apple Intelligence setting in WatchOS 27 for those devices? Otherwise if a user has an Apple Watch Series 11 (which does support Apple Intelligence) paired with an iPhone 15 (which doesn't support Apple Intelligence), will they be unable to use the Foundation Models PCC calls from WatchOS in my app? Despite the fact the iPhone isn't involved in these queries anyway?

I've created a Snippet for my iOS app which I want to be able to run from the LockScreen via a Shortcuts widget. All works fine except when I run the shortcut and the App Snippet appears, it doesn't always render the SwiftUI view in the same way. Sometimes the width boundaries are respected and sometimes not. I've tested this on iOS 26.1 and iOS 26.2 beta 3 I think this is a bug but it would be great if anyone could see what I might be doing wrong if it's not. Incase it is a bug I've filed a feedback (FB21076429) and I've created a stripped down sample project showing the issue and added screenshots showing the issue. Basic code to reproduce issue: // Intent.swift // SnippetBug import AppIntents import Foundation import SwiftUI struct SnippetEntryIntent: AppIntent { static let title: LocalizedStringResource = "Open Snippet" static let description = IntentDescription("Shows a snippet.") // Don’t open the app – stay in the snippet surface. static let openAppWhenRun: Bool = false func perform() async throws -> some ShowsSnippetIntent { .result(snippetIntent: TestSnippetIntent()) } } struct TestSnippetIntent: SnippetIntent { static let title: LocalizedStringResource = "Snippet Intent" static let description = IntentDescription("Action from snippet.") @MainActor func perform() async throws -> some IntentResult & ShowsSnippetView { .result(view: SnippetView(model: SnippetModel.shared)) } } @MainActor final class SnippetModel { static let shared = SnippetModel() private init() { } } struct SnippetView: View { let model: SnippetModel var body: some View { HStack { Text("Test Snippet with information") Spacer() Image(systemName: "heart") }.font(.headline) } } struct Shortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: SnippetEntryIntent(), phrases: [ "Snippet for \(.applicationName)", "Test Snippet \(.applicationName)" ], shortTitle: "Snippet", systemImageName: "barcode" ) } } You also need these lines in your main App entry point: import AppIntents @main struct SnippetBugApp: App { init() { let model = SnippetModel.shared AppDependencyManager.shared.add(dependency: model) } var body: some Scene { WindowGroup { ContentView() } } } This is correct This is incorrect

Is there any guidance on changes here between iOS 26 & 27? To go .topLeading or .topTrailing? That is the question. iOS 26 iOS 27

What’s the recommended way to determine whether HealthKit data is being accessed on an iPad versus an iPhone? My goal isn’t really to identify the device type itself, but to know whether the HealthKit data is likely being viewed on the device where it was originally recorded, or on a device that receives the data via HealthKit/iCloud syncing. This matters because synced HealthKit data can appear with a delay, and I’d like to set appropriate expectations for users. I previously used UITraitCollection.current.userInterfaceIdiom == .pad as a proxy for this, but that API is being deprecated. Is there a better way to distinguish between locally recorded HealthKit data and data that has arrived via sync, or otherwise identify when the app is running on an iPad?

Is this exclusive to the Apple Watch Workout app? If I make a third party workout app, and use a workout builder to create a running workout, will that workout still cause VO2Max values to be generated? Similar question for Cardio Recovery values.

This is discussed here: https://developer.apple.com/forums/thread/801455 Essentially my users are finding there can be inconsistencies in the configurations offered for my app complications depending on if they are doing so on their Apple Watch directly or via the Watch Face Gallery in the iPhone Apple Watch app. Are there any new changes here or any best practices to follow when creating WidgetConfigurationIntents?

Let's take an example where a user is on an iPhone 12 running iOS 27. They have an Apple Watch Series 10 paired running WatchOS 27. Are they able to access SiriAI queries from the Apple Watch? If not is there a technical limitation on why this isn't possible? On Apple Watch models where SiriAI is fully supported, does it still have any on device capability or is it all now requiring Internet access? And can this be Internet over cellular without the paired iPhone nearby?

I have some really straight forward code in a sample project. For some reason when the app launches the title is blurred obscured by scrolledgeeffect blur. If I scroll down the title goes small as it should do and all looks fine. If I scroll back to the top, just before it reaches the top the title goes large and it looks correct, but once it actually reaches/snaps to the top, is then incorrectly blurs again. Is there anything obvious I'm doing wrong? Is this a bug? struct ContentView: View { var body: some View { NavigationStack { ScrollView { VStack { Rectangle().fill(Color.red.opacity(0.2)).frame(height: 200) Rectangle().frame(height: 200) Rectangle().frame(height: 200) Rectangle().frame(height: 200) Rectangle().frame(height: 200) } } .safeAreaBar(edge: .top) { Text("Test") } .navigationTitle(Title") } } }

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!

Are there any HealthKit related changes to be aware of in the new update that enables SPO2 / Blood Oxygen Saturation measurements on certain Apple Watch models within the US? I’m aware of processing happening on the phone…. But beyond that: Does this mean values are then saved to Apple Health? Do these models still take background SPO2 measurements in the same way as other models do? Are these values then visible in third party iOS apps as normal through HealthKit? Do these values sync back to the paired Apple Watch HealthKit store for third party apps to access on the Watch? For reference I have an iOS and WatchOS app that, amongst other features, provides the ability to see your SPO2 values in the Watch app, complications and in the iOS app.

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

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.