As an experiment, I would query the historical pedometer data from Core Motion (7-days history, I think), and compare that to the steps you're seeing in Pedometer++. In the fitness app I wrote, the device automatically captures data from the pedometer and saves it to Apple Health / HealthKit, the question is, is there any quality of service going on to screen out bad or otherwise data from the pedometer? I can't speak to the app authors implementation, but he could be using the pedometer API in conjunction with HealthKit. The app does request access to motion permissions, so it is a real possibility. Presumably Pedometer++ is just using the statistics query but you'd have to ask them and see if they'd share details if you're using this as a point of reference.

@Jaroslav_the_healthy My guess is that this is due to your predicate options. Play with the .strictStartDate and .strictEndDate. As an experiment, change from .strictStartDate to .strictEndDate and see if the issue goes to the tail of the data instead. Look at the actual basal samples saved in health kit near the hour mark and I bet you will find some that are overlapping before and after the hour. At least that is where I would start looking.

@haozes you didn't mention if this was beta or not, so I can't speculate how related this is. I have noticed on iOS26 beta 2, that workout route builder does not let me insert route data during an active HKWorkoutSession and collection started HKLiveWorkoutBuilder. If Apple is using the same API in the fitness app, and you're on beta, perhaps these are two in the same? Just in case: https://developer.apple.com/forums/thread/791715 FB18603581 - HealthKit: HKWorkoutRouteBuilder insert call within CLLocationUpdate task never returns

@Quappi, I do not have an answer, however, because the type is a HKCategoryType and the frequency of the data being saved should be low, it would be reasonable to assume that .immediate would behave the way you expect--immediate when on device. I seem to recall the behaviors of some of the quantity samples are these buckets as you have described: immediate 10-minute hourly daily weekly I don't remember if the 10-minute bit was knowledge from a WWDC lab, or trial and error experimentation with workout APIs. Ever notice how Apple Watch will ask you if you're working out roughly after 10 minutes of walking?... HKQuantityTypes have an aggregation style property, there is no reason that health types couldn't have a property to represent the fastest allowed background update frequency. FB18604790 - HealthKit: Create new API for developers to check the minimum allowed update frequency for background updates, or robust documentation per-sample type #feedbackfriday

If anyone at Apple is looking, or others are curious and want to try and reproduce this and share, I believe I figured out the cause. Background: So my app captures MetricKit payloads and saves them into CoreData / SwiftData locally. After a period of time, I ship the payloads to CloudKit. This works for all of my other apps as I mentioned, my container entitlements are setup just fine, this new app has worked in the past, etc. Cause: It appears that when I use Xcode to download the container of my app, and then restore it, that there is some residual data in this process that causes the issue. In the container I found a few directories called MMCS in CloudKit and deleted them, then restore the container to my device(s). After doing this, it worked. It looked something like this: Container > AppData > CloudKit > Random Folder Identifier 1 > MMCS Container > AppData > CloudKit > Random Folder Identifier 2 > MMCS For safe measure I deleted other directories which was likely an unnecessary action as they appear to be artifacts of other frameworks, such as WeatherKit (Caches/weather-data.db and Caches/geocode_wk.db). This is still an issue however, because many developers will take snapshots of their files this way to perform Core Data / Swift Data migration tests on their devices.

Checkout this sample code: https://developer.apple.com/documentation/corelocation/monitoring-location-changes-with-core-location Associated with the talk here: https://developer.apple.com/videos/play/wwdc2023/10147 Referenced from Adam's WWDC24 talk here: https://developer.apple.com/videos/play/wwdc2024/10212 Code change necessary Add NSLocationRequireExplicitServiceSession as a Boolean to your app's Info.plist as the sample code shows.

I haven't been able to find any supporting evidence that this is possible given the current API. FWIW, Apple likes Feedback. @alpennec @michael.h I suggest you file your own, feel free to mention mine so they can mark as related. Here is my Feedback # FB16218331 - Core Location: CLLocationUpdate doesn't have mechanism for influencing the 'filter accuracy' like CLLocationManager does - add functionality to API FB16226614 - Core Location: CLLocationUpdate doesn't have mechanism for influencing the 'filter distance' like CLLocationManager does - add functionality to API

This is still an issue for me. Has anyone else encountered indexes not updated in CloudKit public database? I'd hate to just burn a DTS for this.

This was an issue on my end that I didn't catch until now. In adding Shortcuts support earlier this summer I had to rename my Product Name to include a space due to how the system renders things. So my filters needed updating.

