If your UI use UINavigationController (which of course contain UINavigationBars) then you are likely seeing the NavigationBar-in-NSToolbar hosting that is done by default for iOS 16 linked apps. If you want to disable this then you need to set the preferredBehavioralStyle of each UINavigationBar to .pad
Unfortunately, setting preferredBehavioralStyle to .pad will show the title bar under Ventura, even if the title bar should be hidden. Below are screenshots from a quick demo project I created, the first is built against the Xcode 14 and Catalyst 15, the second is built under Xcode 14.1 and Catalyst 16 with preferredBehavioralStyle set to .pad:
This is a problem if you are hosting everything inside of a UISplitViewController and want to run the secondary view all the way to the top of the UI. Before, you could even do this with navigation controllers by setting additionalSafeAreaInsets.top to a negative value matching the height allotted for the title bar, but doing so under Catalyst 16 with preferredBehavioralStyl set to .pad gives you this instead, where you can see the navigation bar hidden under the title bar that is supposed to be disabled:
The only workable solution I have found (beyond building against Catalyst 15, which precludes newer features) is to use the leadingItemGroups, centerItemGroups, and trailingItemGroups properties of UINavigationItem when running under Ventura instead of leftBarButtonItem, titleView, and rightBarButtonItem.
This works (mostly), but makes maintaining the codebase for backward compatibility more difficult by adding conditionals every time you need to deal with a navigation item. Yes, you can abstract this out, but even then, for a large codebase it adds additional risk of breaking previously working behavior.
Also, there seems to be a problem with clipping the hosted view. If you look at the example below, you can see the segmented control in the center has its border clipped along the top and sides:
Ideally, setting preferredBehavioralStyle set to .pad would give the prior behavior across the board, making everything much easier to maintain for backward compatibility purposes. I think this is particular important on the Mac as, at least in our case, we have found our Mac customers tend to upgrade their OS and hardware at a much, much slower rate than with iOS. And with subscription-based software, it is important to make newer features in the app itself available to these users.