I have a watchOS app that records workouts on a piece of Bluetooth LE fitness equipment. It runs an HKWorkoutSession and, for the length of that session, stays connected to the machine and subscribed to a characteristic that reports step data once a second. Each notification is recorded into the workout's HKLiveWorkoutBuilder. The connection needs to last as long as the workout — typically 20–60 minutes. The watch app declares both: WKBackgroundModes = workout-processing UIBackgroundModes = bluetooth-central This works indefinitely while the app is in the foreground. When the app leaves the foreground — the user lowers their wrist or goes to the watch face — the peripheral disconnects after roughly three minutes, and the workout loses the rest of its data. What we have been able to establish from logs at the moment of the disconnect: The app is not suspended. Notifications arrive at a steady 1 Hz with no gaps right up to the disconnect (271 and 272 consecutive notifications in two separate cases), so the workout session is keeping the app running as expected. centralManager.state is .poweredOn. centralManager(_:didDisconnectPeripheral:error:) is called with error == nil, and the peripheral's state is .disconnected. Nothing in our code calls cancelPeripheralConnection at that point; our own teardown runs afterwards, in response to the disconnect. The user is still using the machine, and the machine is still notifying. Reproducible: two captures roughly three minutes and twenty seconds after the app backgrounded. I understand from Get timely alerts from Bluetooth devices on watchOS (WWDC22) that background Bluetooth on watchOS is intended for timely alerts, with a limited number of background runtime opportunities, and that periodic data collection should use Background App Refresh instead. Our data arrives once a second for the whole workout, so I assume we are well outside what that mode is budgeted for, and that the disconnect is the system reclaiming the link. My questions: Does a running HKWorkoutSession grant any exemption from the background Bluetooth limits? workout-processing clearly keeps the app executing — we receive notifications for minutes after backgrounding — but the connection is still torn down. Is Bluetooth's background budget independent of the workout runtime, and is that the intended behaviour? Is there a supported way to hold a BLE connection for the duration of a workout session? Reading a fitness machine's telemetry for an entire workout seems like a mainstream use of both frameworks together, but I cannot find a configuration that survives the app leaving the foreground. Would a longer connection interval change this? The session recommends at least 150 ms. If the disconnect is driven by connection-event volume rather than notification count, a slower interval or a lower update rate may be the answer — and if so, is there a documented threshold to aim for? error == nil on disconnect. The documentation says a nil error means the disconnect was requested locally via cancelPeripheralConnection, which we do not call here. Should a system-initiated reclaim of the link be reported this way, or is there a more specific error we should be looking for? We now log the error on peripheral(_:didUpdateValueFor:error:) to catch LeGattNearBackgroundNotificationLimit and LeGattExceededBackgroundNotificationLimit, but have not yet observed either before a disconnect. Is there any entitlement path for this? We are aware of com.apple.developer.bluetooth-central-background and that it is limited to continuous glucose monitoring. Is there an equivalent route for fitness equipment, or is foreground-only the expected design for this class of app? If continuous background Bluetooth is simply not available here, I would like to know that clearly, so I can design around the disconnect — reconnecting mid-workout rather than treating a dropped link as the end of the session.

I'm writing a Watch app where we have an in-built protocol for measuring resting heart rate. The user taps start and the heart rate is measured for 30 minutes while they're lying down. It works well, but because I'm using HKWorkoutSession to do this, the green exercise ring is advancing by 30 minutes even though the user is not exercising. So, any way to get continuous heart rate measurements without using HKWorkoutSession?

I have a watchOS app with a connected iOS app using Swift and SwiftUI. The watchOS app should read heart rate date in the background using HKOberserQuery and enableBackgroundDelivery(), send the data to the iPhone app via WCSession. The iPhone app then sends the data to a Firebase project. The issue I am facing now it that the app with the HKObserverQuery works fine when the app is in the foreground, but when the app runs in the background, the observer query gets triggered for the first time (after one hour), but then always get terminated from the watchdog timeout with the following error message: CSLHandleBackgroundHealthKitQueryAction scene-create watchdog transgression: app<app.nanacare.nanacare.nanaCareHealthSync.watchkitapp((null))>:14451 exhausted real (wall clock) time allowance of 15.00 seconds I am using Xcode 16.3 on MacOS 15.4 The App is running on iOS 18.4 and watchOS 11.4 What is the reason for this this issue? I only do a simple SampleQuery to fetch the latest heart rate data inside the HKObserverQuery and then call the completionHandler. The query itself takes less than one second. Or is there a better approach to read continuously heart rate data from healthKit in the background on watchOS? I don't have an active workout session, and I don't need all heart rate data. Once every 15 minutes or so would be enough.

