As of Xcode 16 beta 4, most of these issues have been resolved. There are still some visual bugs with the new floating tab bar and animations involving the moreNavigationController when at compact widths, but the overall behaviours of the new tab bar system now seem correct.

I'm seeing the same issue, and it's unrelated to deployment target. It appears that BoringSSL-GRPC is setting the "-GCC_WARN_INHIBIT_ALL_WARNINGS" as a compiler flag on a per-file basis, and clang v16.0.0 is not recognizing it and treats it just as "-G" and errors out because "-G" is not supported. The clang behaviour change is probably from this commit My guess is that this was always an invalid flag, but clang (due to the bug fixed by the above commit) was previously silently ignoring it.

The issue appears to be with how the UIMoreListController improperly retains the child view controllers until after UITabBarController finishes its dealloc, and then when those child view controllers go to dealloc they crash on a now-invalid (unowned?) reference to the UITabBarController as their parent view controller. This only seems to occur when the UIMoreNavigationController is set as the UITabBarController's _selectedViewController ivar. Unfortunately, it's not easy to detect if that's the case, because the getter for selectedViewController will (contrary to what is said in the header comments) return whichever of the UITabBarController's viewControllers children is shown in the UIMoreNavigationController, NOT the UIMoreNavigationController reference directly. I was able to workaround this issue by always running tabBarController.selectedViewController = tabBarController.viewControllers.firstObject; to switch back to the first tab's (i.e. not under "More") controller immediately before triggering the deallocation of the UITabBarController. (In my case, the UITabBarController is already offscreen at this point, so there's no visual artifact from this last-moment switching.)

I was experiencing this issue, and I found that switching the Swift compilation mode build setting to "incremental" (instead of "whole module") for the build configuration being used for the tests fixed it, and the coverage counts now look accurate, instead of acting like 90% of the Swift code isn't even code. (This limitation doesn't seem to be documented anywhere, unfortunately.)