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.
There is no public API that can add an overlay on the system keyboard on iOS, and that is as-designed to avoid keyboard loggers and better protect user’s privacy.
If you don’t have to stick with the system keyboard, there are two options you might consider:
-
Use a custom
inputViewto replace the system keyboard, as you mentioned. Note thatinputViewonly works in your own app. -
Write a custom keyboard extension. This allows other apps to use your keyboard, if the users choose to do so.
Both inputView and a custom keyboard extension completely replace the system keyboard, and so you will need to implement the basic text input features, which will be really involved, if you would like them to behave like the system keyboard.
Best,
——
Ziqiao Chen
Worldwide Developer Relations.
