While attempting to read a user’s daily step history spanning backward to the last 7 days, a small but consistent subset of users encounter Error Code 3 with the underlying error description: Error Code 3 "Unable to invalidate interval: no data source available." When this error occurs, we are entirely unable to read their step history. We have received ~10 direct user reports of this within the last couple of weeks.

Health and Workout data stopped syncing from my Apple Watch to my iPhone on 21 September while both devices were on the public releases. The Watch continues recording the data and the missing data remains on the Watch. Activity Sharing also continues to work. I’ve since installed the matching iOS/watchOS developer betas in an attempt to resolve the pre-existing issue, but it remains. And now I cannot get assistance via the usual Apple Support route. I’ve submitted a Feedback Assistant report with both iOS and watchOS sysdiagnoses: FB24923176. Multiple users are also reporting this issue here - https://www.reddit.com/r/AppleWatch/comments/1whu0at/apple_watch_workoutshealth_data_stopped_syncing/ Could someone advise whether this can be reviewed by the appropriate HealthKit/watchOS team? I am deliberately avoiding unpairing the Watch because the unsynced data is currently only stored on the Watch. Thanks so much!

I have a watchOS app communicating with a BLE peripheral during an active HKWorkoutSession. The workout provides sufficient runtime: once connected, the Watch can receive a notifying GATT characteristic approximately once per minute for hours, including while the display is off. In normal conditions the connection is very stable. The difficult case is outdoor use with marginal RF conditions. The peripheral and application protocol otherwise work reliably, but outdoors there are fewer reflected RF paths and normal body movement can intermittently obstruct the Watch-to-peripheral path. In those situations the link occasionally terminates with CBError.connectionTimeout. Reconnection is particularly important because this peripheral advertises for reconnection only approximately once per minute. We also know approximately which second of each minute the peripheral becomes active, so missing a single advertising opportunity can cause a relatively long data gap. I’m trying to better understand the supported CoreBluetooth/watchOS behavior in this situation. Maintaining a marginal existing connection Once the BLE connection is established, are there any public CoreBluetooth mechanisms or recommended practices for making that connection more robust against CBError.connectionTimeout? In particular, can application-level GATT activity have any influence on connection scheduling or link robustness, or is this entirely handled by the Bluetooth stack below CoreBluetooth? CBConnectPeripheralOptionEnableAutoReconnect with sparse advertising When CBConnectPeripheralOptionEnableAutoReconnect is enabled and the connection is lost, how does watchOS handle a peripheral that advertises only very infrequently? Does CoreBluetooth simply keep the reconnect pending and wait for subsequent advertisements indefinitely, subject to system policy? Known peripheral activity timing If the app knows approximately when the peripheral becomes active and advertises each minute, is there any supported way to make use of that timing during reconnection? Or should the app simply leave AutoReconnect pending and let CoreBluetooth handle reception? WWDC22 reduced reconnection range WWDC22 session 10135 says: “If your device is on the edge of Bluetooth range and repeatedly disconnects while in Background BLE connection, the reconnection range will be reduced. This means only devices close to the Apple Watch will reconnect.” The session also says these limits are counted over a rolling 24-hour window and are reset when the user interacts with the app. I would particularly appreciate clarification of how this works in practice: What conditions cause a disconnect to count toward this policy? Does this policy apply while an app has an active HKWorkoutSession and continues executing in the background? Is the state maintained per peripheral, per app, or more globally? What exactly constitutes the user interaction that resets it? Does bringing an already-running workout app back to the foreground reset it, or does the app need to be relaunched? Is there any public API or diagnostic indication that reduced reconnection range is currently active? Is there any supported way to explicitly clear/reset that state? Connection parameters Does watchOS expose any supported mechanism for a CoreBluetooth central to influence parameters relevant to connection robustness, such as connection interval, supervision timeout, PHY, transmit power, or similar link parameters? Diagnosing CBError.connectionTimeout When CoreBluetooth reports CBError.connectionTimeout, is there any supported diagnostic method to determine whether the Watch stopped receiving the peripheral, the peripheral stopped receiving the Watch, or whether this should simply be treated as a link-layer timeout without attribution to either side? For context, this is not primarily a background-runtime problem. The active workout keeps the app running and the normal persistent BLE connection can operate flawlessly for many hours. I’m specifically trying to understand the best supported strategy for preserving and recovering the BLE link when RF conditions temporarily become marginal, especially with a peripheral that advertises very sparsely after a disconnect. DTS asked me to post this question here for review.

