Hello, I have submitted multiple requests for the Family Controls Distribution Entitlement through this form: https://developer.apple.com/contact/request/family-controls-distribution After submitting my requests, I waited for about 1 week but did not receive any response. Since I heard nothing, I contacted Apple Developer Support by email. After that, I finally received a response from an advisor asking for additional information, including my follow-up number. I replied with all the requested information immediately, but it has now been 5 more days and I still have not received any further response. In total, I have been waiting for about 2 weeks for this entitlement request. My app is a Screen Time control / digital wellbeing application that helps users reduce screen time through exercise-based challenges and healthy habits. My app uses the FamilyControls, ManagedSettings, and DeviceActivity frameworks and requires the Distribution Entitlement for App Store release. Here are my details: Case Number: 102866460896 Request Type: Family Controls Distribution Entitlement I understand the team may be busy, but I would appreciate any help checking the status of my request or escalating it if possible. Thank you very much.

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 building an iOS mobile application using Flutter, with native Swift integration for accessing Apple HealthKit instead of a Flutter plugin. The primary goal is to capture and sync specific HealthKit data types, namely Respiratory Rate and Sleeping Wrist Temperature, and send this data to a backend API as close to real-time as possible after it is written to HealthKit. The application needs to support both foreground and background syncing. Data should be synced when the app is opened, but also in the background when the device is locked. Additionally, there are reliability constraints to consider: the user may not open the app for extended periods, the device may remain locked, and Low Power Mode or other system restrictions may impact background execution. I have explored a few possible approaches. One option is using BGTaskScheduler to periodically fetch and sync data. However, based on my understanding, background tasks are not guaranteed to execute frequently and may be throttled or stopped by the system after some time. Another approach is to use HKObserverQuery along with HKAnchoredObjectQuery. In this setup, observer queries would be registered for the required data types, background delivery would be enabled, and whenever triggered, anchored queries would fetch incremental updates which would then be sent to the backend. This seems closer to a real-time model, but I am unsure how reliable and timely these background updates are in practice. I have also looked into newer APIs like HKQueryDescriptor, but it is not clear whether they provide any advantage over the observer plus anchored query approach for this use case. My main questions are: what is the recommended architecture for achieving near real-time syncing of HealthKit data for these metrics? Does HealthKit background delivery provide any guarantees or expectations around delivery timing, or can updates be significantly delayed depending on system conditions? How should edge cases be handled, such as when the device remains locked for long durations or when Low Power Mode is enabled? Would it be advisable to combine observer queries with BGTaskScheduler as a fallback mechanism? Finally, apps like Athlytic appear to show updated data immediately when opened. I am curious whether this is primarily achieved through background delivery or by fetching data on demand when the app becomes active. The goal is to design a system that is as close to real-time as possible while remaining reliable and compliant with iOS background execution constraints. Any recommended patterns, best practices, or references would be greatly appreciated.

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.

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.

In the last few weeks 5 users have reported my workout watch app being unable to read health data despite the permissions being enabled in the iPhone Settings app. This has been a common complaint over the years and is usually fixed by disabling the permissions; rebooting both devices; and then enabling them again. This usually nudges iOS into sending the permissions to watchOS. However that procedure doesn't work for these users, all of whom are using watchOS 10.6.2. They are using various versions of iOS 18 or 26 so it seems to be a problem with that version of watchOS, which users are usually limited to because their hardware won't support anything more up to date. It seems that unpairing and re-pairing the watch can fix the problem but not always. I looked around and it seems that other apps are having the same problem: https://www.reddit.com/r/runna/comments/1rhhs2n/runna_wont_start_an_outdoor_run_on_apple_watch/ Does anyone know a way to fix this? My current advice is to repeatedly unpair / re-pair until it works, which isn't really practical! Thanks in advance.

Hi all, I'm building a coaching app for runners on top of WorkoutKit and would like to confirm a missing API — or learn that I overlooked something. The gap IntervalStep transitions deliver a haptic at T0 of the next step. The available alerts (HeartRateRangeAlert, SpeedRangeAlert, PaceRangeAlert, PowerRangeAlert, CadenceRangeAlert) are reactive — they activate when the measured value leaves the target range, not ahead of a planned step. There is no API for a "pre-roll" haptic at, say, T-15s before a high- effort step. On watchOS today, the only signal arrives exactly at step start. What I checked The WorkoutAlert protocol and concrete types — all metric-driven, no scheduling primitive. IntervalStep initializer — (.work, step: WorkoutStep). No leadTime, warning, countdown, or prepareDuration parameter. CustomWorkout — no per-step pre-roll knob. WorkoutScheduler and the rest of the surface in iOS/watchOS 26.4 SDK. If I missed something obvious, please point me at it. Filed with Apple Feedback ID: FB22708659 Has anyone here found a cleaner workaround, or seen any signal from the WorkoutKit team about pre-roll cues being on the roadmap? Thanks!

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.

Hello, I'm experiencing a bug on iOS 26.5 RC1/RC2 where the Blood Pressure option is silently excluded from the HealthKit permission dialog (when requesting HKQuantityTypeIdentifierBloodPressureSystolic and HKQuantityTypeIdentifierBloodPressureDiastolic). This does not reproduce on iOS 26.4.2 or earlier. What happens: When BP types are requested alone, a blank white modal slides up and immediately dismisses — no permission UI is shown. When BP is requested alongside other types, a normal dialog appears for those other types, but Blood Pressure is simply absent from the list. The completion handler returns success = YES, error = nil in both cases, but BP permission is never granted. The result: Settings → Privacy & Security → Health → [app] shows Blood Pressure as requested but not granted getRequestStatusForAuthorizationToShareTypes for the BP types keeps returning ShouldRequest indefinitely HealthKit queries for BP samples return no data Workaround: Manually toggling Blood Pressure to ON in Settings → Privacy & Security → Health → [app name] fixes everything - queries work, notifications fire, and getRequestStatusForAuthorizationToShareTypes correctly returns HKAuthorizationRequestStatusUnnecessary. Environment: Confirmed broken: iOS 26.5 RC1 (23F75) and RC2 (23F77), iPhone 11; iOS 26.5 RC1 (23F73), simulator Confirmed working: iOS 26.4.2 (device), iOS 26.4.1 (simulator) Feedback filed as FB22735935.

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.