I don't see estimated effort scores in Apple's Fitness app for any workouts created by my app, for any activity type. The only time they are visible is if an effort score has been specifically set by the app (which I got working after your help on that other thread, so thanks for that). I am assuming that the Fitness app shows the effort if one has been set and otherwise shows the estimated effort. Is that the case? Or does the estimated effort get stored in Health Kit but is not used by the Fitness app?

Many thanks for your detailed response. I finally managed to get it working by coding it in Swift, using your example code. For some reason I just couldn't get it working with Objective C.

I can't get it working when using relateWorkoutEffortSample. The completion comes back without an error but there doesn't seem to be an effort stored for the workout when I view it in the Fitness app. My code is: HKUnit* effortUnits = [HKUnit appleEffortScoreUnit]; HKQuantity* effortQuantity = [HKQuantity quantityWithUnit:effortUnits doubleValue:effort]; HKQuantityType* effortQuantityType = [HKQuantityType quantityTypeForIdentifier:HKQuantityTypeIdentifierWorkoutEffortScore]; HKQuantitySample* effortSample = [HKQuantitySample quantitySampleWithType:effortQuantityType quantity:effortQuantity startDate:self.startDate endDate:self.endDate]; for (HKWorkoutActivity* activity in self.workout.workoutActivities) [self.store relateWorkoutEffortSample:effortSample withWorkout:self.workout activity:activity completion:^(BOOL success, NSError * _Nullable error) { if (!success) { if (error) NSLog(@"Error saving effort score: %@", error.localizedDescription); else NSLog(@"Error saving effort score"); } else NSLog(@"Successfully saved effort score %d", effort); }];

Many thanks for the fast, detailed and helpful reply. It helped me realise that I was using the Xcode beta 6. However I downloaded it yesterday from the Downloads page and that page definitely described it as the RC, with a date of September 9th. I suspect I downloaded when the page had been partially updated with the text for the RC but the link to the file hadn't been changed. I was eagerly pressing refresh on that page and downloaded the moment the text changed to say RC with yesterday's date. Anyway it all seems to be working now, so many thanks again for your very helpful response.

I am seeing the same thing. It is only an issue with iOS 17.5. Sending from iOS 17.4 to watchOS 10.5 worked fine, but not sending from iOS 17.5.

I am also seeing this stack trace in the crash logs that Apple send via Organiser. My app uses TTS on the iPhone and the Apple Watch and I get this crash for both iOS 17 and watchOS 10.

I have only seen two outdoor swim workouts with watchOS 10, but the GPS trace for both of them was awful. Much worse than I have seen in the past. It's a very small sample and probably too early to be sure, but I am probably seeing the same GPS issues as you when swimming outdoors with watchOS 10.

Thanks. I suspect they are different problems because I don't get distance samples for pool swims either, where GPS is not involved. However I have only seen two outdoor swim workouts with watchOS 10, but the GPS trace for both of them was awful. Much worse than I have seen in the past. It's a very small sample and probably too early for me to tell, but I am probably seeing the same GPS issues as you when swimming outdoors with watchOS 10.

Many thanks for replying so quickly. My watch app is independent (although I wish it wasn't but that is another story) so in theory users should be fine in most circumstances. That may explain why only two people have complained so far. As you say, new users of the app running a recent iOS will not be able to install the app. This is not too bad because they can just get a refund and an apology. However it may also affect long term users of the app. For example if they update their iPhone but not their watch. They would then get the latest version of the iOS app, which will not be able to install its watch app on the old watch. It seems that it is possible to download an older version but only for the situation where the user is running an old version of iOS. Is it also possible to do the same when the user is running an old version of watchOS? For example if they try to install the watch app from the App Store on the watch? Thanks again for replying so quickly and thoroughly, especially at the weekend and just before the release of all the new hardware and software!

Same problem here. I find that it is only possible to buy the in-app purchase if it has a base country that matches the country of the tester. For example a tester in the Netherlands can only buy if the IAP has a base country of Netherlands (EUR). They cannot buy if the IAP has any other base country, even if that country also uses EUR. Hopefully this is just a TestFlight issue and it will work when the app is released, but it is worrying not to know that for sure.

I am seeing the same problem.

A couple of the app's testers have reported that this is now working in beta 3 of watchOS 9.2, so many thanks for fixing it! Apparently the first time they use it after a reboot it does take a long time to work, but it does eventually work, and after that it is fine.

Any update on this documentation? I have seen a change in the HIG that mentioned it but nothing in the developer documentation. Also, as the AppIntents API is Swift only, how would I use the button with an app written in Objective C? Thanks.

In case anyone else is reading this because they are tempted to make their watch app work independently, then please think very carefully about it.  I enabled the WKRunsIndependentlyOfCompanionApp option a year or two ago because my watch app can work independently, so I figured it was worth doing. However the watch app is still best used with the iPhone app (e.g. configuration is easier on the bigger screen). As others have said, ever since I made the watch app independent then every time I release a new version I get complaints from users due to issues caused because either the iPhone app has updated and the watch app has not, or vice-versa. The worst thing is that I can't roll that change back because of Apple's restrictions. For some reason it is a one-way change. This is why I recommend against making the watch app independent. Even if you think there is no need for a companion iPhone app now there may still be the chance that you may add one in the future (e.g. the bigger screen can be useful for configuration or analysis). So if you choose to make the watch app independent now then you may be setting yourself up for major problems in the future. I do not understand why Apple cannot simply update both versions of the app regardless of whether the watch app is tagged as being able to work independently. Why would you want a user to have inconsistent versions? And if they can't do that then they should definitely improve the documentation for WKRunsIndependentlyOfCompanionApp. They need to make it clear that enabling that option will cause the watch app and iPhone app to get out of sync with every update, and that once you have made that change then there is no way back in future versions. At the moment that option looks innocuous but can be deadly.

I gave up trying all the suggested fixes because in the end it was impossible to tell if they worked because the issue is random. So I very reluctantly made my app accept all file types. Even if Apple were to fix the problem tomorrow it would still be too late. Most people are using iOS13 now and a significantly large amount will still be using it in a year or two, so I can't see myself ever changing the app back to only accepting some file types. It is very annoying because we told Apple about the issue months before iOS 13 was released but they did nothing and now the file type system is broken for the foreseeable future.