I am building an iOS text composer with an attachment panel. When its UITextField is first responder and the system keyboard is visible, tapping the attachment button should present a panel that can extend into the region occupied by the keyboard. When the panel closes, the user should return to the same keyboard state without a visible dismissal and re-presentation.
The required continuity is:
The same UITextField remains first responder.
The active input mode remains alphabet, 123, or Emoji.
Emoji preserves its selected category, search state, and scroll position.
The composer remains positioned above the keyboard throughout the transition.
I have investigated the public UIKit approaches:
A normal app-window overlay cannot render above the remotely hosted system keyboard.
inputAccessoryView remains in the accessory region and cannot cover the keycaps.
Resigning first responder visibly dismisses the keyboard and loses continuity.
Assigning a custom inputView to the same UITextField and calling reloadInputViews() publicly replaces the keyboard. However, restoring inputView to nil reconstructs the system keyboard and does not preserve the exact Emoji or keyplane state.
UIKeyboardLayoutGuide provides geometry but no presentation control.
Is there a supported public API or recommended architecture that allows an app to:
Temporarily obscure or visually hide the system keyboard while keeping it active and preserving its state?
Present app-owned content in a layer above the keyboard keycaps?
Temporarily replace the keyboard and restore the same mode, Emoji category, and scroll position?
If these are unsupported, what is Apple's recommended way to create an attachment panel that visually occupies the keyboard region while maintaining input continuity?
This occurs on iOS 26.x in Simulator and on a physical iPhone using a UIKit-backed text field inside a SwiftUI interface. I am specifically looking for a public API solution and do not want to access private keyboard windows or views.
0
0
81