I'm trying to understand the exact rules the Health app uses to reconcile (deduplicate/merge/discard) overlapping sleep samples, and I'm hoping an Apple engineer can clarify the behavior. Background: My Apple Watch wrote sleep samples to HealthKit twice within the same day, and the two writes overlap substantially: Same stage, overlapping in time — e.g., two "Core" sleep samples that overlap each other in time. Different stages, overlapping in time — e.g., Deep and Core overlap, and Core and REM (Rapid Eye Movement) also overlap. Observation: Even though the raw samples contain these overlaps, the Health app ultimately displays non-overlapping data (i.e., it has reconciled the overlaps somehow). I'm confused about the exact reconciliation rules the Health app applies to such overlapping data. To make the problem clearer, I've visualized the raw HealthKit samples. In the attached chart, you can see the same stage was written multiple times at different timestamps, shown in chronological order. However, the data ultimately displayed by the Health app differs significantly from the raw data — samples appear to have been reconciled, dropped, and merged in various ways. Question: What are the detailed rules the Health app uses to reconcile overlapping sleep samples? Specifically: When samples of the same stage overlap in time, how is the overlap resolved? When samples of different stages overlap in time, which stage takes precedence, and how are the boundaries adjusted? Are samples merged, truncated, or discarded entirely? Under what conditions? Any clarification from the HealthKit team would be greatly appreciated. Appendix 1 — Raw data visualization. All sleep samples as shown in the Health app (source: the complete sleep dataset in the Health app). Appendix 2 — Final presentation. How the Health app presents the data after reconciling the raw samples. Note — Comparing Appendix 2 with Appendix 1, the following differences are clearly visible: 1.A portion of Deep sleep was discarded. 2.Four awake segments were discarded. 3.Multiple REM segments were also discarded. 4.Core sleep was partially merged.

Hello, I’m requesting assistance with an urgent issue concerning my Apple Developer Program membership. I recently paid for a new subscription/membership, but I still cannot access my Apple Developer account or the related Apple connector account. When I sign in, I receive the following message: “Developer Program Membership Expired Your membership has expired, and your apps have been removed from the App Store until you renew your membership. To renew, a user with the Account Holder role must sign in and renew the membership on the Apple Developer website.” I have already completed the payment for the new membership, but the account continues to appear as expired. I am therefore unable to access the necessary developer services and manage my apps. Could someone please advise me on the following? • How can I confirm that my payment has been correctly associated with the Apple Developer team? • Does the renewal need to be completed by the Account Holder specifically? • How long should it take for the membership status and app availability to be restored? • What should I do if the payment was made with a different Apple Account? • How can I regain access to my Apple connector account? Payment info is from: 22 August 2026 I understand that Apple may require some processing time after renewal, and I appreciate your assistance. However, this issue is urgent because it is affecting access to my apps and development services. Thank you in advance for your help.

