I'm adding Weather info to my workout app. The documentation for HKMetadataKeyWeatherHumidity states that the unit is percentage humidity. https://developer.apple.com/documentation/healthkit/hkmetadatakeyweatherhumidity HKUnit.percent() has valid values from 0.0-1.0 inclusive. https://developer.apple.com/documentation/healthkit/hkunit/1615517-percent For a given humidity of 61% (i.e. 0.61 from my server), I'm saving the following quantity: metadata[HKMetadataKeyWeatherHumidity] = HKQuantity(unit: .percent(), doubleValue: humidity) builder.addMetadata(metadata) { } The health app is interpreting this at 1% humidity (school kid rounding) 0.61 -- 1% and 0.41 -- 0%. When I print the humidity quantity of a workout recorded by Fitness app on Apple Watch, I see the value as 6100 %. Meanwhile, quantity.doubleValue(for: .percent()) prints out 61.0. Seems that the Health app is scaling by a factor of 100. Has anyone else integrated humidity into their HealthKit compatible app? How were you saving it to make sure it displayed correctly in the Health app. I'd hate to account for this, only to find out it is a bug and have apple change their logic in the app.

I have a record type called ContactInformation that has phone and email as fields. This record type also has two references that point to different types. Namely type1 and type2 for illustration (one is a person reference, another is a place reference). When I seed my application I do a blind query operation to get all records. I don't think there is a way to perform a query using a predicate where the field isn't nil but thought I'd pose the question to the forums. The idea would be query where type1 != nil and then a second one where type2 != nil. Using CloudKit Console doesn't receive any results when running the following queries so I don't think this is supported as of today. CloudKit Console provides the following error when a reference filter by is applied with empty value: invalid id string: empty As a work around, I could create a 'dummy/default' reference id then the != "dummy identifier" would in theory work but it feels very hacky. Has anyone found a more elegant solution than to use a dummy reference ID? I filed this feedback requesting the ability to create a predicate that supports nil values: FB9833175

Xcode 14 beta 1 is yelling at me that CKNotification initializer should return a non-optional value. This happens only AFTER letting Xcode upgrade my project settings. The change that the upgrade project settings made was it merged my WatchKit and WatchKit extension targets into a single watch app target. After doing so, this code will not compile which I know to be good. // This line fails to compile with ' if let notification = CKNotification(fromRemoteNotificationDictionary: userInfo) { // Do something } Compile error: "Initializer for conditional binding must have Optional type, not 'CKNotification'" Feedback w/ sysdiagnose: FB10282805 - watchOS / CloudKit: CKNotification doesn't return optional, xcode build failing after updating project settings for Xcode 14 I could not reproduce this in a sample application. I tried making a standalone watch app with Xcode 13, upgrading the project file with Xcode 14 beta, and then creating a CKNotification object--but that worked fine. :/

I would like to socialize the idea of starting a Live Activity while the app is in the background. According to the ActivityKit, documentation, Live Activities can only be started while your app is foreground. I wrote up a really lengthy feedback about this enhanced ActivityKit permission concept but will summarize to share with others here. FB11308611 The idea is this, like CoreLocation, the ActivityKit framework could have the permission model of 'when in use' and 'always'. Apps that the user has granted the 'always' permission for would then be allowed to start an activity from some sort of background execution. I'm looking at the Background Modes defined in Xcode namely: Location Updates, Bluetooth, Remote Notifications, Nearby Interactions, etc. My specific use case is to combine my usage of Core Location Region Monitoring and Visit Monitoring into triggering a Live Activity to the users Lock Screen when they are at a place contextually relevant to my app(s). I can imagine this applies to many other applications too. While the current experience I have will present the user with a local notification gets the job done, the user experience could be so much more engaging. When I saw the Live Activities feature get announced during WWDC22, this was the first thing that came to mind. FB11308699 Some very high level concepts: Live Activity when entering a sport stadium Live Activity when entering a concert venue Live Activity when entering a gym Live Activity when entering a restaurant Live Activity when entering a store Got another use case? Share it! Like a use case in this thread? Comment on it!

