Keyboard Launch Time

This version improves the keyboard launch time, by making the keyboard controller postpone costly operations until the keyboard has appeared.

Host Application

This version adjusts the hostApplicationBundleId logic to handle the breaking changes in iOS 26.4, which remain broken in the 26.5 betas.

While the host application bundle ID is broken, you should consider a UX workaround, for instance by letting your users pick a HostApplication with the new HostApplication.Picker. But if this truly cripples your app, you should consider filing a feedback or using a TSI (technical support incident).

App

This version adds a new openMainApp action that can open the main app from the keyboard, with an optional reason. The reason is persisted in a new KeyboardAppContext, which is available to the app.

For instance, launching the main app to start dictation will set the context reason to dictation. The main app can then check this property and if dictation is started, and show a message or toast that tells the user to tap the back arrow to return to the keyboard.

The reason is automatically reset when the main app is sent to the background, which means that any such message will automatically be hidden once the reason has served its purpose.

Autocomplete

The Autocomplete.Toolbar can now be set to scroll with the new autocompleteToolbarScrollMode view modifier and the new Autocomplete.ToolbarScrollMode enum.

Conclusion

Since the breaking host application changes in iOS 26.4 remain in 26.5, we should take this as a hint to design our keyboards to work around these limitations. KeyboardKit 10.4 therefore adds new ways to manage the host application and open the main app with a reason, to allow for better UX.

For complete details about all changes, see the KeyboardKit 10.4 release notes. Upgrade today to take advantage of these new features and improvements.

The previous icon

The previous icon has been with us for a while. Designed by digital artist Matthew Skiles, it added a glass-like, glowing design to the original, plain keyboard key design.

While we absolutely loved this design, we have struggled with explaining what the A in the old icon stands for. All attempts to tweak it to better communicate KeyboardKit have been unsuccessful.

The new product icon

The new icon design takes a more abstract approach. Rather than having a literal key, it places two discrete, K-like glass-shapes on top of the gradient background from the previous icon.

This icon design lets us carry over the color identity from the original icon and stay true to our visual roots, while taking the brand in a new, exciting direction.

App icon variants

While the new KeyboardKit product icon is a colorful bundle of joy, we acknowledge that its colorful style can be distracting in certain contexts.

This is why we will tone it down for the KeyboardKit app - and instead let the same glass shapes be placed on a single color gradient.

This toned-down approach will let the KeyboardKit icon fit in better on the iOS home screen, while the original can still be allowed to pop in marketing material.

While this design is probably too plain, we will iterate on it to find something visually distintivtive for the iOS home screen, while at the same time let the app users switch to the colorful icon if they like.

Implementation

The new icon is a work in progress. We’re trying it out in the open rather than waiting for a perfect result behind closed doors, and we expect to tweak it as we see how it looks in different contexts.

As such, you may find that the previous icon is still being used in some places. We’ll update these as the rollout continues, and would love to hear what you think.

The Issue

In the iOS 26.4 betas and RC, the hostApplicationBundleId value is empty. This affects a keyboard’s ability to identify in which app it’s currently used.

When the host application bundle ID becomes empty, keyboards may not be able to:

• Provide app-specific customizations or behaviors.
• Implement context-aware features that depend on knowing the host app.
• Navigate back to the keyboard from the main application, during dictation.

Many keyboard developers, including those not using KeyboardKit, have reported encountering this problem, which is caused by private APIs being changing in iOS.

What We Know

The issue has is documented tracked in the KeyboardKit GitHub repository. For more information, discussions, and updates on this issue, please visit this bug report.

KeyboardKit Implications

This iOS 26.4 change will affect KeyboardKit in different ways, based on which version you’re using.

• KeyboardKit 10.2.1 and earlier uses Objective-C to parse the host application information. This approach crashes when the bundle information is missing.

• KeyboardKit 10.2.2 and later uses Swift to parse the host application information. This is more robust and will not crash, but the bundle identifier will be empty.

It’s very important that you promptly upgrade to KeyboardKit 10.2.2 or later to avoid this crash.

Workarounds and Next Steps

While we look at alternatives, or until Apple issues a fix, developers experiencing this issue should:

• Upgrade to KeyboardKit 10.2.2 or later.
• Implement graceful fallbacks when the bundle ID is empty.
• Avoid relying on the host application for critical functionality.
• Monitor the GitHub issue for more information and updates.

We’ll continue monitoring the situation and will update you as more information becomes available or when Apple releases a fix. Please share any findings in this issue.

Reporting your problems to Apple

We urge the community to report this problem to Apple, using the Feedback Assistant. If you do, consider referring them to our feedback with the FB22247647 ID.

Our bug report

This is a copy of the bug report that we have reported to Apple, using the Feedback Assistant:

OBS! We’re fully aware that this bug report refers to private APIs, which you take no responsibility for and strongly discourages people to use. However, being able to identify a custom keyboard’s host application is critical for custom keyboard developers, to be able to tailor the UX and features to fit the currently active app, and to be able to smoothly navigate back to the keyboard from the main app. This feedback shares what has stopped working, with the hopes that you can reverse the removal, or replace it with a proper, public API.

PROBLEM: We have started noticing crashes in iOS 26.4, that are caused by a private API that has been used by keyboard extensions to resolve the bundle ID of the host application that is currently using the keyboard. The reason for the crash is that the last steps of resolving the bundle ID has started returning nil in 26.4. This caused a crash in apps that used old Objective-C ways to try to parse the nil value.

FIXING THE CRASH: The attached code below uses a newer approach, which uses Swift to parse the string. This code doesn’t crash, but it still returns nil as bundle ID.

IMPLICATIONS: When the host application bundle ID becomes nil, developers are no longer able to identify the host application. This causes severe problems for keyboard developers that tailor the keyboard functionality to the host application, or need the host application ID for critical features. While we understand that you may want to remove or change private APIs over time, this particular change will strongly affect all custom keyboards and lead to a much worse user experience. Some keyboards will be severely crippled by not being able to access the host application bundle ID.

SUGGESTION: Due to the severe implications of this change, we ask you to reverse the removal that causes this to return NIL, or replace it with a proper, public API to let custom keyboard developers identify the host application in a safe manner. You can require Full Access and limit the capability to the UIInputController type.

Keyboard Essentials

The KeyboardInputViewController gains a new viewWillSetupKeyboardKit() function, providing you with better control over the keyboard setup lifecycle.

This new function allows for more precise timing when configuring the keyboard, and avoids any side-effects of overriding viewDidLoad and failing to call super.viewDidLoad().

On-Device Next Word Prediction

KeyboardKit 10.3 brings support for local, on-device next word prediction using Apple’s Foundation Models. This is available on iPhone 15 Pro and later devices running iOS 26.1 or higher.

The new Autocomplete.NextWordPredictionMethod.local method has been added to make it easy to enable this functionality with code or from the settings screen. This method is enabled by default.

The next word prediction in Autocomplete.SettingsScreen has been redesigned to better showcase this new option, making it easier for developers to configure and for users pick it manually.

Faster License Validation

KeyboardKit Pro license validation has been significantly optimized in this release. KeyboardKit now validates licenses much faster, dramatically reducing the flickering that could occur during keyboard initialization. This improvement creates a smoother experience when your keyboard first appears.

Additionally, the Keyboard.ToggleToolbar now displays the base toolbar view even when no license is registered, to provide a nice fallback in case of license expiration.

Layout Improvements

This release brings enhancements to keyboard layout rendering. The standardPhone configuration has been updated to use a 51-point row height in iOS 26, to match Apple’s updated designs.

Layout caching is now enabled by default, and has been converted from an experiment to a setting. This caching mechanism improves rendering performance by storing computed layouts, resulting in faster keyboard display and reduced computational overhead during layout calculations.

Settings and Developer Tools

A new isPredictiveTextVisualizationActive setting has been added to help developers verify that predictive text features are working correctly. This developer-focused setting provides visibility into the prediction system, making debugging and validation easier during development.

Experimental Features

The experiment engine has been refactored for easier use. The Experiment type now provides all you need to get and toggle experiments, and Experiments has been reduced to a plain namespace.

Bug Fixes

This version includes some bug fixes. For instance, the Keyboard.LocaleSettingsScreen now handles locale changes more reliably, preventing edge cases where changes could behave unexpectedly.

Additionally, the keyboard now performs autocomplete more reliably on launch, ensuring users see suggestions immediately when they begin typing.

Conclusion

KeyboardKit 10.3 brings powerful new capabilities with on-device next word prediction, significant performance improvements with faster license validation and layout caching, and more settings and customization options. These improvements make KeyboardKit more capable and performant.

For complete details about all changes, see the KeyboardKit 10.3.0 release notes. Upgrade today to take advantage of these new features and improvements!

🎤 Dictation

KeyboardKit 10.2 has a new .keyboard dictation method that makes it possible to perform dictation directly within the keyboard, with an automated app-sync only when needed.

In-keyboard dictation method will only open the main app to start dictation if needed, then navigate back to the keyboard to perform dictation, keeping an open connection to the dictation engine.

In-keyboard dictation is currently opt-in. Follow the dictation developer guide to set up dictation, then enable keyboard dictation with the dictation settings or the .keyboardDictation experiment.

In-keyboard dictation is the recommended dictation method moving forward. It has new views that provide a great user experience, like Dictation.ProgressView and Dictation.VolumeVisualizer.

The Dictation feature also has new tools like the new Dictation.VolumeRecorder. KeyboardKit Pro unlocks all required tools to easily set up dictation.