Hello, We received a customer report about intermittent missing historical step-count data when using HKStatisticsCollectionQuery on iOS 27 beta. When the query was executed on August 16, only the most recent two days—August 16 and August 15—returned correct step counts. Earlier dates returned nil from sumQuantity() and were consequently treated as zero. However, queries executed on August 14 and August 18 returned the expected data. Therefore, the problem appears to be intermittent rather than consistently reproducible. The customer confirmed that all affected historical step counts were visible in the Apple Health app, including the dates returned as zero by our query. We have not received the same type of customer report from devices running iOS 26 or earlier. Here is a simplified version of our query: guard let stepType = HKObjectType.quantityType( forIdentifier: .stepCount ) else { return } var calendar = Calendar(identifier: .gregorian) calendar.timeZone = TimeZone(identifier: "Asia/Seoul")! let queryStartDate = calendar.startOfDay(for: parsedStartDate) let tomorrow = calendar.date(byAdding: .day, value: 1, to: Date())! let queryEndDate = calendar.startOfDay(for: tomorrow) let datePredicate = HKQuery.predicateForSamples( withStart: queryStartDate, end: queryEndDate, options: .strictStartDate ) let nonUserEnteredPredicate = HKQuery.predicateForObjects( withMetadataKey: HKMetadataKeyWasUserEntered, operatorType: .notEqualTo, value: NSNumber(value: true) ) let predicate = NSCompoundPredicate( andPredicateWithSubpredicates: [ datePredicate, nonUserEnteredPredicate ] ) let anchorDate = calendar.startOfDay(for: Date()) var interval = DateComponents() interval.day = 1 let query = HKStatisticsCollectionQuery( quantityType: stepType, quantitySamplePredicate: predicate, options: .cumulativeSum, anchorDate: anchorDate, intervalComponents: interval ) query.initialResultsHandler = { _, results, error in guard let results, error == nil else { print("Query error: \(String(describing: error))") return } results.enumerateStatistics( from: queryStartDate, to: queryEndDate ) { statistics, _ in let steps = statistics .sumQuantity()? .doubleValue(for: .count()) ?? 0 print(statistics.startDate, statistics.endDate, steps) } } healthStore.execute(query) Observed behavior Query executed on August 14: historical step counts returned correctly Query executed on August 16: August 16 and August 15 returned correctly August 14 and earlier returned nil from sumQuantity() Query executed on August 18: historical step counts returned correctly again No query error was reported All step counts remained visible in the customer's Apple Health app Expected behavior The query should consistently return cumulative daily step counts when matching HealthKit samples exist and are visible in the Health app. Because this was reported through customer support, we do not currently know the exact iOS 27 beta build number. We are also unable to reproduce it consistently on our own test devices. Questions Is there a known intermittent issue with historical .stepCount queries on iOS 27 beta? Can HealthKit temporarily return incomplete statistics while data is being indexed, synchronized, or migrated? Is there a recommended way to detect that the returned statistics are temporarily incomplete? Should applications retry the query when older statistics unexpectedly return nil without an error? We have not received reports of this behavior from customers using iOS 26 or earlier. Thank you.

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