We are an interdisciplinary research team involving Gazipaşa Science High School and Akdeniz University in Türkiye, including student researchers, a project advisor, and a medical researcher. We are conducting a non-commercial scientific research project within the TÜBİTAK 2204-A High School Students Research Projects Competition. As part of the project, we are developing an experimental wrist-based optical monitoring system. We plan to use an Apple Watch Series 9 (A2980, Part Number MR9A3TU/A) as a comparative benchmark during the development and evaluation of our system. In particular, we are interested in accessing Apple Watch photoplethysmography (PPG) data through SensorKit. We intend to use these data to support the iterative development of our optical monitoring system and to evaluate and report how modifications to our system affect its signal characteristics and performance relative to an established commercial wearable optical sensing platform. Apple Watch measurements will be used for comparative research and system evaluation, rather than as a clinical reference or diagnostic measurement. We would therefore appreciate guidance on the appropriate procedure for obtaining SensorKit access and the required entitlement for Apple Watch PPG data for this type of scientific research. To perform a scientifically meaningful comparison, we also need reliable technical information about the optical sensing system of the Apple Watch used in our study. However, we have been unable to find an authoritative and citable Apple source specifying the wavelengths or wavelength ranges of the optical emitters used in the Apple Watch Series 9 (A2980). Could you please direct us to any official Apple documentation, publication, technical specification, or other authoritative resource containing this information? If the exact specifications are not publicly available, we would appreciate guidance on whether such information can be provided for academic research purposes. We would also appreciate recommendations for the appropriate Apple technical support channel, Developer Forum, research contact, or other point of contact for further questions that may arise during the development and research process. Thank you for your time and guidance.

After updating my Apple Watch Series 10 to the public release of watchOS 27, Environmental Sound Level measurements became extremely sparse. Before watchOS 27, with Environmental Sound Measurements enabled, my watch recorded environmental sound data approximately every 30 seconds and the coverage was nearly continuous throughout the day. After updating the same Apple Watch to watchOS 27, the behavior changed significantly: Environmental Sound Level samples are much less frequent Large gaps appear between measurements Overall daily temporal coverage is dramatically reduced The same change is visible both in the Health app and through HealthKit using HKQuantityTypeIdentifier.environmentalAudioExposure No relevant settings were changed, and Environmental Sound Measurements are still enabled. This is important for apps that use Environmental Audio Exposure data for time-based analysis. In my case, I use this data for sleep and nap environment analysis. With the much sparser sampling on watchOS 27, it is difficult to reliably evaluate the acoustic environment during a specific sleep period. I have also seen other watchOS 27 users reporting similar behavior: https://www.reddit.com/r/watchOSBeta/comments/1wjrdaq/watchos_27_broke_the_noise_monitoring_app/ I submitted a Feedback Assistant report: FB24837491 Has anyone else observed the same change on watchOS 27? I’m especially interested in whether this is: an intentional change to the sampling or aggregation strategy, a HealthKit write-frequency change, or a regression in watchOS 27. If anyone has compared HKQuantitySample.startDate, endDate, sample duration, and sample interval before and after the watchOS 27 update, that data would be very useful for comparison.

