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.

New Locale

KeyboardKit 10.5 adds support for 🇦🇪 Arabic (PC), which is a variant of the classic Arabic layout, with different keys and callout actions.

🌱 Essentials

The KeyboardController protocol has a new resetKeyboardInputType function which is used by the system to disable emoji search when the text input moves.

♿️ Accessibility

This version adds a new KeyboardAccessibility namespace, with new accessibility settings that let you adjust the font weight and button height.

💡 Autocomplete

This version adds a new additionalAutocompletions dictionary, and adds more standard suggestions to additionalAutocorrections. This makes suggestions more accurate, and lets you register custom values.

For instance, the default autocompletions dictionary now contains the suggestion “he’ll” for “hell”. Unlike before, this manual addition will be a regular suggestion, and not an autocorrecting one.

The Autocomplete.SettingsScreen has a new toggle that can be used to hide the autocomplete toolbar. You can also toggle the AutocompleteSettings.isToolbarEnabled property with code.

Besides all this, the Autocomplete.StandardAutocompleteService has been improved to filter out any duplicate suggestions.

🔣 Layout

The KeyboardLayout.DeviceConfiguration type now supports defining custom edgeInsets, which is applied to the edge of the keyboard. The standard layouts are adjusted to use it on Liquid Glass iPad devices.

The standard keyboard layouts now place the keyboard switcher first on Liquid Glass iPad devices, which aligns better with the native Liquid Glass layouts.

🌐 Localization

The new KeyboardLocale namespace is used to contain all locale-specific types. This lets us use Locale for Foundation-specific extensions.

The native Locale has a new .arabic_pc locale, which adds Arabic (PC)-specific layouts and callouts to KeyboardKit.

😀 Emojis

This version adds support for all new iOS 26.4 emojis - 🫪🧑‍🩰🫍🫈🛘🫯🪊🪎 - as well as skin tone support for two person emojis.

The EmojiKeyboard now supports skin tones in emoji search. The KeyboardInputViewController will now also cancels emoji search when the cursor moves.

📄 Proxy

The UITextDocumentProxy has a new moveTextInputCursorToRefreshContext(sleepInterval:) extension, which can be used to move the cursor in a controlled way, to refresh the document context.

🎛️ Settings

The Keyboard.SettingsScreen is moved to KeyboardSettings and LocaleSettingsScreen has been moved to KeyboardLocale.

🎨 Styling

The new version slightly increases the font weight for image and lowercase keys, and redesigns the content view of all swipe down-enabled keys to look a bit more like native.

Conclusion

KeyboardKit 10.5 adds support for a new locale, and adds new accessibility features. It also adds several small capabilities to the various types, polishes the design, and fixes some bugs.

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

Why We Rebuilt

The previous KeyboardKit website had a lot of information, but didn’t guide visitors to where they needed to go. Basic building blocks were stacked together without any clear structure or purpose.

This made it hard for us to add new content. With no clear structure to follow, new information had no natural home. Visitors felt that too, often struggling to understand the product and to find what they were looking for.

In contrast, the new site, as shown by Lovisa in her announcement video, has a purpose with every section and page. This makes it easier for us to add content, and easier for visitors to find it.

The Design Philosophy

For this project, Lovisa’s core design philosophy was to design for decision-making. That meant structuring the new site to serve both technical and business audiences, reducing friction, and building trust.

Guiding Dual Audiences

The KeyboardKit site serves two distinct groups: developers (often coming from GitHub) who want to evaluate the technology, and decision-makers (CTO/CEO) who care about business value and commercial fit.

The new site structures information so developers get the technical details they need instantly, while decision-makers are presented with the business value up front.

From Information to Conversion

The new site communicates what KeyboardKit is and highlights the value it creates. By building natural paths toward both features and commercial plans, the site guides visitors to the information most relevant to them.

Reducing Cognitive Load

By streamlining the information architecture, the new site makes it easier to find what you need. Its structure guides visitors through the content, and the new side menu makes long articles easier to navigate.

Establishing Professional Weight

For B2B clients, trust is everything. The new site moves from a “project feel” toward a business-grade finish that matches the ambitions of the product, and the expectations of the clients KeyboardKit wants to attract.

Conclusion

We hope you will love the new site as much as we do. We couldn’t have asked for a better collaboration. Make sure to reach out to Lovisa if you need help to improve your company or product website.

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.