It feels to me like every year advances are promised in improving watch app build, installing & debugging with Xcode. Sadly these fixes and changes seem to either not do that or introduce other errors. Having an Apple Watch Series 6 & Newer or SE 2 is a good start because they have the dual band wifi chip needed to work with networks at 5GHz, debugging over Bluetooth is pointless. Using Xcode 14 is probably the best debugging experience I've had over the Apple Watch lifetime, but the standard is so low its not saying much. Once I have app building and debugging working I can do endless app builds to the watch without issue in one session. But its just getting it working initially thats the issue. Problems such as: Copying Watch debug symbols Saying Developer mode not enabled on watch when it is Getting a random failed to install WatchKit app on Xcode with no further details No paired Apple Watch even being listed for an iPhone that definitely has one You get this idea....

In the end I fixed this and got the behaviour I wanted without the need for a custom solution. The solution was to wrap the whole thing in one navigationStack rather than individual ones. I had already tried this but had the bug mentioned with the navigationTitle not displaying properly. This was fixed by setting the NavigationTitle on the TabView to the same title as the title on the first Tab item view. This is likely a bug which I'll report. Thanks

No, there's no way for third party apps to trigger HRV readings from Apple Watch (unlike heart rate which is possible). However, since the new AF History feature launched with WatchOS 9, I've noted that enabling that changes the number of daily HRV reading the watch records from roughly 5 to roughly 50. Users have to enable this feature though and it currently "requires" the user to have a diagnosis of AF. Hopefully the additional HRV readings roll out to all users with WatchOS 10.

Sorry for missing something here, is it not simply the samples.count here thats equal to the number of workouts in a week? Or are you saying the query doesn't return any results?

Unfortunately this doesn't work for me though as it introduces another issue. If I go with the layout you suggested, any NavigationLinks I have within the NavigationStacks do not hide the Tab View indicator "dots" when opening. This is not the behaviour I'm after. So if I have - NavigationStack{ TabView{ View{ NavigationLink - This works in terms of correctly displaying the NavigationLinks with the new view hiding the indicators, but I loose the large titles. If I have - TabView{ NavigationStack{ View{ NavigationLink - The Large titles display correctly but the indicators are still there after selecting the navigation link. Is this all expected behaviour or is there a bug I need to submit? Or is there some other combination of elements to try that gets me all the behaviour I'm after? Thanks

Can't help on the specific detail of interpreting sensor positional data into user movement. But one thing to add, you won't be able to do this live on the watch with background processing on the data unless you configure your app to run as a workout. Does this fit your use case?

Same issue here with Xcode 14.3 Beta 3

I've had this issue since SwiftUI complications with WatchOS 7. I also find that you can't get font sizes as large without truncation compared to using the old template (CLKComplicationTemplateGraphicCornerGaugeText in your case). Have reverted to using the template ones instead until this is fixed and should solve your problem for now.

No Suggestions? Apple?

Any further suggestions? All issues still present in WatchOS 9.4 & iOS 16.4

Have come up with a solution.... someone will probably tell me it's horrible, buts it's my only idea for now. I used a ZStack so when the complicationRenderingMode == .tinted I overlay another chart with complicationForeground() modifier applied to the whole thing. On that chart I then only include the elements I want to be tinted. The base chart then offers the elements I want in grey. Hope this helps someone, will update if I find a better solution.

I've had issues too. Mostly with migrating my app from the app / extension to a single combined targets. A whole host of issues have occurred since and no real fixes seem to exist other than reinstalling the app. Have submitted feedback, heard nothing. (FB 11989396)

Same problem. Can't debug on my WatchOS 8.7.1 test device. Xcode 14.3

I am 99% sure I know what's happening here having experienced the exact same issue. I too migrated to the single app target and have regretted it for this problem ever since. My understanding is that in the WatchOS system there are caches for the complications you run on your watch face. These caches include bundle identifiers for the complications, bundle identifiers which change when you migrate to the new single target! So this means the complications on your existing watch face point to what seems like a non-existent app hence the "--". I think the reason this so blatant problem has got through and continued is because Apple expects developers to also adopt WidgetKit for complications instead of Clockkit, and this has a migrator (although I've read plenty of issues with that). The problem is that some developers, including me, are not yet adopting WidgetKit for complications for many reasons including supporting < WatchOS 9, issues with WidigetKit update performance not being as reliable as ClockKit etc.... In theory, with my answer above you would think that just deleting the complications off the watch face and adding them back will resolve the issue. It can do, but often the caches don't clear and you have to either reboot the watch, delete the watch face entirely and start again or various other combinations of fixes. I missed and therefore shipped the problem so I have had to create an entire support document for my users to resolve this bug. I also will not ship an update undoing the problem because then I'll have even more users with watch faces on a variety of complication bundle identifier caches if that makes sense.... So, if you have shipped it, that's a problem. The good news is it won't affect new users of your app, but old users with existing complications will have a pain migrating over. If you haven't shipped yet, my only advice is don't and revert back to a single target until Apple fixes the issue. (FB 11989396) If you somehow felt like you had to ship a single target you could try changing all the identifiers in your CLKComplicationDescriptors you provide to the getComplicationDescriptors() function. I've not tested this but think it would solve the problem. That said, any existing users with watch face complications will still have to change them for the new ones, but the caching/restart issues should be prevented. I really hope this is the answer you're looking for and it's helpful, please let me know either way! As I'm sure you can tell from the length of my response, it's given me a great deal of pain in the last 8 months!

I believe this is the same issue as detailed here: https://developer.apple.com/forums/thread/729599?answerId=753211022#753211022 I've given an answer to me best knowledge there. Hope it helps.