I'm building a native macOS app (deployment target macOS 14.0) that uses HealthKit. The App ID (com.ryanegli.Vantage, team RWGMA3VG99) has HealthKit enabled and saved under Capabilities. However, no provisioning profile generated for this App ID — automatic (Xcode-managed) or manually created/regenerated via the Developer Portal — ever includes the com.apple.developer.healthkit entitlement. The profile's "Review Provisioning Profile" page on the portal consistently lists only "In-App Purchase" under Enabled Capabilities, never HealthKit, even immediately after editing and regenerating the profile. Environment: Xcode 26.6, macOS 26.5 SDK Deployment target: macOS 14.0 Account role: Account Holder (sole owner of team) Steps to reproduce: Create a macOS app target with com.apple.developer.healthkit and com.apple.developer.healthkit.access in its entitlements file, App Sandbox enabled. Enable HealthKit on the App ID via developer.apple.com → Certificates, Identifiers & Profiles → Identifiers → [App ID] → Capabilities → HealthKit → Save (confirmed saved: Save button greys out afterward). Build with Xcode automatic signing, or manually create/download a "macOS App Development" provisioning profile for this App ID via the portal. Inspect the resulting profile (security cms -D -i profile.provisionprofile, or the portal's "Review Provisioning Profile" page). Expected: Profile includes com.apple.developer.healthkit. Actual: Entitlement is absent from every profile generated, across multiple regeneration attempts over several hours. Additional notes: Xcode's "+ Capability" picker in Signing & Capabilities does not list HealthKit at all for macOS targets (only appears for iOS/watchOS/etc.), suggesting Xcode's own capability catalog may not yet be updated for HealthKit-on-macOS. The App ID's "App Services" and "Capability Requests" tabs show no separate HealthKit-related entry that might explain a gating requirement (only clinical-records-specific sub-capabilities like "HealthKit Access (Verifiable Health Records)" appear there, which we don't need). Any suggestions, help, or input would be welcome. Thanks!

My app has been stuck in “Waiting for Review” status since August 6th, over a week now. I’ve submitted multiple expedited review requests and haven’t received any response or update on any of them. This delay is holding up my launch and affecting my ability to plan around it. I understand expedited review isn’t guaranteed, but getting no reply at all, even a decline, makes it hard to know whether the request was seen or if something else is holding up the review. Could someone look into my case and let me know what’s going on? Best regards, App Name: Ratiō - AI Calorie Tracker Apple ID: 6790632661

Hi Apple Developer Community, I’m preparing an iOS app called Titech for App Review. The app is intended for clinic/business users and provides preliminary AI-generated cosmetic analysis and preview guidance based on user-submitted face photos. The app is not intended to provide medical advice, diagnosis, or treatment decisions, and users are told to consult qualified experts before acting on any recommendation. We have received multiple App Review rejections and I would appreciate guidance on whether our current approach is aligned with Apple’s expectations. Current issues raised by App Review: Guideline 2.1 - Information Needed Apple asked for more information about how the app uses face data, including: What face data is collected How it is used, stored, retained, deleted, and shared Whether it is shared with third parties Where this is explained in the privacy policy Exact privacy policy text about face data We updated the app and privacy policy to explain that: Users voluntarily upload front, left-side, and right-side face photos Photos may be sent to our backend and processed by OpenAI through the OpenAI API Face ID/fingerprint data is not collected Uploaded face photos and generated preview images are deleted after the active session ends The app does not sell face data or share it with advertisers/data brokers Guideline 2.1(b) - Information Needed Apple asked about the business model and whether users access paid content. Our app does not currently include paid digital content, subscriptions, credits, or in-app purchases. Access is controlled by a registration code for clinic/business users and App Review only. Guideline 2.3.3 - Accurate Metadata Apple said the screenshots did not show the current version of the app in use. We replaced the screenshots with updated iPhone and iPad screenshots showing: Clinic access Consent and face-data disclosure Photo capture AI-generated analysis Recommendations Side effects page Generated preview flow My questions: For apps using user-submitted face photos with a third-party AI API, is it enough to clearly disclose OpenAI processing in the consent screen and privacy policy, or should this also be repeated elsewhere in the app flow? For face photos that are deleted after the active session ends, what wording does Apple generally expect around retention and deletion? Since the app is clinic/business access only and does not sell digital content, is a registration code acceptable if we clearly explain that it is not a paid digital unlock? Are there any additional App Review notes or privacy policy sections that developers usually include for apps involving face photos and AI-generated preliminary recommendations? For metadata, should the screenshots avoid login/consent screens entirely, or is it acceptable to include them as long as most screenshots show core app functionality? Any advice from developers who have passed review with apps involving user-uploaded face photos, AI analysis, or cosmetic/health-adjacent recommendations would be very helpful. Thank you.

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.

Hello everyone, I’m experiencing a visual issue when dismissing a sheet on iOS 26. I’m using the same implementation shown in the official Apple documentation. While testing, I noticed that some apps do not exhibit this behavior. However, when running this code on iOS 26, the issue consistently occurs. Issue description: The sheet dismisses abruptly A white screen briefly appears for a few milliseconds and then disappears This results in a noticeable visual glitch and a poor user experience I tested the exact same code on iOS 18, where the sheet dismisses smoothly and behaves as expected, without any visual artifacts. Has anyone else encountered this issue on iOS 26? Is this a known bug, or is there a recommended workaround? Any insights would be greatly appreciated. Thank you.

I'm developing a watchOS meditation app in which the user starts one continuous meditation session. During that session, I'd like the app to obtain a 1-minute HRV measurement immediately after the session begins (to establish a baseline), and then automatically obtain another 1-minute HRV measurement approximately 6 minutes after the session started, without requiring the user to manually start a second measurement or leave the app. My understanding is that HealthKit allows apps to read HRV samples after they have been recorded, but I haven't found a way to request that the watch generate a new HRV measurement. Is there any public API that allows a third-party watchOS app to initiate an HRV measurement similar to the Mindfulness/Breathe app, or otherwise request the Apple Watch to collect a new HRV sample at predetermined times during an ongoing session? Thanks in advance, Hern

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

I am currently developing an app that measures HRV to estimate stress levels. To align the values more closely with those from Galaxy devices, I decided not to use the heartRateVariabilitySDNN value provided by HealthKit. Instead, I extracted individual interbeat intervals (IBI) using the HKHeartBeatSeries data. Can I obtain accurate IBI data using this method? If not, I would like to know how I can retrieve more precise data. Any insights or suggestions would be greatly appreciated. Here is a sample code I tried. @Observable class HealthKitManager: ObservableObject { let healthStore = HKHealthStore() var ibiValues: [Double] = [] var isAuthorized = false func requestAuthorization() { let types = Set([ HKSeriesType.heartbeat(), HKQuantityType.quantityType(forIdentifier: .heartRateVariabilitySDNN)!, ]) healthStore.requestAuthorization(toShare: nil, read: types) { success, error in DispatchQueue.main.async { self.isAuthorized = success if success { self.fetchIBIData() } } } } func fetchIBIData() { var timePoints: [TimeInterval] = [] var absoluteStartTime: Date? let dateFormatter = DateFormatter() dateFormatter.timeZone = TimeZone(identifier: "Asia/Seoul") dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss.SSS" var calendar = Calendar.current calendar.timeZone = TimeZone(identifier: "Asia/Seoul") ?? .current var components = DateComponents() components.year = 2025 components.month = 4 components.day = 3 components.hour = 15 components.minute = 52 components.second = 0 let startTime = calendar.date(from: components)! components.hour = 16 components.minute = 0 let endTime = calendar.date(from: components)! let predicate = HKQuery.predicateForSamples(withStart: startTime, end: endTime, options: .strictStartDate) let sortDescriptor = NSSortDescriptor(key: HKSampleSortIdentifierStartDate, ascending: false) let query = HKSampleQuery(sampleType: HKSeriesType.heartbeat(), predicate: predicate, limit: HKObjectQueryNoLimit, sortDescriptors: [sortDescriptor]) { (_, samples, _) in if let sample = samples?.first as? HKHeartbeatSeriesSample { absoluteStartTime = sample.startDate let startDateKST = dateFormatter.string(from: sample.startDate) let endDateKST = dateFormatter.string(from: sample.endDate) print("series start(KST):\(startDateKST)\tend(KST):\(endDateKST)") let seriesQuery = HKHeartbeatSeriesQuery(heartbeatSeries: sample) { query, timeSinceSeriesStart, precededByGap, done, error in if !precededByGap { timePoints.append(timeSinceSeriesStart) } if done { for i in 1..<timePoints.count { let ibi = (timePoints[i] - timePoints[i-1]) * 1000 // Convert to milliseconds // Calculate absolute time for current beat if let startTime = absoluteStartTime { let beatTime = startTime.addingTimeInterval(timePoints[i]) let beatTimeString = dateFormatter.string(from: beatTime) print("IBI: \(String(format: "%.2f", ibi)) ms at \(beatTimeString)") } self.ibiValues.append(ibi) } } } self.healthStore.execute(seriesQuery) } else { print("No samples found for the specified time range") } } self.healthStore.execute(query) } }

Hi, We are integrating HKQuantityTypeIdentifierTimeInDaylight into a research application and have a few questions about how developers should interpret the data returned by HealthKit. Specifically: Should TimeInDaylight samples be treated as having a fixed minimum temporal granularity (for example, approximately 5-minute intervals), or is the sample duration implementation-dependent and subject to change? Is there any expected latency between a daylight exposure event and the corresponding TimeInDaylight sample becoming available through HealthKit? For example, are samples intended to appear shortly after exposure, or only after periodic processing and synchronization? In the Health app, each Time in Daylight sample displays a Maximum Light Intensity (lux). Is this value available through the public HealthKit API (e.g., metadata), or is it only used internally by the Health app? More generally, should developers consider TimeInDaylight to be a high-level derived metric rather than expecting a direct correspondence with underlying ambient light sensor observations? Thank you.

Dear SensorKit team, We are currently working with SensorKit ambient light data under our approved SensorKit entitlement for research use. We would be grateful for some technical clarification on the sampling strategy for the SRSensor.ambientLightSensor stream, as this directly affects how we analyse and report the data. In exported data from Apple Watch, we observe that ambient light samples do not appear to follow a fixed sampling cadence. Instead, the data appear burst-like: in one short window, we see many samples with inter-sample intervals around 100 ms, occasional near-duplicate timestamps, and then gaps of around 10 to 30 seconds with no samples. This suggests that the stream may be adaptive, event-triggered, buffered, or subject to system-level sampling decisions. We also noticed a related discrepancy when comparing the SensorKit ambient light trace with the Health app display for a corresponding Time in Daylight sample. In one example, the Health app shows a 5-minute Time in Daylight interval with a “Maximum Light Intensity” value of 9,493 lux. In the SensorKit ambient light trace around that period, the raw samples show a different maximum depending on the precise time window considered, including higher values shortly before the HealthKit interval start and lower values within the subset of SensorKit samples we inspected. We realise that Time in Daylight may be generated by a separate internal aggregation or classification pipeline, but this comparison raised the question of how closely SensorKit ambient light samples should be expected to correspond to the light intensity values displayed in Health. Could you clarify the following points for SensorKit ambient light data? Is SRSensor.ambientLightSensor sampled at a fixed cadence, or is sampling adaptive / event-driven? If sampling is adaptive, what factors influence sampling density? For example, changes in illuminance, device or wrist motion, device orientation, display state, app state, power state, charging state, or other system-level conditions. Are ambient light readings buffered and delivered or exported in bursts? Do SensorKit timestamps correspond to the physical sensor acquisition time, processing time, or the time at which the sample is made available through SensorKit? Are duplicate or near-duplicate ambient light samples expected in SensorKit exports? Are there circumstances under which ambient light sampling is suspended, downsampled, or suppressed? Is SensorKit ambient light expected to match, approximate, or differ from the light intensity values shown in Health app Time in Daylight sample details? Is the “Maximum Light Intensity” shown for Time in Daylight computed from the same underlying ambient light sensor stream exposed through SensorKit, or from a separate internal stream or aggregation? Are there recommended practices for analysing SensorKit ambient light data, especially with respect to irregular sampling, burst sampling, missing intervals, and aggregation to longer time windows? Is the sampling strategy the same across Apple Watch hardware versions, or should researchers expect device-specific differences? We do not need proprietary implementation details. Our goal is to understand the methodological constraints well enough to analyse the data appropriately and describe the limitations accurately in scientific work. Thank you!

Hello everyone, We are encountering a critical regression introduced in iOS 26.4 that results in permanent workout data loss for users. When invoking HKWorkoutBuilder.finishWorkout(completion:) while the iOS device is locked, the save operation fails completely. However, it fails silently: the completion handler executes but returns both a nil workout and a nil error. Expected Behavior: Before iOS 26.4 finishWorkout resulted in a workout id, and correctly stored the workout data in HealthKit. According to HealthKit data protection documentation, saving data when the device is locked should either succeed (writing to a temporary journal file to be merged upon unlock) or explicitly throw an error such as HKError.Code.errorDatabaseInaccessible. Actual Behavior: Because the framework returns nil for both the object and the error, the application has no way to detect that the save failed. We cannot implement a retry mechanism or queue the save, resulting in silent data loss. Steps to Reproduce: We have built a Minimal Reproducible Example (MRE) that reliably triggers this: Initialize an HKWorkoutBuilder and call beginCollection(withStart:) followed by endCollection(withEnd:). Wrap the finishWorkout call in a short 5-second asynchronous delay, protected by a UIBackgroundTask to prevent app suspension. Lock the physical device during this 5-second window. The finishWorkout completion handler will execute while the device is locked, returning workout == nil and error == nil. Existing Reports: We have filed this via Feedback Assistant (a month ago) and opened a TSI (a week ago), providing the MRE project and a sysdiagnose captured at the time of failure: Feedback ID: FB22396180 TSI Case-ID: 19755043 As we have not yet received a response or a suggested workaround through these official channels, we are reaching out to the community. Has anyone else encountered this silent failure with HKWorkoutBuilder recently? Any insights or escalation help would be greatly appreciated.

Hi everyone, I’d love to see Apple add full Sleep Tracking support for Apple Watches that are set up using Family Setup. Many families use Family Setup for children or older family members who don’t have an iPhone of their own. Sleep is one of the most important health metrics, and it would be incredibly useful if caregivers could view sleep duration and trends just like they can with other health features. This would help parents better understand their child’s sleep habits and would also be valuable for families caring for older adults. Even if detailed health data stayed private, allowing sleep summaries to sync through Family Setup would make the feature much more useful. I hope Apple considers adding this in a future watchOS update. Is this something anyone else would find helpful?

I'm building a tennis App, but I noticed the data update between the phone and watch keeps failing if I placed my camera on the baseline and player is moving around on the court. I'm trying to notify the player when they did something wrong when the camera detected it in realtime. I'm using HKWorkoutSession to keep the watch alive. Any suggestion?