I tried setting auto layout constraints, which did in fact cause _UITAMICAdaptorView to be removed from the view hierarchy but in my case that has nothing to do with the UI glitch (the custom view still appears at the wrong location on y axis because of _UINavigationBarTitleControl yOrigin)

I was able to reproduce it in a small sample project after awhile. The key to reproduce it is to make sure the navigationItem's title property is set. Have the title property set to a non nil value and also set the titleView. Then if "Debug View Hierarchy" I can see that _UINavigationBarTitleControl has an ambiguous vertical position. Anything I can do to workaround this issue?

Okay so setting the title to nil before setting the titleView works around the issue. However this may have side effects if you read the title from other areas in your code (as a generic reference to build alerts titles etc.)...seems like it should be okay to have .title and .titleView set (was the case before iOS 16 anyway).

I was hoping for more control of the search in app. In my case I'm just using "Find" (not replace). The issue is my app uses UISearchController in another area that has its own search preferences so ideally I'd like to be able to configure the UIFindInteraction to match the search experience I already have. I'm not sure if users will understand that the search bar in one area is app provided and the "Find" experience is system provided and they could potentially have different preferences. So ideally, I want to configure the UIFindInteraction to match my existing search experience in another view controller but it doesn't appear to be possible unless I implement UIFindSession subclass from scratch, in which case I get almost nothing for free.

Also the UIFindInteraction's delegate is readonly, which makes determining when the Find Session ends much more difficult. I'd like to know when the "Find Panel UI" is finished so I can call -becomeFirstResponder on another UIResponder so the user can invoke undo/redo actions on it.

They shipped Xcode 14 with this bug. I just reported it. Brrr... hitting exception breakpoints like crazy every time I set properties on UINavigationItem.

I just reported this.....iOS has so many alarmist system logs now devs have no way of controlling.

Huh when I added an updated copy of GoogleMobileAdsSDK somehow the .xcframeworks got added to the "Embed Frameworks" area in Xcode. Not sure if Xcode did that automatically on drag and drop or if I did it by mistake...but after I removed them from the "Embed frameworks" area uploading worked.

I filed a feedback: FB11573728

Changing my snapshot code to use UIGraphicsImageRenderer appears to have fixed the issue:   UIGraphicsImageRenderer *imageRenderer = [[UIGraphicsImageRenderer alloc]initWithBounds:snapShotView.bounds]; UIImage *snapShotImage = [imageRenderer imageWithActions:^(UIGraphicsImageRendererContext *rendererContext)     {         CGContextRef cgContext = rendererContext.CGContext;         [snapShotView.layer renderInContext:cgContext];     }]; Not sure why UIGraphicsBeginImageContextWithOptions API was generating a clipped image only in the landscape orientation on certain iPhone models like iPhone 14 Pro. For whatever it's worth the view being "snapshotted" is offscreen (not in a UIWindow). Migrating to the newer API works for me (I should have been using UIGraphicsImageRenderer in the first place anyway).

I opened FB11580679

Potential workaround:  [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext>  _Nonnull context)     {         UIView *container = context.containerView;         CGRect containerFrame = container.frame;         CGSize authenticSize = containerFrame.size; //use the size from the container view to workaround bogus size.     }     completion:nil]; Also tried moving this code to -traitCollectionDidChange: but it looks better if the view gets hidden before the rotation, not after.

Heh this weird size is also passed to iPhone 13 Pro Max (even on IOS 15) but I didn't notice before because I also update the hidden property in -viewDidLayoutSubviews if landscape/iPhone combination is detected and on iOS 15 -viewDidLayoutSubviews is called after -viewWillTransitionToSize:withTransitionCoordinator: What makes this an issue in my app on iOS 16 is UIKit is now making an extra call to -viewWillTransitionToSize:withTransitionCoordinator: after viewDidLayoutSubviews (with the bogus size), so the call to hide the view in -viewWillTransitionToSize:withTransitionCoordinator: ends up winning. Another potential workaround is to move this code out of -viewWIllTransitionToSize:withTransitionCoordinator and into -viewWillLayoutSubviews OR use -willTransitionToTraitCollection:withTransitionCoordinator: -(void)willTransitionToTraitCollection:(UITraitCollection*)newCollection withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator { //iPhone going landscape...translate the size class abstraction into normal terms.     if (newCollection.userInterfaceIdiom == UIUserInterfaceIdiomPhone         && newCollection.verticalSizeClass == UIUserInterfaceSizeClassCompact)     { //do it.     } [super willTransitionToTraitCollection:newCollection                  withTransitionCoordinator:coordinator]; } Looks like iOS may have stopped passing in the final destination size to -viewWillTransitionToSize:withTransitionCoordinator: in iOS 15, for unknown reasons. This is all from within a view controller presented modally.

This bug is new in iOS 16.... running the app on iOS 15 and I get the expected behavior.

Aha. The problem was I forgot to assign the configuration property on the content view! 🤦‍♂️ -(nonnull __kindof UIView<UIContentView>*)makeContentView { CustomContentView *customContentView = [[CustomContentView alloc]init]; customContentView.configuration = self; return customContentView; }