I’m evaluating a native watchOS smart-alarm app and would like to clarify whether public APIs support its core requirement before building a prototype. The app would wake the user during a 20–30-minute window before their selected alarm time, using Apple Watch’s own sleep-stage classifications available through HealthKit’s sleepAnalysis category: Core, Deep, REM, and Awake. I have reviewed HKCategoryValueSleepAnalysis, HKAnchoredObjectQuery, HKObserverQuery, background delivery, and WKExtendedRuntimeSession’s Smart Alarm mode. However, I haven’t found documentation establishing when Apple-generated sleep-stage samples become available during an ongoing sleep session. Could you clarify: Are Apple-generated sleep-stage samples written to the Watch’s local HealthKit store during sleep, or only after the sleep session ends or subsequent processing? If available during sleep, is there any documented update cadence or latency that would make them suitable for a smart alarm? Should the latest sample be treated only as a retrospective classification rather than the current sleep stage? Can an app query these samples during a Smart Alarm extended runtime session while the Watch is worn and unlocked, with its display off and Sleep Focus enabled? Are there relevant execution or data-access restrictions? If this use case is unsupported, is there any public API that exposes Apple’s current sleep-stage estimate? If not, which Feedback Assistant category is appropriate for requesting this capability? The intended approach queries HealthKit directly on Apple Watch, without depending on Watch-to-iPhone synchronization, and retains a fixed latest wake-up time as a fallback. This is an API feasibility question, not a reproduced bug. I haven’t yet built or tested a prototype. Thank you.

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

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

Filed as FB24834050. Still reproducible on watchOS 27.0.1 (24R365). Posting here in case an Apple engineer can help route it, and to see whether other developers are seeing the same behavior through HealthKit. Minimal reproduction (under 3 minutes, no distance involved) Apple Watch Series 10 (GPS) running watchOS 27.0.1 (24R365), paired to an iPhone 15 running iOS 27. Start an Other workout. Move your arms continuously for about 2 minutes (I use air punches). No treadmill, GPS, or distance calculation involved. End the workout and review the heart rate samples. Result: One heart rate sample at approximately 0:05, then no additional samples for the rest of the workout. Expected: Continuous heart rate sampling every few seconds, which is how the same watch behaved on watchOS 26. This reproduces 100% of the time across every workout type I've tried since updating to watchOS 27.0. It did not occur on watchOS 26 using the same watch, same wrist, and same fit. Key diagnostic: the sensor is working, the workout session path is not. The Heart Rate app reads immediately and continues updating every few seconds, even while a workout is running. Background heart rate sampling outside workout sessions works normally. Active energy for my daily 65-minute session is accurate when no workout is started (405 calories on 9/22/26, consistent with watchOS 26). Recording that same session as an Indoor Walk workout results in roughly half the active calories (typically 185-200 versus high-300s/low-400s before the update). Starting a workout appears to suppress a working measurement path and replace it with one that is failing. Downstream impact A 1:06:13 session has been credited as 9, 35, and 55 exercise minutes on different days. Since exercise-minute credit for walking is heart-rate driven, the lack of heart rate samples appears to directly affect exercise credit. Separate issue in the same build (not the subject of this post) Indoor distance is consistently about 50% low. A 1:06:13 walk at a constant 4.1 mph should be 4.52 miles, but the watch reports roughly 2-3 miles even though step counts are correct. The watchOS 27 User Guide describes a redesigned pedometer model using new machine-learning algorithms for treadmill distance. Series 12 and Ultra 4 owners are reporting the same shortfall with matching step counts, including on clean installs, so this does not appear to be hardware-specific. The heart rate dropout reproduces in the Other workout type, which performs no distance calculation, so the two issues appear to be independent regressions. Already ruled out Health details are correct Wrist Detection enabled Power Saving Mode off on both watch and iPhone Heart Rate and Fitness Tracking permissions enabled Motion Calibration & Distance enabled Watch fit and position unchanged Both devices restarted Fitness Calibration Data reset Full unpair/re-pair Multiple workout types tested Pause/resume mid-workout (heart rate briefly shows "Searching" and then drops out again) FB24834050 includes two sysdiagnoses from watchOS 27.0 and currently shows "Recent Similar Reports: More than 10." Status remains Open with no response. Ask Can anyone from Apple confirm whether this is a known/tracked issue? Also, would a sysdiagnose captured using the watchOS logging profile from the Apple bug-reporting site be useful? I'm happy to install the profile, reproduce the issue in under three minutes, and attach fresh logs. I'm also interested in hearing from developers using HKWorkoutSession. Are you seeing the same heart-rate sample gaps on watchOS 27 in your own apps? That would help determine whether this is specific to the Workout app or a regression in the workout session layer underneath it. Thanks!

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.

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.

