My workaround is to remove and recreate the SKOverlay on orientation change. Also have to hold the SKOverlayTransitionContext's endFrame in a property to access the current location during other events (like viewDidLayoutSubviews etc.) Feels like this API could be improved.

After updating to IOS 16 I see my custom title view is getting placed in the wrong position on the y axis. My app conditions are this: -My custom title view isn't shown all the time (dynamically added/removed). -When the custom title view is first set it is placed approximately at the center of the navigation bar on both the x and y axis as expected. -After certain events happen my app sets the custom title view to nil to remove it. -When I reset the custom title view, it gets placed either at the top or the bottom of the navigation bar on the y axis instead of the center. This custom title view has a static frame, so I tried caching the size and returning it in -intrinsicContentSize but the system never calls intrinsicContentSize even though translatesAutoresizingMaskIntoConstraints is YES. So I tried overriding -sizeThatFits: and that is actually called by the system but the issue persists because the size of the custom title view's frame is fine it's the origin that is wrong. So I logged out the frames of my custom title view its ancestor views like this:  NSLog(@"My frame: %@",NSStringFromCGRect(frame)); NSLog(@"superview %@ frame: %@",NSStringFromClass([superview class]),NSStringFromCGRect(superview.frame)); NSLog(@"superview.superview %@ frame: %@",NSStringFromClass([superview.superview class]),NSStringFromCGRect(superview.superview.frame)); When the custom title view is approx placed in the right location the first time its set the frames log out to this: My frame: {{0, 0}, {161.5, 23}} superview _UITAMICAdaptorView frame: {{0, 0}, {161.5, 23}} superview.superview _UINavigationBarTitleControl frame: {{291.5, 3}, {161.5, 23}} Then when it later gets reset and it is not properly placed on the y axis: My frame: {{0, 0}, {161.5, 23}} superview _UITAMICAdaptorView frame: {{0, 0}, {161.5, 23}} superview.superview _UINavigationBarTitleControl frame: {{291.5, 24}, {161.5, 23}} For some reason when the titleView is set the second time _UINavigationBarTitleControl yOrigin is 24.0. Initially it has a y origin of 3.0 when the custom title view appears to be in the correct location.

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.