I've been getting duplicate visits sent to my CLLocationManagerDelegate. This is new since iOS 16, I did not see this behavior in iOS 15--the observed effect is a quite severe regression in the behavior of CoreLocation. Here is what I'm seeing: The visits have already been delivered When they're sent 'again', they're sent in dozens of callbacks When they're sent 'again', they're sent in batches irrespective of app state I have had a debug app on my phone running since November to capture sysdiagnose for FB12107066. My app simply records data from CoreLocation into a mini Core Data table. Since November 11th, I have had 3808 visits, but when I do some distinct queries on arrival and departure I get a fraction of that. Select distinct arrivalDate: 929 Select distinct departureDate: 799 Select distinct arrivalDate + departureDate: 1172 I wrote some logic to attempt to deduplicate and filter out garbage visits that have already been delivered to me, but my filtering isn't bullet proof. This issue has been happening for me on multiple devices since Nov (iOS 16.2 days?). This happens on an iPhone 13 Pro and an iPad Pro 11-inch (4th gen). This is a real nasty bug as it also keeps waking my app up in the background when I don't expect it to since the OS is delivering me old / replay visits. :/ Has anyone else seen issue with the Core Location Visit API in iOS 16? What deduplication and filtering logic did you come up with? While the issue is affecting me via CoreLocation, I would suspect the same might also occur for anyone using the visits API in SensorKit too.

Hey everyone, From WWDC23 lab conversations, in order to run a fitness app, health tracking apps, etc. on iPadOS 17 that 'requires' health, you actually have to remove the UI Required Device Capabilities for Health. The UIRDC will still prohibit the app from running on iPad this fall even though from a developer lens it is satisfied. I understand this is to allow iPhone apps a chance to upgrade and get ready for iPadOS 17, but there isn't a path forward if an app truly requires HealthKit. Namely for fitness apps that ONLY read and or write data to Health. Sure I could move my target SDK to 17, but that doesn't help my existing users who can't upgrade on iOS < 17. What is the path forward for Apps that want to target something like the following? iOS 14+ watchOS 7+ iPadOS 17+ Socializing the idea of having an App Store Connect feature or checkbox to allow / opt into being available on iPadOS 17+. The same applies for App Clips that also require HealthKit. FB12327957 - Health / App Store Connect: Ability to make HealthKit required on iPadOS and iOS together

I'm trying to download artifacts from some recent Xcode Cloud builds. In both Xcode and App Store Connect I'm getting errors. Xcode says: "Error Fetching Test Results: API Invalid status code: 501. App Store Connect says: "artifacts could not be found." FB13773789 - Xcode Cloud: Service returning 501 in Xcode when trying to view artifacts of successful build from minutes ago I have tried several projects to rule out project specific issues and it is happening to all of my Xcode Cloud enabled projects. Both Xcode 15.3 and 15.4 beta exhibit this behavior. Is anyone else running into this issue? I noticed it yesterday, and it continues into this morning.

I'm running into an error in Xcode 16 beta 4 where the compiler can't type check what appears to be a simple @FetchRequest. I have the following Core Data types: Establishment name website etc. locations (relationship, to many, optional) Location name address establishment (relationship, to one, non-optional) In one of my SwiftUI views I have the following @FetchRequest and SortDescriptors. Unwrap required because 'core data' optional types. It looks based on the swift lang key-path expression docs that this should be allowed. Build and run works, but archiving does not. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/expressions/#Key-Path-Expression In practice it won't be nil and validation should prevent it too so I could force unwrap the relationship property, but, defensive coding I want to make it safe as I can. @FetchRequest( sortDescriptors: [ SortDescriptor(\Location.establishment?.name, order: .forward), SortDescriptor(\Location.city, order: .forward), SortDescriptor(\Location.state, order: .forward) ] ) private var locations: FetchedResults<Location> This worked fine with Xcode 15.x, but fails to archive in Xcode 16 beta 4. The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions When I remove the first sort descriptor it works. When I force unwrap the optional key path property it works. Does anyone know of a documented change that would make this no longer work? FB14515958 - SwiftUI: SortDescriptor cannot archive in Xcode 16 beta 4 but works in Xcode 15.4 For clarity, this archives fine, note the force unwrap. @FetchRequest( sortDescriptors: [ SortDescriptor(\CraftTaproom.brewery!.name, order: .forward), SortDescriptor(\CraftTaproom.city, order: .forward), SortDescriptor(\CraftTaproom.state, order: .forward) ] ) private var taprooms: FetchedResults<CraftTaproom>

Apple's sample code 'Trails' supports multiple scenes, however everything is using shared state across the scenes. Put the app in Split View mode and have two windows of the app running and navigate, you can see both mirror each other. Works as designed, it is using a shared 'navigation model' across all scenes. https://developer.apple.com/documentation/appintents/acceleratingappinteractionswithappintents I would like to know if there is a supported or recommended way to modify individual scene storage from within the perform body of an AppIntent. The objective is to have App Shortcuts that launch different tabs in a TabView or different selections in a List. In short, I want to deep link to features, but account for more than one scene being open on iPad and only have programatic navigation happen on the scene that is 'foremost' or the 'activated' one in Split View. I have it working with either a @Dependency or posting a Notification with my main ContentView listening to the other end, but it changes all scenes.

