The Problem

When selecting an already initialized custom keyboard after using another keyboard, the host application will render its keyboard toolbar inside the frame of the custom keyboard.

This happens in all custom keyboards, including KeyboardKit-based ones as well as in Grammarly and Gboard:

This does not happen when launching a custom keyboard for the first time. It only happens when first initializing a keyboard, then switching to another keyboard, then switching back to the already initialized keyboard.

Steps to Reproduce

You can easily reproduce this bug by following the steps below:

• Use an app that has keyboard toolbar controls, e.g. Apple Notes
• Select a custom keyboard, e.g. Grammarly or Gboard
• Switch to another keyboard
• Switch back to the same keyboard

You should now see the keyboard toolbar controls overlay the custom keyboard, at least in iOS 26.5. If you can’t reproduce it, please let us know, so that we can pinpoint when this started happening.

Workaround Attempts

We tried adding a button to redraw the keyboard when this happens, but it didn’t help. It seems like the toolbar is always merged with the keyboard once the keyboard is presented after initialization.

Next Steps

We hope that iOS 27 will fix this problem, and will track any progress in this issue. If you report this to Apple using the Feedback Assistant, you can mention our report FB23560337 for additional details.

This release comes out close to KeyboardKit 10.6, which was released not even two weeks ago. The reason is to get these new things out and get your feedback before KeyboardKit 11.

⚡️ Actions

The KeyboardAction has new actions, like .openMainApp (without a deep link and reason), and .undo. The StandardKeyboardActionHandler also has a new undoLastRecordedDocumentChange function.

📜 Licenses

The LicenseErrorAlert that is used by KeyboardKit Pro has been redesigned to be more informative, and fit better in with the overall iOS platform design.

📦 Namespaces

KeyboardKit 10.7 flattens the remaining namespaces, to complete the extensive namespace transition earlier than initially planned, to give us all time to migrate before KeyboardKit 11.

🎛️ Settings

KeyboardKit 10.7 also adds many more pickers and settings for various keyboard models, including a brand new KeyboardActionPicker. This will let us harmonize settings, and use the same base picker for all models.

The Keyboard namespace has these new pickers: DockEdgePicker, InputToolbarTypePicker, InputTypePicker, KeyboardCasePicker, KeyboardTypePicker, LayoutTypePicker, ReturnKeyTypePicker, SpacebarLongPressBehaviorPicker, SpacebarMenuTypePicker, and there’s also a brand new KeyboardActionPicker.

🎨 Styling

As part of implementing the new pickers, there are new images, and image builders to add icons to the pickers:

.keyboardArrowBackward, .keyboardArrowForward, .keyboardCase, .keyboardEscape, .keyboardFunction, .keyboardInputType, .keyboardSpace, .keyboardSystemSettings, .keyboardType, .keyboardUrlDomain.

↩️ Undo

This version adds undo functionality to the keyboard engine. This makes it possible to undo text insertions, text deletions, and autocompletions in smart steps. We write more about this feature here.

Undo is currently opt-in, to avoid unexpected side-effects. Enable the undoManager experiment to try it out.

Conclusion

KeyboardKit 10.7 is a huge release that adds since long requested features, makes many structural changes for a greater developer experience, and irons out some bugs.

For more details, see the release notes for a full list of changes. Update now to get access to all improvements.

Host Application

KeyboardKit 10.6.0 disabled the host application bundle ID feature, which stopped working in iOS 26.4. Since iOS 27 haven’t restored the required APIs, we determined that it was best to remove this code.

However, some apps are still using this to provide a good user experience on iOS releases before 26.4. Due to this, we have decided to revert this removal, and instead soft deprecate the property.

Conclusion

KeyboardKit 10.6.1 is a small patch that reverts the removal of a function that is still used by some apps. The feature is not soft deprecated, and will be removed in KeyboardKit 11.

For more details, see the release notes for a full list of changes. Update now to get access to all improvements.

This beta release comes out very close to KeyboardKit 10.6, which was released just a few days ago. The reason for this is to get all the new things into your hands as soon as possible, to get your early feedback.

⚡️ Actions

The KeyboardAction has new actions, like .openMainApp (without a deep link and reason), and .undo. The StandardKeyboardActionHandler also has a new undoLastRecordedDocumentChange function.

📜 Licenses

The LicenseErrorAlert that is used by KeyboardKit Pro has been redesigned to be more informative, and fit better in with the overall iOS platform design.

📦 Namespaces

KeyboardKit 10.7 flattens the remaining namespaces, to complete the extensive namespace transition earlier than initially planned, to give us all time to migrate before KeyboardKit 11.

