Same here — filed FB25094825 with a minimal sample project (a plain UIInputViewController with a single 260 pt height constraint, no third-party code), a video and measurements. A few data points that might help: English -> custom keyboard: keyboard frame 352 pt; Emoji -> custom keyboard: 335 pt (iPhone 15 Pro, iOS 27.0). Reproduces every time, also with the plain sample keyboard. iOS 18.5 Simulator, same steps: 335 pt every time, so it's a regression (FB21449121 above suggests it started in iOS 26). The inset seems to follow stale state of the hidden system assistant row: the host's TUISystemInputAssistantView is hidden (height 0) in both states, but its subviews keep the previous keyboard's row height — 44 pt after English -> 17 pt inset, 53 pt after Emoji (emoji search row) -> no inset. The native English keyboard with its assistant bar hidden gets the same 17 pt, so the inset itself looks intended; it's just applied inconsistently to third-party keyboards. Nothing on the extension side changes it (allowsSelfSizing, UIHostingController.safeAreaRegions = [], re-requesting layout on appear, UIInputView style). The extension's window, view and safe area are identical in both states, so there is nothing to detect or compensate for.