I noticed last night that workouts I have been recording on my main carry device running 17.6.x have not been syncing to my beta devices running iOS 18 RC, iPadOS 18 RC and watchOS 11 RC. All devices are using the same Apple Account and I have iCloud enabled for Health data. The iPad running the RC has the syncing enabled in Profile. Is anyone else experiencing health data not propagating to the 18.x devices? Some of data exists on all devices but not all. For good measure I left the device unlocked on the health app last night for a long period of time to let it do its thing. This morning the data still hadn't propagated. I disabled and reenabled the synchronization on my iPad having chosen to delete all samples when disabling it. Hopefully all of my data dating back to the first Apple Watch in 2014 restores. FWIW my data set according to iCloud settings my health dataset is just shy of 650 MB. FB15102443 - Health / HealthKit: Workouts, activity rings, sample data, and more not syncing via iCloud to 18 RC device

I am encountering issues on my device running iOS 18 that fetching heart rate samples associated to a given workout is very slow. Like 10+ seconds slow. This is unacceptable and unexpected. In producing a video to attach to a feedback, I also observed that Apple Health app displays incorrect information if a workout effort score is associated to a workout. In this image, you can see the Health app bug: Total Resting Energy != Estimated Workout Effort Score Here is the same workout after I delete the workout effort score using the Apple Health app: Can anyone else see if attempting to view 'heart rate' data within the workout summary in Apple Health is unbearably slow if that workout also has an effort score associated? My steps: Record workout (Apple Activity app on watchOS) Associate effort score View the workout on Apple Health (iOS) Attempt to view it's heart rate samples Observe very slow loading times Observe the incorrect cell label and value and disappearance of resting energy cell data Remove/disassociate the effort score from the workout by tapping the workout effort row, and swipe to delete the value. Navigate back, navigate back, and then go into the workout detail again At this time the UI fixes itself, but the loading of heart rate data is still super slow FB15269657 - HealthKit: Sample query to fetch heart rate samples associated to a workout is taking over 10 seconds - computing 'time in heart rate zone' FB15278790 - Health: Workout summary 'Total Resting Energy' label has value of 'Estimated Workout Effort Score' for a value, pushed view shows empty

Apple is using the RPE scale for workout effort scores. This stands for the Rate of Perceived Exertion. They're specifically using the CR-10 scale, at least from what I can tell by saving values to HealthKit. They only accept value between 0 and 10. Has anyone been able to find a scientific or academic paper on how they have chosen their different effort breakouts? Right from the Fitness app on iPhone and Activity app on Apple Watch: 1-3 Easy 4-6 Moderate 7-8 Hard 9-10 All Out There is zero documentation on these new types, which makes it difficult for workout recording apps to properly and appropriately save this new data type. Sure, we can use the Apple apps as a reference, but since there isn't a built-in Apple SwiftUI sheet to present this data, and no references to academia to point our users to, our solutions would just look the same. FB15315876 - Documentation / HealthKit: Publish documentation about .workoutEffortScore and .estimatedWorkoutEffortScore FB15316109 - Documentation / HealthKit: Add documentation to .estimatedWorkoutEffortScore and .workoutEffortScore that you can't save those samples via the save API and that they must be related and let that API save the sample FB15316251 - Documentation / HealthKit: Add documentation for acceptible values of .estimatedWorkoutEffortScore and .workoutEffortScore - don't rely on a runtime error! Apple missed making an enum for all third party developers this year.