🎛️ Settings

KeyboardKit 10.7 also adds many more pickers and settings for various keyboard models, including a brand new KeyboardActionPicker. This will let us harmonize settings, and use the same base picker for all models.

The Keyboard namespace has these new pickers: DockEdgePicker, InputToolbarTypePicker, InputTypePicker, KeyboardCasePicker, KeyboardTypePicker, LayoutTypePicker, ReturnKeyTypePicker, SpacebarLongPressBehaviorPicker, SpacebarMenuTypePicker, and there’s also a brand new KeyboardActionPicker.

🎨 Styling

As part of implementing the new pickers, there are new images, and image builders to add icons to the pickers:

.keyboardArrowBackward, .keyboardArrowForward, .keyboardCase, .keyboardEscape, .keyboardFunction, .keyboardInputType, .keyboardSpace, .keyboardSystemSettings, .keyboardType, .keyboardUrlDomain.

↩️ Undo

This version adds undo functionality to the keyboard engine. This makes it possible to undo text insertions, text deletions, and autocompletions in smart steps. We write more about this feature here.

Undo is currently opt-in, to avoid unexpected side-effects. Enable the undoManager experiment to try it out.

Conclusion

KeyboardKit 10.7 is a huge release that adds since long requested features, makes many structural changes for a greater developer experience, and irons out some bugs.

For more details, see the release notes for a full list of changes. Update now to get access to all improvements.

What does this mean?

This will be a huge thing for the keyboard engine, especially since the native APIs lack any kind of undo control.

KeyboardKit’s custom undo engine will allow you to build nice features on top of it, for instance to allow a back swipe to undo the last change. We will also add new undo features over time.

Being able to undo autocomplete and autocorrect suggestions will be another huge win, where any destructive operations finally become revertible.

How does it work?

The standard action handler will use the new TextDocumentUndoManager to record revertible changes, like text insertions, deletions, and applied autocomple suggestions.

Changes of the same type will be recorded in chunks, to let us undo many subsequent changes of the same type with a single undo. This means that typing several subsequent characters will be recorded as a single change, to let us undo word by word insertions as separate undos.

The same goes for text deletions, where tapping backspace multiple times will be revertible with a single undo, and applying several subsequent autocomplete suggestions.

Changes will be stored in sequences in a change log, which means that you can type, delete, and complete freely and use the undo manager to rollback change by change. Due to a keyboard extension’s limited control over the text document, moving the input cursor will reset the undo stack.

To make it easy to trigger undo operations, there will be a new .undo keyboard action, that can be triggered with code or by adding an undo button to the keyboard.

When will this be available?

The new undo manager will be available in KeyboardKit 10.7, which will be released later in June. It will be opt-in at first, to allow us to test it with large changesets, to ensure that it doesn’t affect performance.

This also version starts reducing namespace nesting, as described here. Expect less nesting and more surface-level types, with renaming guides to help you migrate. This change will be implemented in steps.

🌱 Essentials

The KeyboardInputViewController has been adjusted to minimize the number of on-launch redraws, to minimize height and view flickering. This makes it more stable to launch KeyboardKit-based keyboards.

The Keyboard.SpacebarDragGestureHandler has been extended with up and down drag support. When you drag the spacebar vertically, the cursor will now move to the end of the previous/next sentence.

🏠 Host

Since the host app bundle ID keeps returning nil in iOS 27 beta, the hostApplicationBundleId property is now deprecated, and will always return nil. See the documentation for ways to work around this.

🔣 Layout

The keyboard switcher key placement is adjusted on older devices, and the DeviceConfiguration applies the updated edge insets on iPads running iOS 18 and earlier.

📦 Namespaces

This version implements the namespace changes for the Layout, Localization, Proxy, Settings, Status and Themes features. This involves a lot of cleanups and renamings.

🎛️ Settings

The KeyboardSettingsPicker has been extended with more functionality, to make it easier to port various pickers to use this component in the future. This will reduce the amount of picker code in the library.

Conclusion

KeyboardKit 10.6 makes faster and more stable to launch KeyboardKit-based keyboards. The version also adds new features, like improved spacebar drag, and starts flattening namespaces for improved discoverability.

For more details, see the KeyboardKit 10.6 release notes. Upgrade now to take advantage of all improvements.

WWDC 26

WWDC 26 came and went without any major announcements that directly affect KeyboardKit or the custom keyboard parts of the system. It’s more or less business as usual, with new features rather than disruption.

That said, we are keeping an eye on Apple’s Foundation Models and on-device capabilities that keep improving over time. We already use these models for some predictions, and will explore how to take things further.

iOS 27 Beta

