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

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?

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.

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

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....

I'm having lots of problems with my published app which I think are similar. Since merging my watch extension and watch app to one target it's wreaked havoc on my complications (I've not even started on WidgetKit yet and using that in my complications). My users are generally finding that complications templates all work find but they often get dashes "--" after updating my app. The only solution has been to change the complication in the slot to a different one, and then move it back again, al then works fine. I think it must be because of some bundle or id change in the complication but it's an absolute nightmare and I'd roll back if I didn't think I'd just get the same grief from all the users who it now works for. I'm targeting WatchOS 8 or later and the main app function is reading HealthKit data and displaying it on complications. On a separate but possible related note to this, since moving to one watch app target I've also gained duplicate HealthKit permissions in the iPhone Privacy Settings. I have a feedback in for this FB11704560 but it's been completely silent for over a month....

Having the exact same set of problems here with complications and WatchOS 9 & iOS 16. Wondering if it might be an Xcode 14 problem too as its causing problems for an old version of my app that used to work. An update from Apple Engineers would be very appreciated...

Second this issue. Xcode 14 GM iOS 16 GM iPhone 12 mini

As of today I have now been able to upload a build using Xcode 14 Beta 5. Hope yours is fixed too!

Same issue here, not resolved yet...

This was fixed in iOS 15, issue persists for iOS 14 even if built with Xcode 13.

This issue has not been solved for me even using Xcode 14 Beta 4 when distributing via TestFlight. I've not been able to test Beta 5 yet as I can't submit any builds currently, will report back once I've tested this.

Same for me trying to ship a TestFlight beta of my app which uses the new Charts framework. Crashes on launch for a large proportion of users with the following message: Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: DYLD 4 Symbol missing Symbol not found: _$s6Charts11BuilderPairVMn Referenced from: <E7FDC397-7B61-3C7C-A6A0-441BD43EFDC1> /Volumes/VOLUME/*/<App_Name>.app/Heart Hive Expected in: <D800F5CA-04A9-3D85-A4A1-8AEACDF75A13> /System/Library/Frameworks/Charts.framework/Charts (terminated at launch; ignore backtrace)

I second this question and behaviour here. I'd like to know if my independent Watch app will still be available in the WatchOS App Store on WatchOS 6 devices if I release an update with the minimum deployment target of WatchOS 7. And if the user has a newer iPhone that supports a later version of my app, but the watch doesn't, what happens then? Thanks

I've not been able to get the always on display feature working throughout the entire summer. My app has a deployment target of WatchOS 6 mostly to support Series 1 & 2 Apple Watch models. Do you think that I need to drop support for WatchOS 6 & 7 in order to get my app working with the Always On display for WatchOS 8? Because even in the latest RC build (RC Xcode 13, RC iOS 15 and RC WatchOS 8), I can't get it to behave differently from how it did with WatchOS 7 and the time. I've also tried adding WKSupportsAlwaysOnDisplay and setting it to TRUE. No luck.