Post

Replies

Boosts

Views

Activity

Reply to Unable to invalidate interval: no data source available error when fetching steps using HKStatisticsCollectionQuery
@DTS Engineer In my iOS app, I query HealthKit step count using HKStatisticsCollectionQueryDescriptor with .cumulativeSum. I’m seeing a reproducible issue where daily aggregation returns an empty HKStatisticsCollection for recent step-count data, while hourly aggregation for the same date range can return valid data, and HKSampleQuery can also retrieve the underlying step samples. This does not appear to be an authorization issue, because other HealthKit data types are available and step samples can be read. It also does not appear to be a time zone boundary issue: the device time zone is Asia/Shanghai (UTC+8), and the queried date ranges are local-day ranges such as 2026-06-14 00:00:00 to 2026-06-14 23:59:59. Observed behavior: HKStatisticsCollectionQueryDescriptor for stepCount, intervalComponents = DateComponents(day: 1), returns 0 buckets / 0 total steps. HKStatisticsCollectionQueryDescriptor for stepCount, intervalComponents = DateComponents(hour: 1), can return valid hourly buckets for some dates in the same period. HKSampleQuery for stepCount can retrieve raw step samples for dates where the daily statistics query returns empty. No error is thrown by descriptor.result(for:). The query succeeds but returns an empty statistics collection. Expected behavior: Daily cumulative step-count statistics should include buckets for days that contain step samples, or at least be consistent with the hourly aggregation and raw samples for the same date range. Example logs: [HealthKitSteps] daily statistics result range=2026-06-14 00:00:00...2026-06-14 23:59:59 interval=1d buckets=0 valuedBuckets=0 total=0 [HealthKitSteps] daily statistics result range=2026-06-13 00:00:00...2026-06-13 23:59:59 interval=1d buckets=0 valuedBuckets=0 total=0 [HealthKitSteps] hourly statistics result range=2026-06-09 00:00:00...2026-06-09 23:59:59 interval=1h buckets=9 valuedBuckets=9 total=3379 [HealthKitSteps] hourly statistics result range=2026-06-08 00:00:00...2026-06-08 23:59:59 interval=1h buckets=3 valuedBuckets=3 total=6216 Query details: Quantity type: HKQuantityTypeIdentifier.stepCount Statistics option: .cumulativeSum Daily query interval: DateComponents(day: 1) Hourly query interval: DateComponents(hour: 1) Predicate: HKQuery.predicateForSamples(withStart: startOfLocalDay, end: endOfLocalDay, options: .strictStartDate) Anchor date: startOfLocalDay Device time zone: Asia/Shanghai (UTC+8)
Jun ’26
Reply to WatchOS HealthKit HKObserverQuery crashes in background
@DTS Engineer Yes, we would greatly appreciate if Apple could look into this issue. This crash has already generated tens of thousands of crash reports in our app's backend, and we've also observed several similar crash logs in other health-related apps on Apple Watch. Thank you very much for your attention to this matter. ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Incident Identifier: 74A69084-446E-461C-9401-FC97A426180B CrashReporter Key: 7d3c0ace745a10af53054a01d91601a47d39d41e Hardware Model: Watch7,5 Identifier: com.abc.watchkitapp Version: 2.1.0 (967) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: com.abc.watchkitapp [633] Date/Time: 2025-07-02 20:38:25.6084 +0800 Launch Time: 2025-07-02 19:01:28.0292 +0800 OS Version: Watch OS 26.0 (23R5296f) Release Type: User Baseband Version: Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CAROUSEL 3306925314 CSLHandleBackgroundHealthKitQueryAction watchdog transgression: app< com.abc.watchkitapp((null))>:20784 exhausted real (wall clock) time allowance of 15.00 seconds <FBApplicationProcess: 0x3d81a8480; app< com.abc.watchkitapp>:20784(vE5A4)> Elapsed total CPU time (seconds): 7.600 (user 4.670, system 2.930), 25% CPU Elapsed application CPU time (seconds): 4.427, 14% CPU, lastUpdate 2025-07-02 12:38:10 +0000 <0x0> watchdog transgression. Exhausted wall time allowance of 15.00 seconds.
Jul ’25
Reply to Unable to invalidate interval: no data source available error when fetching steps using HKStatisticsCollectionQuery
@DTS Engineer In my iOS app, I query HealthKit step count using HKStatisticsCollectionQueryDescriptor with .cumulativeSum. I’m seeing a reproducible issue where daily aggregation returns an empty HKStatisticsCollection for recent step-count data, while hourly aggregation for the same date range can return valid data, and HKSampleQuery can also retrieve the underlying step samples. This does not appear to be an authorization issue, because other HealthKit data types are available and step samples can be read. It also does not appear to be a time zone boundary issue: the device time zone is Asia/Shanghai (UTC+8), and the queried date ranges are local-day ranges such as 2026-06-14 00:00:00 to 2026-06-14 23:59:59. Observed behavior: HKStatisticsCollectionQueryDescriptor for stepCount, intervalComponents = DateComponents(day: 1), returns 0 buckets / 0 total steps. HKStatisticsCollectionQueryDescriptor for stepCount, intervalComponents = DateComponents(hour: 1), can return valid hourly buckets for some dates in the same period. HKSampleQuery for stepCount can retrieve raw step samples for dates where the daily statistics query returns empty. No error is thrown by descriptor.result(for:). The query succeeds but returns an empty statistics collection. Expected behavior: Daily cumulative step-count statistics should include buckets for days that contain step samples, or at least be consistent with the hourly aggregation and raw samples for the same date range. Example logs: [HealthKitSteps] daily statistics result range=2026-06-14 00:00:00...2026-06-14 23:59:59 interval=1d buckets=0 valuedBuckets=0 total=0 [HealthKitSteps] daily statistics result range=2026-06-13 00:00:00...2026-06-13 23:59:59 interval=1d buckets=0 valuedBuckets=0 total=0 [HealthKitSteps] hourly statistics result range=2026-06-09 00:00:00...2026-06-09 23:59:59 interval=1h buckets=9 valuedBuckets=9 total=3379 [HealthKitSteps] hourly statistics result range=2026-06-08 00:00:00...2026-06-08 23:59:59 interval=1h buckets=3 valuedBuckets=3 total=6216 Query details: Quantity type: HKQuantityTypeIdentifier.stepCount Statistics option: .cumulativeSum Daily query interval: DateComponents(day: 1) Hourly query interval: DateComponents(hour: 1) Predicate: HKQuery.predicateForSamples(withStart: startOfLocalDay, end: endOfLocalDay, options: .strictStartDate) Anchor date: startOfLocalDay Device time zone: Asia/Shanghai (UTC+8)
Replies
Boosts
Views
Activity
Jun ’26
Reply to WatchOS HealthKit HKObserverQuery crashes in background
@DTS Engineer Yes, we would greatly appreciate if Apple could look into this issue. This crash has already generated tens of thousands of crash reports in our app's backend, and we've also observed several similar crash logs in other health-related apps on Apple Watch. Thank you very much for your attention to this matter. ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Incident Identifier: 74A69084-446E-461C-9401-FC97A426180B CrashReporter Key: 7d3c0ace745a10af53054a01d91601a47d39d41e Hardware Model: Watch7,5 Identifier: com.abc.watchkitapp Version: 2.1.0 (967) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: com.abc.watchkitapp [633] Date/Time: 2025-07-02 20:38:25.6084 +0800 Launch Time: 2025-07-02 19:01:28.0292 +0800 OS Version: Watch OS 26.0 (23R5296f) Release Type: User Baseband Version: Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CAROUSEL 3306925314 CSLHandleBackgroundHealthKitQueryAction watchdog transgression: app< com.abc.watchkitapp((null))>:20784 exhausted real (wall clock) time allowance of 15.00 seconds <FBApplicationProcess: 0x3d81a8480; app< com.abc.watchkitapp>:20784(vE5A4)> Elapsed total CPU time (seconds): 7.600 (user 4.670, system 2.930), 25% CPU Elapsed application CPU time (seconds): 4.427, 14% CPU, lastUpdate 2025-07-02 12:38:10 +0000 <0x0> watchdog transgression. Exhausted wall time allowance of 15.00 seconds.
Replies
Boosts
Views
Activity
Jul ’25