Post

Replies

Boosts

Views

Activity

Clarification on HealthKit Observer Delivery Frequency and BGTaskScheduler Behavior
Hi Team, We are implementing HealthKit data sync using HKObserverQuery along with enableBackgroundDelivery and BGTaskScheduler for fallback processing. However, we are observing inconsistent behavior and would like clarification on expected system behavior: For HKObserverQuery: When using enableBackgroundDelivery with frequency .immediate, we sometimes receive updates promptly, but other times we do not receive any trigger at all. Similarly, when using .hourly, our expectation was that updates would be delivered approximately once per hour, but in practice, triggers are delayed, batched, or skipped. For BGTaskScheduler: We are scheduling BGAppRefreshTask with earliestBeginDate set (e.g., 1 hour), but tasks are sometimes delayed by several hours or not triggered predictably. In some cases, tasks are not executed even after extended periods. We would like to understand: Are HKObserverQuery delivery frequencies (.immediate, .hourly, .daily) strictly best-effort hints rather than guaranteed intervals? Under what conditions can observer updates be skipped or significantly delayed? Is there any recommended approach to ensure more reliable periodic syncing of HealthKit data? For BGTaskScheduler, what factors most strongly influence scheduling delays or missed executions? Our goal is to design a reliable sync mechanism, but the lack of deterministic behavior is making it difficult to define expected system behavior. Any clarification or recommended best practices would be greatly appreciated. Thanks in advance!
1
0
72
5d
Clarification on HealthKit Background Access While Device Is Locked
Hello Apple Developer Support / Community, I would like clarification regarding HealthKit data access behavior when an iPhone is locked. We are building an app that uses: HKObserverQuery enableBackgroundDelivery HKAnchoredObjectQuery Background execution to sync HealthKit data to our server Our specific question is: When the device is locked with passcode/Face ID protection enabled, can an app launched in the background through HKObserverQuery or other background mechanisms reliably access and read HealthKit data? We would like to understand the expected Apple-supported behavior for the following scenarios: If new HealthKit samples are written while the phone is locked, will HKObserverQuery still trigger immediately? If the observer callback is invoked while locked, can HKAnchoredObjectQuery successfully read the new samples? Is HealthKit data inaccessible while locked due to Data Protection / encrypted store behavior? Should developers expect delivery or data reads to be deferred until the user unlocks the device? We are trying to set correct expectations for background syncing and would appreciate official clarification on whether near real-time HealthKit sync is possible while the device remains locked. Relevant documentation mentions HealthKit store encryption, but we would appreciate direct confirmation for production behavior. Thank you.
0
0
26
12h
Clarification on HealthKit Observer Behavior in Flutter App vs Native iOS App
Hello Apple Developer Support / Community, I would like clarification regarding HealthKit observer behavior when comparing a Flutter-based iOS app with a fully native iOS app. We are using HealthKit background delivery with: HKObserverQuery enableBackgroundDelivery HKAnchoredObjectQuery We have observed that in a Flutter-based app, HKObserverQuery callbacks appear to execute multiple times or more frequently than expected for a single data update. In comparison, a native iOS implementation using similar HealthKit logic appears more stable and predictable. We would like to understand the expected platform behavior and whether there are any known considerations from Apple’s perspective. Specific questions: Does iOS treat HealthKit observer delivery differently for apps built with Flutter versus fully native UIKit / Swift apps? Are there known issues where app lifecycle handling, Flutter engine initialization, method channels, isolates, or plugin architecture could cause repeated observer callbacks? Can repeated HKObserverQuery executions occur if queries are registered multiple times during app launches or engine restarts? Does Apple recommend any specific observer management pattern for cross-platform frameworks such as Flutter? From the HealthKit system side, should observer callback frequency be identical regardless of whether the app is Flutter or native, assuming the same iOS code is used? We are trying to determine whether this behavior is due to HealthKit delivery semantics, duplicate observer registration, Flutter lifecycle integration, or framework-related limitations. Any guidance from Apple or developers who have implemented HealthKit successfully in Flutter would be appreciated. Thank you.
0
0
82
12h
Clarification on HealthKit Observer Delivery Frequency and BGTaskScheduler Behavior
Hi Team, We are implementing HealthKit data sync using HKObserverQuery along with enableBackgroundDelivery and BGTaskScheduler for fallback processing. However, we are observing inconsistent behavior and would like clarification on expected system behavior: For HKObserverQuery: When using enableBackgroundDelivery with frequency .immediate, we sometimes receive updates promptly, but other times we do not receive any trigger at all. Similarly, when using .hourly, our expectation was that updates would be delivered approximately once per hour, but in practice, triggers are delayed, batched, or skipped. For BGTaskScheduler: We are scheduling BGAppRefreshTask with earliestBeginDate set (e.g., 1 hour), but tasks are sometimes delayed by several hours or not triggered predictably. In some cases, tasks are not executed even after extended periods. We would like to understand: Are HKObserverQuery delivery frequencies (.immediate, .hourly, .daily) strictly best-effort hints rather than guaranteed intervals? Under what conditions can observer updates be skipped or significantly delayed? Is there any recommended approach to ensure more reliable periodic syncing of HealthKit data? For BGTaskScheduler, what factors most strongly influence scheduling delays or missed executions? Our goal is to design a reliable sync mechanism, but the lack of deterministic behavior is making it difficult to define expected system behavior. Any clarification or recommended best practices would be greatly appreciated. Thanks in advance!
Replies
1
Boosts
0
Views
72
Activity
5d
Clarification on HealthKit Background Access While Device Is Locked
Hello Apple Developer Support / Community, I would like clarification regarding HealthKit data access behavior when an iPhone is locked. We are building an app that uses: HKObserverQuery enableBackgroundDelivery HKAnchoredObjectQuery Background execution to sync HealthKit data to our server Our specific question is: When the device is locked with passcode/Face ID protection enabled, can an app launched in the background through HKObserverQuery or other background mechanisms reliably access and read HealthKit data? We would like to understand the expected Apple-supported behavior for the following scenarios: If new HealthKit samples are written while the phone is locked, will HKObserverQuery still trigger immediately? If the observer callback is invoked while locked, can HKAnchoredObjectQuery successfully read the new samples? Is HealthKit data inaccessible while locked due to Data Protection / encrypted store behavior? Should developers expect delivery or data reads to be deferred until the user unlocks the device? We are trying to set correct expectations for background syncing and would appreciate official clarification on whether near real-time HealthKit sync is possible while the device remains locked. Relevant documentation mentions HealthKit store encryption, but we would appreciate direct confirmation for production behavior. Thank you.
Replies
0
Boosts
0
Views
26
Activity
12h
Clarification on HealthKit Observer Behavior in Flutter App vs Native iOS App
Hello Apple Developer Support / Community, I would like clarification regarding HealthKit observer behavior when comparing a Flutter-based iOS app with a fully native iOS app. We are using HealthKit background delivery with: HKObserverQuery enableBackgroundDelivery HKAnchoredObjectQuery We have observed that in a Flutter-based app, HKObserverQuery callbacks appear to execute multiple times or more frequently than expected for a single data update. In comparison, a native iOS implementation using similar HealthKit logic appears more stable and predictable. We would like to understand the expected platform behavior and whether there are any known considerations from Apple’s perspective. Specific questions: Does iOS treat HealthKit observer delivery differently for apps built with Flutter versus fully native UIKit / Swift apps? Are there known issues where app lifecycle handling, Flutter engine initialization, method channels, isolates, or plugin architecture could cause repeated observer callbacks? Can repeated HKObserverQuery executions occur if queries are registered multiple times during app launches or engine restarts? Does Apple recommend any specific observer management pattern for cross-platform frameworks such as Flutter? From the HealthKit system side, should observer callback frequency be identical regardless of whether the app is Flutter or native, assuming the same iOS code is used? We are trying to determine whether this behavior is due to HealthKit delivery semantics, duplicate observer registration, Flutter lifecycle integration, or framework-related limitations. Any guidance from Apple or developers who have implemented HealthKit successfully in Flutter would be appreciated. Thank you.
Replies
0
Boosts
0
Views
82
Activity
12h