We are seeing inconsistent results from HKStatisticsCollectionQueryDescriptor on iOS 27. Using the same quantity type, statistics options, anchor date, interval components, and predicate configuration, some date ranges return the expected statistics, while other ranges unexpectedly return empty results or buckets with no quantity. The affected ranges do contain HealthKit samples: HKSampleQueryDescriptor finds samples in the same date range. HKStatisticsQueryDescriptor returns the expected value when run separately for an affected bucket. HKStatisticsCollectionQueryDescriptor returns no quantity for that same bucket. Slightly expanding or shifting the date range may cause the collection query to return data again. A simplified version of the query looks like this: let datePredicate = HKQuery.predicateForSamples( withStart: startDate, end: endDate, options: .strictStartDate ) let descriptor = HKStatisticsCollectionQueryDescriptor( predicate: .quantitySample( type: quantityType, predicate: datePredicate ), options: .cumulativeSum, anchorDate: anchorDate, intervalComponents: DateComponents(day: 1) ) let collection = try await descriptor.result(for: healthStore) collection.enumerateStatistics(from: startDate, to: endDate) { statistics, _ in let quantity = statistics.sumQuantity() print(statistics.startDate, quantity as Any) } Expected behavior Every interval containing matching samples should return the corresponding statistics, regardless of the overall requested date range. Actual behavior Some date ranges produce missing or empty buckets even though matching samples exist and an individual HKStatisticsQueryDescriptor can calculate the expected value. Changing only the date range can make the data appear or disappear. The samples are visible to the app in the affected range, so this does not appear to be explained solely by iOS 27’s Limited History authorization. This behavior was not observed with the same query flow on earlier iOS versions. Is this a known regression in HKStatisticsCollectionQueryDescriptor on iOS 27, or has the expected date-range or predicate behavior changed?

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 am building a training app for endurance athletes and I am trying to get the storage design right before I write it. Guideline 5.1.3(ii) says an app "may not store personal health information in iCloud", but I cannot find anywhere that defines what falls under that phrase, and the HealthKit documentation does not mention iCloud at all. The app records workouts from Bluetooth sensors (power, speed, distance, elevation, GPS, heart rate). With permission it also reads HRV, resting heart rate and sleep from HealthKit, and calculates a daily readiness value from them. I would like to keep the app's own records in my own CloudKit container so the user sees them on their iPad. Three things I cannot resolve from the documentation: Is a developer's own CloudKit container — private or shared database — "iCloud" for the purposes of 5.1.3(ii)? Does 5.1.3(ii) apply to physiological data the app measures itself from a Bluetooth sensor and never writes to HealthKit — for instance heart rate during a workout? Is a value derived from HealthKit samples, such as a readiness score computed from HRV, resting heart rate and sleep, "personal health information" even though it is not itself a HealthKit sample? I am aware that HealthKit already syncs a user's own data across their devices, so I do not intend to mirror HealthKit samples. My question is about the app's own records and derived values. Any pointer to documentation I have missed would be very welcome.

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 submitted our app to the App Store on 9th august and it has been stuck in "Waiting for review". We have a very critical launch date timeline. We have to release our app in the first week of September (before 5th); therefore, we submitted it quite early. But seems like the app is stuck indefinitely in the "Waiting for review" state. We even raised a support ticket for this. No response on that too. App ID: 6799395555 Support conversation ID: 20000139951347 What can be done to expedite this as further delays will cause us to miss our timeline?

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.

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

I’m looking for about 15 additional iPhone/iWatch users to test SomataQuest, an early-stage fitness app that uses Apple Health data to help users understand their recent training, recovery, and readiness for today’s activity. Learn more: https://www.nexuspointinnovations.com/somataquest TestFlight: https://testflight.apple.com/join/BjXUh9bj I’d especially appreciate testers trying the following: Connect Apple Health and complete the initial setup Check whether the readiness score and its explanation make sense Review whether the app represents your recent workouts and activity accurately Evaluate whether the suggested training intensity feels reasonable Report anything confusing, incorrect, slow, or broken The app currently works best for people who regularly record workouts, sleep, heart-rate, or activity data in Apple Health. Feedback can be submitted through TestFlight or posted in this thread. This is an early beta, so candid feedback—especially about what is unclear or not useful—is very welcome.

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.

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?