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

@Quappi did you make sure to enable HealthKit Background Delivery in your Signing & Capabilities tab? I don't remember off hand if you try to enable via code and don't have this setting enabled if you get errors or not. This would be the first thing that I would double check. You should also check the docs about background delivery, not all types deliver in the background immediately.

@lemessurier I would follow the practices outlined in this video: Testing Tips & Tricks If your goal is to test your logic, this is the way to do it. If your goal is to exercise radio functionality and transmit and receive packets, you should use UI Tests and have your physical device in proximity to your CI machine. As you have likely found out, you cannot instantiate a CBPeripheral, nor can you instantiate CBService, CBCharacteristic, and CBDescriptor. If you're really motivated, you could explore using the mac's Bluetooth to emulate your device. You'd need to create a mechanism to control that 'Mac app' from your XCTest suite. FYI, Process isn't available on iOS, thus you can't run command line tools from an iOS XCTest suite to control your Mac app. Maybe you could get it to work with a local HTTP Server and drive it that way.

@Kenn25 Which API are you referring to as the 'HealthKit tracker Id'?

@sgonser which application is the source of the workout? Some apps save segments for both kilometer and miles so that it is quick and easy to fetch later based on the users preference and locale. To your earlier comments and question, this might be why you are seeing segments overlap of segments. Namely the Apple Activity app on watchOS does this. I recorded a walk on a beach in Ireland earlier this year. You can see my pace wasn't very high...there were many interesting shells, rocks, and sealife. So from the image above, the first segment is the first 1 KM, the second is the first 1 MI, third is 2nd KM (remainder), and the fourth is the 2nd MI (remainder). The HKStatisticsQuery API is very powerful. Another approach you could take, given another workout apps segments, compute the sum distance of that segment interval. If it is near 1-mi, you know the segment is a mile, otherwise if it is near 1-km, you know it is kilometers. In terms of determining that last segment, look at the segment before which has an end date that matches or roughly matches the start date of the last segment. Don't do math that looks exactly for 1-KM or 1-MI because the odds of the sample data generating exactly a round number are slim at best.

When you attempt to start a workout from your iPhone on the paired Apple Watch, watchOS will invoke your WKApplicationDelegate. It is up to you with how to process the workout request. It likely wouldn't be appropriate to use HealthKit to trigger this and then not record a workout. You'd have to disclose in your App Store Description that you work with the Health app, you'd have to put that into your privacy policy, have app specific rules, etc. As for 'using HealthKit other than the purposes of HealthKit' See 2.5.1: https://developer.apple.com/app-store/review/guidelines/#software-requirements Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. For example, the HomeKit framework should provide home automation services; and HealthKit should be used for health and fitness purposes and integrate with the Health app. If your app is a fitness recording app, absolutely use this. If not, don't. You could look at pushing a configuration via Watch Connectivity framework and WCSession, but that doesn't guarantee the companion watch will launch either. Another approach you might take is to use Core Bluetooth. Have the watch scan, have the iPhone advertise. Again you're playing games. Your best bet, make an Apple Feedback, make your argument for your use case, and ask them to make an API to launch the watch app outside of HealthKit.

Late to the game but for what its worth: FB15133265 - Swift Data / Swift 6: Create mechanism for object identifier that is 'immutable' that satisfies 'expand accessors on variable declared with let'

I am also experiencing issues with a document based app. My app can open and pull apart .ips crash files, or at least that is the new feature I wanted to launch next week. When I share an .ips file from the Settings app on iOS 17.6.1, it works just fine. When I do the same on either iOS 18 RC or iPadOS 18 RC, my app icon shows in the suggested list of apps to share to, but when I select my app it does nothing. Interestingly, I can still share the file to the Files app, and from there when I use the Files app's share sheet, I can successfully launch and trigger my app to grab the data. FB15131454 - Settings: PRODUCTION ISSUE - Sharing an ips file from device analytics does not open my app on iOS and iPadOS 18 RC, works on iOS 17.6.x *** suggested by @Engineer for completeness, I modified the WritingApp code to support iOS 17 by conditionally compiling all of the views, changing the extension supported to ips and ran it on my iPhone running 17.6.1. While the app doesn't actually do anything with the file, it successfully launches my app from Settings > Analytics. Taking again, the same sample code with modifications, running it on 18 RC, it does not launch the sample application.

I tried again around 8:30 AM Central today, on Sept 10th. The issue still persists. As a workaround I was able to upload a binary that I archived locally with Xcode 16 RC installed on my machine running Sonoma and so far I haven't gotten an automated App Review rejection on my submission so far. They were pretty instantaneous when submitting binaries from Xcode Cloud so I think I'm in the clear. So what is different between Xcode 16 RC in Xcode Cloud and Xcode 16 RC on a local device? Here are all of the DT keys from the app's Info.plist from a local build: <key>DTCompiler</key> <string>com.apple.compilers.llvm.clang.1_0</string> <key>DTPlatformBuild</key> <string>22A348</string> <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>18.0</string> <key>DTSDKBuild</key> <string>22A348</string> <key>DTSDKName</key> <string>iphoneos18.0</string> <key>DTXcode</key> <string>1600</string> <key>DTXcodeBuild</key> <string>16A242</string> And the same from Xcode Cloud: <key>DTCompiler</key> <string>com.apple.compilers.llvm.clang.1_0</string> <key>DTPlatformBuild</key> <string>22A348</string> <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>18.0</string> <key>DTSDKBuild</key> <string>22A348</string> <key>DTSDKName</key> <string>iphoneos18.0</string> <key>DTXcode</key> <string>1600</string> <key>DTXcodeBuild</key> <string>16A242</string> I can't find anything else different in the two resulting archives. The allure to Xcode Cloud is that you don't have to immediately install the latest beta, RC, or public release of Xcode because Apple will. Small price to pay if you want to be a day-zero adopter of iOS 18 I guess. It would be nice to have some more detail on the automated rejection why this is occurring for Xcode Cloud.