The dictation engine supports the following locales, which means you can use it with languages that are not yet supported by the keyboard engine:

Arabic (ar-SA), Cantonese (yue-CN), Catalan (ca-ES), Chinese (zh-CN), Chinese (zh-HK), Chinese (zh-TW), Croatian (hr-HR), Czech (cs-CZ), Danish (da-DK), Dutch (nl-BE), Dutch (nl-NL), English (en-AE), English (en-AU), English (en-CA), English (en-GB), English (en-ID), English (en-IE), English (en-IN), English (en-NZ), English (en-PH), English (en-SA), English (en-SG), English (en-US), English (en-ZA), Finnish (fi-FI), French (fr-BE), French (fr-CA), French (fr-CH), French (fr-FR), German (de-AT), German (de-CH), German (de-DE), Greek (el-GR), Hebrew (he-IL), Hindi (hi-IN), Hindi (hi-IN-translit), Hindi (hi-Latn), Hungarian (hu-HU), Indonesian (id-ID), Italian (it-CH), Italian (it-IT), Japanese (ja-JP), Korean (ko-KR), Malay (ms-MY), Norwegian Bokmål (nb-NO), Polish (pl-PL), Portuguese (pt-BR), Portuguese (pt-PT), Romanian (ro-RO), Russian (ru-RU), Shanghainese (wuu-CN), Slovak (sk-SK), Spanish (es-419), Spanish (es-CL), Spanish (es-CO), Spanish (es-ES), Spanish (es-MX), Spanish (es-US), Swedish (sv-SE), Thai (th-TH), Turkish (tr-TR), Ukrainian (uk-UA), Vietnamese (vi-VN)

⌨️ Keyboard

KeyboardKit 10.2 adds a new .keyboardReplacementOverlay(...) modifier that can be used to easily replace the keyboard view with an equally sized replacement whenever a boolean condition is met.

🧪 Experiments

Experiment has a new .keyboardDictation experiment that affects the .keyboardMethod dictation setting. You can use this to easily toggle keyboard dictation on and off.

Experiments also has a new Experiments.SettingsScreen that can be used to enable experiments. The KeyboardApp.HomeScreen has a link to this screen, that is hidden by default.

🔉 Feedback

The FeedbackContext class has a new isHapticFeedbackAvailable property, which is only true for devices with haptic feedback.

🎛️ Settings

There are many new settings, like the new isCharacterPreviewEnabled and isPredictiveTextEnabled keyboard settings, and isNextCharacterPredictionEnabled autocomplete setting.

The various settings screens have new toggles and structures, to make them provide more options.

Conclusion

KeyboardKit 10.2 adds many new features and improvements. There are also a bunch of bug fixes and general improvements. For more info, please see the KeyboardKit 10.2 release notes.

The current dictation method

As you may know, iOS keyboard extensions are strictly limited by Apple and can’t do as much as you may need. For instance, dictation is hard since a keyboard can’t access the device microphone.

KeyboardKit currently works around this strict limitation by letting the keyboard open the main app to start and perform dictation, then navigate back to the keyboard to apply the result.

While this works fairly well, it’s a lackluster experience for keyboards that rely heavily on dictation. This is why we are happy to announce a brand new dictation method: in-keyboard dictation.

The new dictation method

In-keyboard dictation method will only open the main app to start dictation if needed, then navigate back to the keyboard to perform dictation, keeping an open connection to the dictation engine.

The dictation engine will stay open as long as the main app is alive. This lets the user perform many subsequent dictation operations without having to open the main app, which is a big improvement.

Together with this experience comes a new Dictation.ProgressView which is automatically added to the main KeyboardView while dictation is active, as well as a Dictation.Indicator.

When applying a dictation result, the keyboard will put dictation in idle mode instead of stopping it. This keeps the dictation going, while stopping it from writing to the observed result.

An improved user experience

The user experience will be greatly improved, since the keyboard will only open the main app one time, instead of each time the user wants to dictate.

The result is a seamless dictation experience where the user can start dictation many times without leaving the keyboard. This makes the dictation feature much more useful.

The new progress and indicator views gives you and the user full control. Users can stop dictation at any time, and you can add these views wherever you need them, and customize them freely.

When will this be available?

The new dictation experience will be available as a beta experiment in KeyboardKit 10.2, which will be released later in January.

Don’t hesitate to reach out to discuss how this can help you improve your keyboard-based product.

This amazing deal is valid through November, and works with the Basic, Silver, and Gold tier. This means that you can save up to $2.500 if you sign up for the Yearly Gold Plan!

Enter the following discount code in the checkout flow, to apply the discount to your Pro purchase:

There has never been a better time to go Pro! See the KeyboardKit Pro info page for more details.

Network & Community

We are so happy to have an amazing network of friends and partners. See BlackFridayDeals.dev for other amazing Black Friday deals from the community.