The keyboard has changed a bit over the last few years. It has new languages, it floats, and it handles multiple screens
Out of process keyboard
- This is the new architecture – allows for improve privacy and security
- This is now a process out side of your app, this will be an asynchronous process with the system and your app requesting updates from each other. Ultimately you will get a Text Insertion – it may provide some slight timing issues
- Frees memory from your app
- Provides flexibility for future changes
Design for the keyboard
- Note in the old model, you moved your view up to address for the keyboard. However in the new model, you need to adjust your app to the intersection with the keyboard overlay (like in Stage manager). You may have multiple scenes that have to adjust.
- If you use the mini-toolbar, in stage manager is different than out of stage manager.
- Keyboard layout guide was introduced in iOS 15 for UIKit, this has been updated by iOS apps, and is the recommended way to address the keyboard.
- view.keyboardLayoutGuide.topAnchor.constraint(equalTo: textView.bottomAnchor).isActive = true
- This has been updated to allow for more customization on iOS 17
- SwiftUI automatically handles the common cases for you, by adjusting the safe view.
- Notifications
- In the past you had to listen for will show, did show, etc. and then process these yourself. But with Stage manager introduction those patterns didn’t work
- It certainly seems that many of these changes are why Stage Manager only got as far as it did last year.
New text entry APIs
- Inline predictions will allow for on device processing and context to provide information. This is enabled by default for most text fields. This is powerful