Well, as it turns out, this issue was fixed in iOS 26 dev beta 4. I was testing on the simulator (using Xcode 26 beta 4) and it was still broken. When I launched Xcode this morning, it said that the iOS 26 simulator hadn't been downloaded yet so I assume that meant that the 26.0 b4 simulator wasn't yet available for download when I installed Xcode 26 b4 so the simulator I was using must've still been iOS 26.0 b3! After updating the simulator to b4 and running the app again, this issue with the tab bar has indeed been fixed.

Not solved in iOS 26 beta 4 for me, either. My app contains a VC with a table view which shows a list of chats. When the user taps on a row, we init a "messages" VC, set .hidesBottomBarWhenPushed = true and then push that VC. In iOS 18, when the messages VC appears, the tab bar is hidden. In iOS 26, including yesterday's beta 4 release, it is still visible and it appears over top of the input bar, etc. in our messages VC.

I just started running into this a few days ago and I'm not sure why. Same behavior as described above. Everything is working fine, then I need to connect to a VPN for work and when I disconnect from the VPN and try to build the app again and deploy it to the phone, it fails with: Warning: unable to build chain to self-signed root for signer "Apple Development: {redacted} (redacted)" Command CodeSign failed with a nonzero exit code There is also mention of errSecInternalComponent. If I open keychain on my Mac, I see that my development certificate now says that it's not trusted. And indeed, as julian99 stated, if I change the trust settings to "Always Trust", close that window, re-open the certificate again, change the trust settings back to "Use System Defaults" and then close the window again, it "fixes" the problem. For added fun, I have to connect and disconnect from the VPN a lot during the work day because the VPN configuration blocks all IPv6 traffic (including link-local traffic) so when I'm connected to the VPN, I can't get Xcode to connect to any of my iPhones. I've asked for an exception but so far, no dice. I haven't filed a bug report yet but I will as soon as I have time to do so.

Looks like it's working now.

@App Store Connect Engineer Thanks! Confirmed working now.

I submitted feedback to Apple about this issue. They asked me for a sysdiagnose from the watch and the phone. I provided that and they said the sysdiagnose from the watch appeared to be 'incomplete' and should be a few hundred megabytes (the one I submitted was ~50 megabytes). They said I should try again and if the resulting sysdiagnose still wasn't the expected size, I should try taking the sysdiagnose using a command line and using the “-L” parameter. I wasn't able to figure out how to execute the sysdiagnose from the command line on the Mac to gather data from the watch but I followed the directions specified in https://download.developer.apple.com/iOS/watchOS_Logs/sysdiagnose_Logging_Instructions.pdf and resubmitted another sysdiagnose. A couple of days later, the feedback ticket resolution was updated to "Investigation complete - Works as currently designed" with no other information. Meanwhile, I continue to experience this issue.

I heard back from DTS on this issue and they told me that what I'm seeing is due to "undefined behavior" after requesting 'always' authorization for location data. They said that since none of the monitoring APIs in Core Location (like the significant change location service, region monitoring, etc.) that actually require 'always' authorization are supported on watchOS, the authorization prompt that appears after I request 'always' authorization is "mostly a place holder and ends up causing the undefined behavior" that I observed. They further stated that if my goal is simply to continue receiving location updates when the app is in the background, that 'when in use' authorization is sufficient for that purpose as long as the app still declares the background location update mode and the location manager instance has its .allowsBackgroundLocationUpdates property set to true. However, the call to .startUpdatingLocation() must occur while the app is in the foreground. Finally, they added that it is not possible to stop and restart location updates while an app is in the background on watchOS. It's still not clear to me why this behavior differs when the code is run on the "Apple Watch Ultra (49 mm)" simulator vs the "Apple Watch Ultra (49 mm) via iPhone 14 Pro Max" simulator or on an actual Apple Watch Ultra. But regardless, it sounds like developers should not be requesting 'always' authorization for location data on watchOS and, that being the case, Apple should probably update their docs accordingly.

I've opened a DTS ticket to get some clarification on this but while I wait to hear from them, I've done some additional investigation and have observed something interesting. Xcode has a watchOS Simulator titled "Apple Watch Ultra (49 mm)". When I deploy the code to this simulator, it behaves as I would expect it to. That is to say, after granting "always" authorization in the second prompt, I get one more callback to locationManagerDidChangeAuthorization(_:) which indicates manager.authorizationStatus == .authorizedAlways and then the authorization prompts cease. I am now able to start location updates and receive them with the app in both the foreground as well as the background. Opening the Settings app on the watch simulator and navigating to Privacy & Security → Location Services, I see the app listed and it indicates that it has "Always" access to location data. Tapping that row shows that the settings ("Never", "Ask or When I Share", "While Using the App" and "Always") are still disabled but again, "Always" is selected and the app appears to function properly. There is another simulator in Xcode (listed under iOS Simulators) titled "Apple Watch Ultra (49 mm) via iPhone 14 Pro Max". If I deploy the code to that simulator, I experience the behavior I described above in my original post. This is the same behavior I encounter if I deploy the code to a real Apple Watch Ultra that's paired with my iPhone. So now I'm wondering if, despite being an independent watchOS app, this behavior is somehow related to the watch trying to use location data from the paired iPhone? As I said above, the location authorization prompts only appear on the watch (I've tried keeping the iPhone nearby and unlocked when running the watch app but still don't see any location authorization prompts on the phone). Could the prompts on the watch (after the first series of prompts, I mean), actually be asking for location authorization on the paired iPhone? If that's the case, I guess I'm still not sure why my selection(s) in the authorization prompts aren't being applied to the phone but at least it would give me something to go on.

For what it's worth, developer technical support told me that what we were trying to achieve is not currently possible in watchOS. They suggested filing feedback and requesting this capability which I have done.

I've spent the past week trying to find a good solution to this problem but have been unable to do so. Unless I'm just missing something, it doesn't seem like there's a good way to accomplish the same thing on watchOS that we've been able to do on iOS without having to keep location updates turned on all the time. Can anyone from Apple confirm that for me?