Hello, I’m investigating CDA XML compatibility with the Health app’s medical document import feature. Health rejects both custom CDA documents and an unchanged public HL7 CCD sample with a generic “No medical documents were found to import” error. Feedback Assistant report: FB25204405. Environment: iPhone 15 Pro Max iOS 27.2 beta 4 (24B5110a) Device language: Hebrew Region: Israel Steps to reproduce: Save a CDA XML document in Files. Open the document’s share sheet and select Health. Health opens but displays an error instead of a document preview or import confirmation. The exact Hebrew error is: “לא ניתן לייבא מסמכים רפואיים” “לא נמצאו מסמכים רפואיים לייבוא.” Approximate English translation: “Unable to Import Medical Documents” “No medical documents were found to import.” For comparison, I also tried the unchanged public HL7 CCD sample containing fictional patient data: https://github.com/HL7/CDA-core-2.0/blob/master/examples/sampleCCD.xml This sample produces the same error. I understand that being an HL7 sample does not necessarily mean it satisfies all of Health’s import requirements. My questions: Is standalone CDA XML import from Files into Health supported through this workflow? Are there specific CDA profiles, header fields, filename extensions, or packaging requirements needed for Health to recognize the document? Has anyone successfully imported a CDA document on this build, or identified a workaround? Is there a recommended way to distinguish a document validation failure from a file recognition or handoff failure? Testing so far has been limited to the Health app’s user interface. I have not tested the document through HKCDADocumentSample in a native app, and I have not established whether this is a regression from an earlier iOS version. I would appreciate guidance on the supported workflow or a public, fictional-data sample known to work with Health. Please do not share real patient records. Thank you.

I am developing a watchOS wellness app with explicitly user-started monitoring during ordinary daily activities. The goal is timely physiological-change check-ins over an approximately eight-to-ten-hour monitoring period, including when the display is off. This is not exercise monitoring or a diagnostic use case. The relevant API sequence is: Create HKWorkoutConfiguration with activityType .mindAndBody and locationType .unknown. Create HKWorkoutSession, its associated HKLiveWorkoutBuilder and HKLiveWorkoutDataSource; set the session and builder delegates. Restrict builder collection to heart rate, then call startActivity(with:) and beginCollection(withStart:). After receiving initial live HR, call HKWorkoutSession.pause(). Receive .heartRate through workoutBuilder(_:didCollectDataOf:) and read statistics(for:), mostRecentQuantity() and mostRecentQuantityDateInterval(). When the user ends monitoring, end collection and discard the workout rather than save it. In development tests on Apple Watch hardware, HR callbacks have continued for hours after pausing, including while backgrounded, with roughly five-second average intervals. Some tests have shown gaps. I do not assume that observing this behavior establishes a supported API guarantee. Is frequent live-builder HR delivery in the paused state officially supported, or is this behavior an implementation detail that an app must not rely on? Is there a supported watchOS API or architecture for this non-exercise monitoring goal, and what are its HR-delivery/background-runtime limits? The app uses HealthKit and HealthKit background-delivery entitlements and the workout-processing background mode. I would also appreciate clarification about possible Activity-ring or energy-calculation effects when the workout is paused and ultimately discarded.I am developing a watchOS wellness app with explicitly user-started monitoring during ordinary daily activities. The goal is timely physiological-change check-ins over an approximately eight-to-ten-hour monitoring period, including when the display is off. This is not exercise monitoring or a diagnostic use case. The relevant API sequence is: Create HKWorkoutConfiguration with activityType .mindAndBody and locationType .unknown. Create HKWorkoutSession, its associated HKLiveWorkoutBuilder and HKLiveWorkoutDataSource; set the session and builder delegates. Restrict builder collection to heart rate, then call startActivity(with:) and beginCollection(withStart:). After receiving initial live HR, call HKWorkoutSession.pause(). Receive .heartRate through workoutBuilder(_:didCollectDataOf:) and read statistics(for:), mostRecentQuantity() and mostRecentQuantityDateInterval(). When the user ends monitoring, end collection and discard the workout rather than save it. In development tests on Apple Watch hardware, HR callbacks have continued for hours after pausing, including while backgrounded, with roughly five-second average intervals. Some tests have shown gaps. I do not assume that observing this behavior establishes a supported API guarantee. Is frequent live-builder HR delivery in the paused state officially supported, or is this behavior an implementation detail that an app must not rely on? Is there a supported watchOS API or architecture for this non-exercise monitoring goal, and what are its HR-delivery/background-runtime limits? The app uses HealthKit and HealthKit background-delivery entitlements and the workout-processing background mode. I would also appreciate clarification about possible Activity-ring or energy-calculation effects when the workout is paused and ultimately discarded.