I have noticed a significant drop out in metric payloads on my local test devices since iOS 18. I am not reliably getting payloads either. I plan to visualize my payload reports over the last 6 months to show the count for my devices bottoming out around mid September. FB15461298 - MetricKit: Production issue / regression with iOS 18 - Significant dropout or metric payloads being generated since 18.0 - nearly no reports I will share my visuals here too as a reference once I have them.

Apple added some more new features related to sleep apnea without any documentation: Sleep Apnea Event Apple Sleep Breathing Disturbances Hopefully all of these types get documented soon before they exit beta and clean up the types that were launched in September.

As for which types support this capability, check out the HKLiveWorkoutDataSource and inspect the types to collect property. You'll find that the types described by @DTS Engineer are consistent with this approach to double check. Looking at a workout that Apple Activity app recorded, the 'effort sample' start and stop date are consistent with the workout duration. Estimated effort score (3). Start 9:08:21 PM End 9:32:15 PM Saved 9:32:15 PM Workout Start 9:08:20 PM End 9:32:15 PM Saved 9:32:20 PM If I find some time I'll inspect the milliseconds for these dates and identify the exact order. I'm curious of there is a timing issue between stopping a workout session, stopping the builder, and ending the session. Like it generates a sample AFTER the builder collection has completed and then gets dropped. It is not exactly easy to record a real workout with the debugger attached or firing up console to sniff out logs. I plan to rewrite all of my code using the async flavor of the APIs where possible instead of nested closures to see if that makes a difference. I can't wait for HKWorkoutSession and HKWorkoutBuilder to be actors and fully async (hopefully in the future)! FB15315876 - Documentation / HealthKit: Publish documentation about .workoutEffortScore and .estimatedWorkoutEffortScore

Since it was introduced last summer, it hasn't worked for me on the simulator like it does on real devices. I have defaulted to just developing with this capability on real devices. June 2023 FB12328242 - Health / Simulator: New mirrored workout session sendData throwing 'host device not connected' for watchOS and iOS simulators July 2024 FB14310200 - HealthKit / Simulator: workoutSessionMirroringStartHandler function is not invoked when mirroring Apple Watch simulator to iPhone simulator in Xcode 15

@PurrProgramming officially voice your feature request to read (and write) this data via Feedback Assistant. Apple, here is my feedback # FB15382945 - HealthKit: Give third party developers access to the internal heart rate zones recorded and associated with Activity app workouts

I want this too. Apple, we like making workout apps for your platform, clearly, you like to tell us each year how many health and fitness apps there are. Open up heart rate zone APIs and management with respect to workouts to third party developers. It has been a few years for you to stabilize the feature and internal API to make ready for public! The speed of which Apple Fitness on iPhone can calculate heart rate zones is within a moment, at present, fetching all heart rate samples associated to a workout and computing the time in each zone is an order of seconds. Evidently, Apple is writing this data privately in HealthKit because you wouldn't be saving health and fitness data outside of HealthKit db, right? FB15382945 - HealthKit: Give third party developers access to the internal heart rate zones recorded and associated with Activity app workouts Years ago, I found via printing metadata on workouts saved by Apple's Activity app on Apple Watch that they were saving metadata keys and structures using _HKPrivateMetadata***. I have a feedback I wrote years ago about workout splits, but I can't find anything about heart rate zones, but it still feels familiar from the summer they introduced it. For the time being, @ravdamani @simonfromhelix and any other third party developer, do you have interest in contributing to an open source 'third party metadata' keys swift package? The issue with metadata, custom keys that is, is other apps including Apple's Health app can't know about localization or appropriate meaning. For example, I allow my users to differentiate between canoeing and kayaking, and for the time being until Apple decides to split them into two different activity types (FB7807902 - June 2020). I wanted to use a key 'HKMetadataKeyPaddleSportsType' BUT, that doesn't localize at all and is confusing to users in other apps. I balanced this with usability for English by declaring the key name as 'Paddle Sports Type'. The first feedback below would mitigate that, but it isn't really in the spirit of sharing that Apple teaches health developers to follow. The second additional feedback is related to those private metadata. Just try saving any of these keys: _HKPrivateMetadataSplitActiveDurationQuantity _HKPrivateMetadataSplitDistanceQuantity _HKPrivateMetadataSplitMeasuringSystem Private API? No, it is a string value provided to a dictionary that should accept any string. Private Usage? Yes, this will crash your code at runtime. Related: FB15053061 - HealthKit: Allow third party developers to create hidden metadata that can only be read by apps that belong to the same TeamID that generated the sample FB15052902 - HealthKit: Custom metadata keys are being rejected with an undocumented error