We have started testing KeyboardKit against the iOS 27 developer beta to identify features and design choices that may need adjustments before the final release.

For those who went through the Liquid Glass transition last year: unlike then, where devices still on iOS 18 kept the old pre-Liquid Glass design, any tweaks we make for iOS 27 will also apply to iOS 26.

iOS 26.4 Host Application Bundle ID

Since iOS 26.4, the host application bundle ID has been returning nil in keyboard extensions. We had hoped this would be resolved, but testing on the iOS 27 beta shows the same behavior persists.

We are taking this as a signal that Apple no longer will support this in its current form. Until they provide public ways to identify and navigate back to the host application, we’ll pause our efforts and shift focus toward UI/UX.

Q2 Releases

Two releases shipped this quarter:

KeyboardKit 10.4 focused on performance, with improved keyboard launch times and new ways to launch the main app with a specific reason from within the keyboard extension.

KeyboardKit 10.5 was a broader release, adding a new language, new accessibility tools, new 26.4 emojis, new autocomplete settings, and much more.

KeyboardKit 11

We have put a lot of care into designing the KeyboardKit feature namespaces, but think we went too far with type nesting. We will therefore begin moving views, styles, and other important types out of their namespaces and into the top level, to make the SDK easier to explore and use. This will be complete in KeyboardKit 11.0.

Beyond that, KeyboardKit 11 will focus on bringing Swift 6 support for structured concurrency, and migrate from ObservableObject to Observable, requiring iOS 17 as the minimum deployment target.

Licensing Updates

We are happy to announce that all business licenses now include an expiration grace period, making it easier and smoother to renew your license files without any interruption, giving you and your users more time.

This applies retroactively to existing licenses. We will begin sending out updated license files to all business license customers starting this week. Don’t hesitate to reach out if you have any questions.

Background

KeyboardKit 10 added support for binary license files, which can be validated on-device, without having to use a network call to contact a remote license validation server.

Since keyboard extensions need Full Access to make network calls, this means that keyboards that use a license file don’t need Full Access to validate licenses.

However, bundling a license file with your app means that the app must be updated with a new license file when you renew your license. KeyboardKit Pro will stop working in older app versions, when their license file expires.

To make this process smoother and give you and your users time to upgrade, our business licenses has offered expiration grace as an add-on service. Starting today, this is automatically included in all business plans.

How does it work?

Starting today, all standard Business licenses now include a 1 month expiration grace period, which means that the license file can be used for an additional month after your license expires, before it stops working.

Furthermore, all Business+ licenses include a 2 month period to allow for an even longer upgrade period, and all Enterprise licenses start with 3 month, with the possibility to extend it even more.

Note that the expiration grace period is NOT intended to delay invoice payments. You will still be contacted a month before your license expires, and will receive a renewal invoice as soon as you confirm that you want to renew your license. Your license will renew from the expiration date.

Rollout

We will start rolling out this change today, and will send our updated license files to business license customers throughout the upcoming week.

We trust this change will be a welcome addition to our business offering, and that it will remove some previous timing complexities when renewing your license. Don’t hesistate to contact us if you have any questions.

Background

For those who haven’t followed, Fleksy was one of the few companies offering a commercial keyboard SDK for mobile platforms. This made them a serious competitor to KeyboardKit, in a very niche market.

At some point last year, Fleksy quietly stopped developing their SDK without any public announcement. No blog post and no statement on their website. The website stayed up, but things like the pricing matrix were removed.

This created confusion in the keyboard SDK space. During a period, we were regularly contacted by developers and companies asking us about the state of Fleksy, whether it was still being maintained, whether the company was still operating, and whether to look for alternatives.

As a competitor, that’s a strange situation to be in. We didn’t have any answers. All we could do was point to the lack of activity, let people draw their own conclusions, and hope they would consider giving KeyboardKit a try.

The Shutdown

The shutdown of the Fleksy website hopefully puts an end to this ambiguous chapter. Whatever was still active, this is about as definitive a signal as you can get that the SDK is no longer available.

We don’t want to further discuss or elaborate on the reason behind why Fleksy decided to sunset their website and SDK, or the way in which it happened. We just hope that if you are affected, this post can guide you forward.

Moving Forward

If you are currently using the Fleksy Virtual Keyboard SDK and are looking for a way forward, we would love to help. KeyboardKit has been in active development for years, offers a modern Swift- and SwiftUI-based API, and is built specifically for iOS keyboard extensions.

Feel free to reach out to us to start a conversation. We are happy to discuss what a transition might look like for your app or product. There is no pressure and no sales pitch, just a genuine offer to help if you are stuck.