Hello Apple Developer Relations and the HealthKit team, I'm a hobbyist developer and recreational swimmer building a personal app to make better use of my own Apple Watch workout data. My goal is training management, post-workout reviews, and long-term summaries of my swimming history. Design goal I would like to create a global map of places where I have swum, similar to the map view in Apple Photos: When zoomed out, group locations by country or region and show the number of distinct swimming places, rather than the number of workouts. When zoomed in, reveal individual places and their associated workouts. Venue or water-body names could be added later where they can be reliably identified. For pool swimming, a single location point is sufficient. A route is not required. For open-water swimming, show the place first, then reveal an individual workout's route when selected. Group repeated visits to the same place while retaining each workout for review. Data requirement The key requirement is read-only access to a location associated with an existing workout, including historical pool workouts recorded using Apple's Workout app. A coordinate linked to the workout would be enough to begin with; I am not expecting HealthKit to identify or name the venue. What I have observed In on-device tests, I can read routes for open-water swimming workouts. For the historical pool workouts I checked, no route was returned, and I did not find usable location coordinates in the public workout, activity, event, or route metadata I inspected. However, Apple Fitness displays a map point for historical pool workouts. The absence of a route therefore does not establish the absence of a recorded location. I have read the DTS response explaining that there is currently no public API for third-party access to indoor workout locations: https://developer.apple.com/forums/thread/827939 Current obstacle Without a supported way to obtain these historical points, the app cannot automatically build a useful map of past pool visits. Recording locations from now on or asking users to assign old workouts manually would not recover the existing history. A computer-backup extraction workflow also would not meet the intended standalone iPhone app experience. Questions and enhancement request Beyond the current HealthKit APIs, is there any supported, user-initiated export or import path that preserves historical indoor workout coordinates and their association with the workout? If there is no supported path today, could Apple consider read-only access to historical workout locations through HealthKit, with explicit user authorization and clear handling of missing or approximate locations? I understand that a formal enhancement request belongs in Feedback Assistant. I am sharing this concrete design and data requirement here to clarify the use case and ask whether a supported alternative already exists. Thank you for considering this request.

We depend on the Export PDF button in previous Apple Health apps and it seems to have disappeared in 27.2 beta. Merging FHIR results from multiple hospitals, pharmacies and other patient portals is complex. Apple does an excellent job of merging, categorizing, and displaying this information in the app and it used to generate a great human-readable PDF export. Exporting individual categories as a PDF would be fussy and unreliable for a typical user. Is this regression in the beta an oversight or a strategic shift on the part of Apple to deprive users of an easy to use combined patient summary?

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?

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!

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.

I have 27.2 developer beta running on my iPhone Air and Watch Ultra 4. My wife has an 18 Pro and also Ultra 4 but hers are both running the current public release versions of iOS 27 and watchOS 27. After 2 nights with the Ultra 4's, her sleep score is reporting accurate. Mine is way off. For example, last night we went to bed around 10 PM and woke up at 7 AM. Her scores were in the 90's with 7:36 hours of sleep. Mine is in the 40's with 4:20 hours of sleep. We both slept the same/great last night. Similar results for the night before - hers is accurate; mine are way off.

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.