I am very happy to see that HealthKit with OS26 is bringing HKLiveWorkoutDataSource to iOS and iPadOS. I have been replicating a similar type for the last several years for users that only have an iPhone. I did notice that the data types that the different platform data sources collect automatically is different. That makes sense if you think exclusively about what the device can actually capture. Bluetooth HRM is the only Bluetooth SIG profile that is out-of-the-box supported for Apple Health on iOS and iPadOS (right?). Whereas watchOS 10 got all of the cycling sensors (woohoo!). It would be great if the types to collect were the same across platforms even if the device couldn't collect the data now, because then in the future when / if new sensor support is added, it will be transparent to developers. Fantastic. Easier life as an indie / third party developer. At least that is the idea. And yes, I know I can also write Core Bluetooth code and roll my own SIG implementation for the cycling profiles, but Apple already has this code in one os, 'just copy it, it will be easy'. I know that isn't the reality especially against the new ASK framework, but one can hope and dream right? Imagine how many more apps would contribute that data if it was supported out of the box. An alternative, GitHub is a great place for Apple to share their Core Bluetooth implementation of the SIG profiles :). Just another thought. Here are some feedbacks related to this: FB17931751 - HealthKit: Add built-in support for cycling sensors on iOS and iPadOS - copy paste the code from watchOS. It will be easy they said (June 2025) FB12323089 - CoreBluetooth / Health / Bluetooth Settings: Add support for cycling sensors announced in watchOS 10 to iOS and iPadOS 17 (June 2023) FB14311218 - HealthKit: Expected outdoor cycling to include .cyclingSpeed quantity type as a default HKLiveWorkoutDataSource type to collect (July 2024) FB14978701 - Bluetooth / HealthKit / Fitness: Expose information about the user specified for Apple Watch paired Cycing Speed Sensor like isConnected and wheelCircumference values (August 2024) FB18402258 - HealthKit: HKLiveWorkoutDataSource should collect same types on iOS and watchOS even if device cannot produce data today (June 2025) FB14236080 - Developer Documentation / HealthKit: Update documentation for HKLiveWorkoutDataSource typesToCollect for which sample types are automatically collected by watchOS 10 and 11 (July 2024) Tangentially related: FB10281304 - HealthKit: Add HKActivityTypes canoeBikeRun and kayakBikeRun (June 2022) FB10281349 - HealthKit: Add HKActivityType walkCanoeWalk and walkKayakWalk (June 2022) FB7807993 - Add HKQuantityTypeIdentifier.paddleDistance for canoeing, kayaking, etc type workouts (June 2020) FB12508654 - HealthKit / Settings / Bluetooth / Workouts: Cycling sensor support doesn't allow for 'bike selection' in use case of multiple bikes and multiple sensors (borrow a bike to ride together) - production usability issue (July 2023)

Has anyone had success using the HKWorkoutRouteBuilder in conjunction with the new iOS support for HKLiveWorkoutBuilder? I was running my watchOS code that worked now brought over to iOS and when I call insertRouteData the function never returns. This happens for both the legacy and closure based block patterns. private var workoutSession: HKWorkoutSession? private var workoutBuilder: HKLiveWorkoutBuilder? private var serviceSession: CLServiceSession? private var workoutRouteBuilder: HKWorkoutRouteBuilder? private func startRouteBuilder() { Task { @MainActor in self.serviceSession = CLServiceSession(authorization: .whenInUse) self.workoutRouteBuilder = self.workoutBuilder?.seriesBuilder(for: .workoutRoute()) as? HKWorkoutRouteBuilder self.locationUpdateTask = Task { do { for try await update in CLLocationUpdate.liveUpdates(.fitness) { if let location = update.location { self.logger.notice(#function, metadata: [ "location": .stringConvertible(location) ]) try await self.workoutRouteBuilder?.insertRouteData([location]) self.logger.notice("Added location") } } } catch { self.logger.error(#function, metadata: [ "error": .stringConvertible(error.localizedDescription) ]) } } } } I did also try CLLocationManager API with delegate which is what my current watch code uses (a bit old). Same issue. Here is what I've found so far: If the workout session is not running, and if the builder hasn't started collection yet, inserting route data works just fine I've tried different swift language modes, flipped from main actor to non isolated project settings (Xcode 26) Modified Apple's sample code and added location route building to that and reproduced the error, modified sample attached to feedback This issue was identified against Xcode 26 beta 2 and iPhone 16 Pro simulator. Works as expected on my iPhone 13 Pro beta 2. FB18603581 - HealthKit: HKWorkoutRouteBuilder insert call within CLLocationUpdate task never returns

Like any good developer, I try to add tests where I can. The AgeRangeService.AgeRange type does not provide an initializer. I know the routine, create an interface or a simple struct that I control and use that instead. Thanks to extensive time with frameworks like Core Bluetooth or Core Location, this is a well understood practice (looking at you CBPeripheral...). Great I'll make my own 'AgeRange' struct. Make it Hashable, make it Sendable, use the framework types as properties. Scratch that, most of the properties on AgeRangeService.AgeRange type are not Sendable and many are also not Hashable. This is proving to be challenging. I hope to open source my little Swift Package wrapper library for DeclaredAgeRange which will add types with full Hashable and Sendable conformance. I hope Apple updates the API and makes this obsolete. I don't see why these simple types can't be Hashable and Sendable. They're structs, enums, and OptionSets (structs). FB20959748 - DeclaredAgeRange: DeclaredAgeRangeAction is not sendable causing main actor compile errors with default isolation settings FB20960560 - DeclaredAgeRange: AgeRangeService.AgeRangeDeclaration is not sendable as expected FB20960574 - DeclaredAgeRange: AgeRangeService.ParentalControls is not sendable as expected FB20960590 - DeclaredAgeRange: AgeRangeService.ParentalControls is not hashable as expected On the note of the library and using the types as-is, there are some issues using the new cases in AgeRangeDeclaration and the isEligibelForAgeFeatures property. I started another thread over here: https://developer.apple.com/forums/thread/808144