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

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.

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.

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 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?

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)

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.

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.

Thanks a lot for the reply. To be clear by "Debug Mode" I meant running the app in the Debug Configuration...so In Xcode's menu bar: Product -> Scheme -> Build Configuration = Debug. Worked fine, both attached and detached from the Debugger without the call to -startAccessingSecurityScopedResource. I fixed the issue in my app and decided to move on as I have to prioritize my time. As a developer I'd consider it to be a bug because the -startAccessingSecurityScopedResource should be required in the "Debug Configuration" as well but maybe Apple has a different point of view on this issue.

What do you mean by “debug mode”? I mean in Debug mode on my iPhone (not the simulator) running iOS 15.6.1 if I selected a file via UIDocumentPickerViewController (using -initForOpeningContentTypes:) I was able read/load the selected file without issue (a call to -startAccessingSecurityScopedResource was not required). However, when I archived and Airdropped a release build to the iPhone the sandbox denied permission to read the file. This made it hard to catch the issue during development. By your reply this sounds like this would be considered a bug?

What about on orientation change? Delegate method isn't called when the orientation changes. If my current view controller has an overlay feels like I should be able to access the frame at anytime...to make sure my content doesn't overlap the overlay? Perhaps something like this? @interface UIWindowScene (SKOverlay) @property (nullable,nonatomic,strong,readonly) SKOverlay *presentedOverlay; @end @interface SKOverlay (FrameInView) -(void)overlayFrameConvertedToView:(UIView*)view; @end //From my view controller... -(void)viewDidLayoutSubviews { [super viewDidLayoutSubviews]; UIWindowScene *scene = self.view.window.windowScene; SKOverlay *presentedOverlay = scene.presentedOverlay; if (presentedOverlay == nil) { //No overlay...layout } else { //overlay is showing...don't place anything inside its rect... CGRect overlayRect = [presentedOverlay overlayFrameConvertedToView:self.view]; } } Why doesn't SKOverlay provide a frame/API to convert its current rect into any arbitrary view in the same window scene? I'm assuming the SKOverlay is being shown in a different UIWindow....showing the SKOverlay doesn't even cause -viewSafeAreaInsetsDidChange to be called. Seems like this object can only be used in the simplest of view controllers.

Using -initForOpeningContentTypes:asCopy: and passing in YES for the asCopy parameter seems to work. I guess I have to use -startAccessingSecurityScopedResource and -stopAccessingSecurityScopedResource if I use -initForOpeningContentTypes: (haven't tried yet). Would be great if this behavior was consistent in debug and release mode.

Someone else reported this on Stackoverflow: https://stackoverflow.com/questions/73483102/appstoreconnect-developer-action-needed-status-wont-go-away Guess I'm stuck waiting on Apple to respond to my case number.

Thanks a lot for clarifying!

So I ended up using lipo to combine the Simulator builds into one (M1 and Intel), then created the XCFramework and everything worked fine. Every post from Apple on the developer forums seems to strongly recommend against using lipo but I could not find another way to make this work. Since I build OpenSSL from Terminal, I'm not sure if there is an option I could use to build for both M1/Intel iOS simulators in one shot. Do command line tool provide a way to build for the Intel simulator even on an M1 Mac? I built the library for the simulator on the Intel machine and Air dropped it over so I could lipo them together. Feels like this should be easier though.