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.

💥 Secondary Swipe Actions

KeyboardKit 10.1 adds swipe down actions to iPad, when creating a layout with alphabetic, numeric, and symbolic input sets. These actions are applied for most supported locales.

Swipe down actions are currently disabled for locales where the final result was not good enough.

🧪 Experiments

KeyboardKit 10.1 adds a new way to handle experimental features, with the new Experiment enum.

The enum can be used to enable and disable active experiment. You can present these experiments to your users if you want to give them the choice to opt-in to an ongoing experiment.

Completed experiments remain as inactive, deprecated enum cases until the next major version, in which they are removed.

⚡️ Performance

KeyboardKit 10.1 improves the typing and view rendering performance through layout caching and view hierarchy cleanups. This results in less layout calculations and fewer views to render.

Layout caching

Layout caching is a new, experimental feature that aims to reduce expensive layout recalculations. It’s disabled by default and can be enabled with Experiment.layoutCaching.setEnabled(true).

View hierarchy cleanups

The keyboard button gesture view modifier has been optimized by removing a geometry proxy for each modifier. This results in a cleaner and lighter view hierarchy.

📱 App

The KeyboardApp.HomeScreen is no longer a Pro feature. This means that it can be used by everyone.

The screen will only render links to the features that are included in your license, but it will show the keyboard status, and let you customize it with the header and footer view builders.

🏠 Host Application

KeyboardKit 10.1 lets you create and pass in your own custom host application values. This lets you extend the host application logic with more apps than what is known by the SDK.

⌨️ External Keyboards

The ExternalKeyboardContext has a new isEnabledOnSimulator property. This is false by default, to avoid a bug where the keyboard could auto-collaps when running on a Simulator.

Conclusion

KeyboardKit 10.1 adds many new features, improves performance, and fixes many small bugs and inconsistencies. For more info, please see the KeyboardKit 10.1 release notes.

When we started working on KeyboardKit 10 years ago, we were intrigued by the complex challenge of replicating the native iOS keyboard. We have now had the luxury of working on it for many years, and have gotten to meet many amazing people and companies along the way.

One such person is Alex and her team at BiAffect, who created a custom keyboard to enable mental health research through the analysis of a person’s typing profile. The way in which a person types lets BiAffect detect if a person is entering or already in a bipolar episode. This makes it possible to get early help, and to get a deeper understanding on illness patterns and behaviors.

Mental health is one of many very exciting areas where a custom keyboard is a critical enabler, and BiAffect goes way beyond what we envisioned when we started working on KeyboardKit. Check out Alex’s talk for inspiration on how a custom keyboard could benefit you or your company.