I have a simple task, to measure the height of the overlapping area occupied by the keyboard in the current view. In the attached images, I use it to position a UITextView (red) above the keyboard, as a test.
The keyboard displays an inputAccessoryView (yellow) when editing a text view, but it’s also summoned by a UIFindInteraction, which shows a search bar above the keyboard. When measuring the keyboard, I need to account for either the accessory view or the search bar, basically, the total keyboard height including any extra views above it.
I use the usual algorithm: the keyboard frame from UIResponder.keyboardWillShowNotification (documented as being in screen coordinates) is converted to my view’s coordinates and intersected with the view’s bounds to get the overlapping height.
The first issue: in windowed mode, the keyboard frame reports a negative origin.x (e.g. -247), even though in screen coordinates it should start at 0. I display the raw frame in the navbar, as shown in the first screenshot.
I then suspected the frame might be in window coordinates on iOS 26, but repositioning the window a few times, and switching between find interaction keyboard and text editing keyboard, sometimes yields a positive origin.x instead, as if the keyboard starts from the middle of the screen!? (see the second screenshot).
And in some cases, the raw keyboard height is even 0, despite the keyboard clearly being visible and taking space (third screenshot).
Interestingly, the reported frame for the search keyboard is always consistent and in screen coordinates, but the default keyboard frame just doesn’t make sense.