I found a solution that works on both iPadOS 14 and 15. In my ContainerUIViewController I was assembling and inserting the child view controller in viewWillAppear As the final step I was calling setNavigationBarHidden to true. This worked as desired in iPadOS 14. Moving this to viewDidAppear meant that the command to setNavigationBarHidden worked correctly. With animation set to 'false' there is no visual appearance of the NavigationBar. I was concerned that handling it after parent view appearance would result in some kind of visual noise, but it wasn't the case.

I have the same problem, luckily I think I only have a single competitor or 'stalker' who is doing it. I was unable to get Apple to remove these reviews and ratings as its hard to prove. A good example is that I released a bug fix release on Sunday last and on the same day it received a 1 star rating. This is a common pattern. The individual in question used to write a review and give the bad star on every update, now it seems he just leaves the rating. I have a ton of problems with reviews. Most users leave 5 stars, not all. However a good number after I switched to subscriptions as a payment (note that they don't have to buy this app, its a completely different app and the old one still works), give a 1-star review because they don't like the new apps business model. I have learned to just stop worrying and focus on improving the app as there's little I can do to stop this.

I was having this issue with 13.2 and 13.3 beta. I'm developing a SwiftUI package. Any compiler error caused the problem, and the detailed compiler error can only be found in the stack trace for the Uncategorized error. I can insert any compiler error to make this occur, then if I remove the error there is no issue as its only affecting error reporting. The file "PropertyEditorViewModel.swift" does not have any compilation errors, but the warning is that diagnostics cannot be read for it. I fixed this by moving some of the code in PropertyEditorViewModel.swift to a different file. After doing this, I receive correct compilation errors. I will not go into the details of the moved code apart from noting that it is not the main class in that file, but a class that implements a separate generic protocol referred to in the main class. I take it that the compiler is struggling with the unrelated classes in the original source file and pulling them apart into separate files helps the compiler when it needs to process diagnostics. Simplification fixed the problem for me.