How it Works

In 11.1, KeyboardContext and KeyboardSettings get a new isSplitKeyboardEnabled property. The context value can be used to enable split keyboard during the current session, while the setting is persisted.

When split keyboard is enabled, the iPhone Duo will enable the feature when the screen is in open landscape.

Split keyboard is however not available other iPhone devices, nor when the Duo is closed or open in portrait.

The new split keyboard feature is also available on all iPad devices, in both portrait and landscape orientation.

To simplify using the keyboard in split mode while the device is in landscape orientation, the keyboard will switch over to use the portrait design while split keyboard is enabled.

Duo Hinge Detection

We are investigating how to get access to the iPhone Duo’s hinge information, which is currently not available to custom keyboard extensions. This would let us automatically enable split mode when the device is folded.

Until then, we will add a context menu to the space bar, that allows users to toggle split keyboard mode from the space bar. This will also be available from the dismiss keyboard button.

iPhone Duo Changes

As we write in our previous article about the iPhone Duo, KeyboardKit must be adjusted for iPhone Duo and its various form factors. Besides keys and font sizes, keyboards should also split when the Duo is folded.

A keyboard extension must therefore check if it’s running on an iPhone Duo, and if so adjust the key sizes. If the hinge information indicates that the device is folded, it should split in two halves.

However, it seems that keyboard extensions can’t detect the hinge information. Below are details of what we’ve tried, what works in an app, and what doesn’t work in a keyboard extension.

New Hinge APIs

iOS 27.1 adds some ways to find out how the device is folded, for instance:

• Hinge state – UIHingeInteraction in UIKit and .onHingeChange in SwiftUI. Both report the hinge state (closed, partiallyOpen, fullyOpen) and an angle.
• Reserved regions – UIView.reservedRegions and GeometryProxy.reservedRegions with the .division kind describes where the screen is divided by the fold.

This is exactly what a keyboard extension needs to adjust its keys around the fold. To explore what information a keyboard extension receives, we built a small test app with a KeyboardKit-based keyboard.

Test Project

Test project’s main app target checks the hinge state and division regions with SwiftUI. The keyboard extension checks the same thing in two ways: from the input controller (UIKit), and from the keyboard view (SwiftUI).

We haven’t uploaded the project, but you can reach out if you want to give it a try, and we’ll give you access to it.

Test Results

In the image below, we can see how the iPhone Duo behaves when it’s closed and the outer display is in use:

As you can see, the app shows that the hinge is closed and that there are no reserved division regions, while the keyboard doesn’t have any information.

When the iPhone Duo is semi-open in a folded state, the app updates accordingly, while the keyboard extension still has no information:

Finally, with the Duo fully open, the app still updates accordingly, while the keyboard still has no information:

The app works as expected. It gets partiallyOpen when folded, and fullyOpen when flat. It also gets an active division region for the fold when the device is half-open, and none when it’s flat. Everything updates live as the hinge moves.

The keyboard extension gets nothing.

According to the documentation, the hinge handler is always called with the initial state, and with a nil hinge if the view isn’t in a hierarchy that provides hinge updates. In the keyboard extension it’s never called at all, not even with nil. We also tried adding the interaction to the extension window instead of its view, with no luck.

Implications

The native keyboard knows exactly where the fold is, and splits its keys around it when the device is folded half-open. Third-party keyboards can’t seem to do the same, which means they will look and feel worse than a native keyboard on a folded iPhone Duo.

These results are from the iPhone Duo simulator with iOS 27.1 (Xcode 27.1 RC). We haven’t been able to test on a physical device yet, and will update this post if a device behaves differently.

Conclusion

We have filed a feedback with Apple, asking for this information to be made available to keyboard extensions as well. If you file a feedback, please refer to FB25187339. Duplicates help Apple prioritize.

You can follow the progress in this GitHub issue.

The Settings app

Since the KeyboardKit app behaves just like the iOS Settings app, it made sense to look at how that app behaves on the Duo, and approach it the same way.

When the iPhone Duo is closed, the Settings app uses a navigation stack and pushes new screen onto the stack.

However, when the iPhone Duo is open or folded, the Settings app switches to a navigation stack, with a sidebar to the left and the selected settings screen to the right.

Unlike the default iOS split view behavior, this sidebar is always open, and the toolbar sidebar toggle is hidden, so this is the configuration we’ll go with as well.

iPhone Duo

When the iPhone Duo is closed, the KeyboardKit app behaves just like on a regular iPhone. The main menu is presented as a list, and tapping an item pushes the selected settings screen onto the navigation stack.

When the device is folded, the app switches to a split view, with the sidebar always open. The two screens are placed on each side of the fold to keep interactive elements away from the fold, as Apple recommends.

When the Duo is folded fully open, the sidebar becomes narrower, which gives the selected screen more space. This is closer to how the app behaves on iPad, although the Duo still places the status bar to the right.

As you can see, the app feels right at home on the Duo, regardless of how it’s folded, instead of just stretching out the iPhone layout over the bigger screen.

You may also notice that we redesign the main menu when it lives inside the sidebar, where all menu items are listed without sections (except app-specific ones at the bottom).

iPad

As part of this change, we also redesign the iPad app to use the same split view configuration as the iPhone Duo.

Since the iPhone Duo in open mode share the same navigation model as the iPad, any improvements we make for one device will benefit the other.

Conclusion

The iPhone Duo forces us to rethink how our apps behave on different form factors. The KeyboardKit app will follow the conventions of the native Settings app, to get a consistent experience on all devices.

Some work still remains. For instance, the keyboard preview must be placed outside the split view, since the it doesn’t provide enough space. We must also adjust the keyboard itself to the Duo, as described in this post.

We hope to have both the app and the keyboard ready shortly after the Duo has been released.

The problem

We have started getting bug reports from users of the KeyboardKit app, that the main app and keyboard could freeze randomly.

We had massive problems reproducing this freeze, and everyone we asked to download and test the app did so without any problems.

After receiving a bug report that the issue also manifested itself in the demo app, on iPad 13”, we could narrow down the scope and reproduce the bug. Turns out that a layout change caused an infinite loop.

The reason

The reason for the freeze was the library augmenting a keyboard layout by adding an additional input toolbar.

When augmenting the layout, the library did so with a default layout configuration. This creates a temporary, observable state that is only used to read settings.

This used to work, but in iOS 27 this seems to have changed behavior, and now causes the observable state to update, which causes the keyboard to redraw, which causes the layout to once again be augmented.

The solution

After locating this problem, we could easily sove it by removing the default configuration parameter value. We will remove these default context parameter values and require an explicit configuration to be passed in.

The fix has been out in production for a few days, and all app users have now reported that they can use the app without any hangs.

Conclusion

KeyboardKit 10.9.6 fixes this problem, but was accidentally built with Xcode 27. If you are still on Xcode 26, the 10.9.7 patch update is rebuilt with Xcode 26.6.

TL;DR

The biggest structural changes in KeyboardKit 11, that will most likely affect you, are the Swift 6.2 transition, and how controller state moves from the keyboard context to a new main actor controller context, plus how dictation and host app detection use a new plugin architecture to move sensitive code out of the main library.

Package Updates

KeyboardKit 11 uses Swift 6.2. This made it possible to remove a lot of dispatch and MainActor.run code, which makes the library more stable. This work involved making more types MainActor, while keeping most of the library unchanged. The controller state is therefore moved from the KeyboardContext to a new main actor-bound KeyboardControllerContext, to keep the core context versatile.

The package is also built in a new way that embeds the dSYMs inside the XCFramework. This means that they will automatically be embedded in your app when submitting it to the App Store. No more manual downloads!

The package also ships three new plugins for autocomplete, dictation, and host application, which you can read more about further down.

New Locales

KeyboardKit 11 almost doubles the number of supported locales, bringing the total to 111. This was made possible by the improved diacritics engine, which now supports combining marks. As part of this, we have also improved the layout engine and harmonized many layouts, to keep them consistent across configuration changes, and fixed a bunch of incorrect swipe down actions on iPad.

This includes 13 indigenous North American locales (Apache, Blackfoot, Chickasaw, Chochenyo, Choctaw, Comanche, Kiowa, Lushootseed, Mvskoke, Nez Perce, Osage, Salish, and Wixarika), 6 Sámi locales (Kildin Sámi, Lule Sámi, Pite Sámi, Skolt Sámi, South Sámi, and Ume Sámi), and 15 other locales (Afrikaans, Basque (France), Basque (Spain), Bosnian, English (South Africa), Esperanto, Galician (Spain), Kalaallisut, Kyrgyz, Māori, Romansh, Samoan, Turkmen, Yiddish, and Zulu).

We noticed that submitting these fully functional locales to the App Store causes a warning for unsupported locales. Since they are working within the library, we will investigate if we can silence this warning.

Plugins

KeyboardKit 11 adds a new plugin architecture, which lets us move sensitive code, like permissions and system API usage, out of the core library. This plugin model is an exciting new part of KeyboardKit, and will let us build more capabilities and integrations outside of the core SDK, and let you decide which plugins you want to use.

For instance, the KeyboardKitDictationPlugin contains all you need to enable dictation, and contains all the code that requires permissions. Also, the KeyboardKitHostPlugin has all the sensitive code needed to resolve the host application, which means that you can choose if you want to include it in your app.

The plugin architecture is an exciting new part of KeyboardKit, and will allow us to build more complex features and integrations outside of the main library, and shield the core library from sensitive code.

Swipe Typing

Although KeyboardKit doesn’t include a swipe typing engine, KeyboardKit 11 adds new layout tools and a new KeyboardViewDragGestureOverlay that makes it possible to swipe over the entire keyboard. You should be able to use these tools to provide a swipe typing engine with enough information to enable it in your app.

Feature Updates

Besides these large updates, KeyboardKit 11 has MANY other feature-specific updates. Please see the release notes for a full list of changes.

Conclusion

KeyboardKit 11 is by far our biggest release ever! It builds upon the many drastic improvements made to the library in the 10.9 minor version lifecycle, and sets a solid foundation for the year to come.

We are so excited to release this next major version, and can’t wait to hear what you think. Don’t hesitate to reach out with your feedback, and please see the release notes for a full list of changes.

Important - KeyboardKit 11 Beta 3 is built with Xcode 27. Use Beta 2 if you’re on Xcode 26. The KeyboardKit 11 release will be built with Xcode 26, for maximum compatibility.

Banner Theme

Let’s start with the most important question. What theme will we use for the KeyboardKit 11 version lifecycle?

After KeyboardKit 10’s focus on Earth, we have discussed a new theme for KeyboardKit 11. We usually release ten versions (11.0-11.9), so perhaps something with ten “things”? We could go with the human hand or foot, but that would only be exciting for the first five versions (joke). Surely, we can do better.

KeyboardKit 11 will therefore take us back to space, but this time closer to home than KeyboardKit 9. This time, we’ll blast through the solar system, starting at our magnificent Sun and ending up at Pluto. And before we start discussing everything in KeyboardKit 11… yes, we count Pluto as a planet. So should you.

Major Changes

KeyboardKit 11 uses Swift 6.2 and strict concurrency. This made it possible to remove a lot of dispatch queues and MainActor.run code, which makes the library more stable. This work also involved making more types MainActor, while aiming to keep most of the library unchanged. The KeyboardContext proxy logic is thus moved to a new main actor-bound KeyboardControllerContext, to keep the core context versatile.

KeyboardKit 11 almost doubles the number of supported languages, bringing the total to 111. This was made possible by the improved diacritics engine, which now supports combination marks. We have also improved the layout engine and harmonized many layouts, to keep them consistent across configuration changes, and fixed a bunch of incorrect swipe down actions on iPad.

KeyboardKit 11 also adds a new plugin architecture, which lets us move sensitive things like permissions and system API usage, out of the core library. The plugin model is an exciting addition to KeyboardKit that will let us add more capabilities and integrations outside of the core SDK, and making any use of features that require permissions or special APIs an intentional developer choice.

Finally, this version removes deprecated code, ends all experiments, and uses LocalizedStringResource for UI components localization.

Plugins

Another big change is the new plugin architecture that allows us to move sensitive or complex code out of the library, as well as 3rd party integrations.

KeyboardKit 11 ships with two plugins - KeyboardKitDictationPlugin and KeyboardKitHostPlugin - as well as a KeyboardKitAutocompletePlugin placeholder that will ship in an upcoming version.

Feature Updates

While many features have been adjusted to the concurrency changes mentioned above, you should still feel at home with the overall structure, which doesn’t change all that much.

📦 Package

KeyboardKit 11 uses Swift 6.2 and strict concurrency, and defines brand new plugin products.

• The package now uses Swift 6.2 and strict concurrency.
• The package defines new KeyboardKit...Plugin products.
• Many types are now Sendable, and those that need it @MainActor.
• dSyms are now included in the package - no need for a separate download.

🌱 Essentials

KeyboardKit 11 cleans up large parts of the library, and removes parts that were previously soft-deprecated.

• Keyboard.Background and Keyboard.BackgroundStyle are now separated.
• KeyboardContext has a new localePresentationCase that defaults to capitalized.
• KeyboardControllerContext is a new context type for controller-specific state.
• KeyboardInputViewController has a new setPreferredKeyboardCase() function.
• KeyboardInputViewController’s setup function can now inject autocomplete engines.
• KeyboardInputViewController’s setup function can now inject a host application resolver.
• KeyboardState has a new controllerContext property of type KeyboardControllerContext.

🧩 Extensions

KeyboardKit 11 adds a bunch of new extensions, and cleans up old ones that are no longer used by the library.

• ProcessInfo has a new isLiquidGlassAvailable extension.

💡 Autocomplete

The new KeyboardKitAutocompletePlugin is currently empty, but will be used to define additional autocomplete engines in future KeyboardKit versions.

• KeyboardKitAutocompletePlugin is a new plugin package.
• AutocompleteContext no longer uses dispatch queues to update itself.
• AutocompleteContext’s isLoading has been removed.
• AutocompleteContext has a new controllerThrottleInterval property.
• AutocompleteEngine is now public and adjusted to align with the plugin.
• AutocompleteEngineWithDownloadSupport is a new protocol.
• AutocompleteService moves some logic to the engine protocol.
• AutocompleteService has a new supportedLocales property.
• AutocompleteService has a new warmUp() function.
• AutocompleteService.autocomplete(_:updating:) is now async throws.
• AutocompleteSettings’ isAutoLearnEnabled has been removed.
• AutocompleteSettingsScreen has been cleaned up and polished.
• AutocompleteSuggestion now defines a new .deleteBackwardsCount.
• AutocompleteSuggestion’s .isUnknown is renamed to isCurrent.
• AutocompleteSuggestionSource is a new enum with known sources.
• StandardAutocompleteService warms up its engine to avoid a launch hangs.
• StandardAutocompleteService now honors the new delete backwards count.
• KeyboardInputViewController will use the new context throttle to throttle autocomplete operations.

🎤 Dictation

The new KeyboardKitDictationPlugin makes it a LOT easier to set up dictation. You don’t have to copy any code since the plugin contains everything, and must only add Info.plist permissions if you use it.

• KeyboardKitDictationPlugin is a new plugin package.
• KeyboardKit has ways to inject a dictation engine.
• DictationEngine defines a standard implementation in the plugin.
• DictationMethod is removed, since dictation now uses a single method.
• DictationVolumeRecorder and DictationSpeechRecognizer are now in the plugin.

🏠 Host Application

The new KeyboardKitHostPlugin contains all host application bundle ID logic, including all sensitive system API usages. This means that the system API usage is not completely opt-in for developers.

• KeyboardKitHostApplication is a new plugin package.
• KeyboardKit has ways to inject a host application resolver.

🌐 Localization

KeyboardKit 11 view localization now uses LocalizedStringResource instead of String. This makes it easier to localize these parts, and will let us localize these components in more locales in later versions.

• All screen localization types now use LocalizedStringResource.

⚙️ Settings

KeyboardKit 11 has rewritten the settings store to work better with Swift concurrency.

• KeyboardSettings uses a new thread-safe store resolver.
• KeyboardSettings now requires a deviceType when created.
• KeyboardSettings has new resetStore(for:) and resetStore(forAppGroup:) functions.

🐛 Bug Fixes

• KeyboardAction adjusts the presentation for multi-char currencies like “kr”.
• KeyboardInputViewController now performs a new autocomplete when the locale changes.

🚨 Breaking Changes

• All deprecated code has been removed.
• DictationMethod has been removed.
• DictationSpeechRecognizer has been removed.
• DictationVolumeRecorder has been removed.
• GestureButtonScrollState has been removed.
• KeyboardApp’s .keyboardSettingsKeyPrefix has been removed.
• KeyboardContext moves proxy logic to controller context.
• KeyboardContext moves Liquid Glass logic to ProcessInfo.
• KeyboardContext’s .autocapitalizationTypeOverride has been.
• KeyboardExperiment has no active experiments.
• KeyboardExperimentContext has been removed.
• KeyboardExperimentSettings has been removed.
• KeyboardHostApplicationProvider has been removed.
• KeyboardInputViewController lifecycle functions have been reduced.
• KeyboardInputViewController now syncs to its contexts, not the other way.
• KeyboardSettings.store and .storeKeyPrefix are no longer mutable values.
• KeyboardInputViewController’s .originalTextDocumentProxy is now fully internal.

Release Process

We are aiming to release KeyboardKit 11 on October 1st, after iOS 27, macOS 27, and Xcode 27 have been released, with some extra time to gather developer feedback.

Feedback

We will continue to release refined betas as we bring KeyboardKit 11 closer to release. Make sure to reach out if you run into problems, or if you have any feedback or suggestions.

Conclusion

KeyboardKit 11 is a big update, and while the concurrency updates are the most prominent change, there are a bunch of things in this release that make it the strongest major update so far.

KeyboardKit 11 sets the direction for the year to come. We hope that you’ll like it and look forward to another exciting major version year. We have so much planned, and can’t wait to share it with you.

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

iOS 26.4 - Host application problems

By being able to identify the host application a custom keyboard can customize itself for the app that’s using it, and can allow the main application to navigate back to the keyboard, for instance after starting dictation.

The host application bundle ID resolver suddenly stopped working in iOS 26.4. This affected many keyboards, including those that don’t use KeyboardKit. As described in this post, KeyboardKit 10.9 made this work again.

iOS 27 - SwiftUI gesture lag

As described in this post, keyboard gestures started lagging in iOS 27. A press action is sometimes delayed until release, or after a ~1s delay. Since the action still triggers, things may seem to work, but typing feels “off”.

KeyboardKit 10.9.4 fixed this by rebuilding the gesture engine from scratch. The new engine feels a lot snappier and keeps the same public API, which means that you get the fix without changing any code.

iOS 27.2 Beta - Layer geometry crashes

A developer recently reported that their keyboard extension crashed after typing a few words on iOS 27.2 beta, with a CALayerInvalidGeometry exception caused by a SwiftUI layer with NaN bounds.

The crash had no application frames at all, which made it very hard to attribute. It turns out that upgrading from KeyboardKit 10.3 to 10.9.5 fixed the problem, without any code changes.

SwiftUI freezes

Previously working code has begun freezing on later versions of iOS. For instance, enabling the additional input toolbar would trigger an infinite loop, which would result in a blank keyboard.

The input toolbar freeze was caused by a default init parameter, which has been in the code for a very long time. KeyboardKit 10.9.6 fixes this freeze by instead passing in an explicit value.

KeyboardKit 11

With KeyboardKit 11 being scheduled to release on October 1st, upgrading your application to use the latest version of KeyboardKit will make it a lot easier to migrate to KeyboardKit 11.

Conclusion

KeyboardKit keeps up with changes in iOS so that you don’t have to. Upgrade to the latest version to make sure that your keyboard works as well as possible on the latest iOS versions.

If you run into any problems when upgrading, don’t hesitate to reach out.

iPhone Duo

Since you most probably already know most about the iPhone Duo, we won’t go through it in detail, but in short it’s a smaller device that compensates for it’s shorter height by moving the status bar to the right.

The iPhone Duo can then be folded out into twice it’s size, which brings it closer to an iPad in size and behavior.

Let’s look at how the Duo’s native keyboard behaves, and compare it to how KeyboardKit behaves on the Duo.

Closed Keyboard

When the Duo is closed, the keyboard is more or less what you’d expect, although a couple of things stand out.

Notice how the globe and dictation buttons are added to the keyboard’s bottom row. This is a new behavior for iPhone, where FaceID devices add these buttons outside the keyboard area. Let’s compare it with KeyboardKit.

While the keyboard looks good, it still behaves like on a regular device and doesn’t add these two buttons to the bottom row. Since the Duo also doesn’t add them, we end up without the buttons altogether. This must be fixed.

Folded Keyboard

When the Duo is folded, we can immediately see a big difference - the keyboard is split around the screen fold!

Apple strongly recommends moving interactive elements away from the fold, and the keyboard is no exception. Also notice that the globe and dictation buttons are now outside the keyboard. Let’s compare with KeyboardKit.

Since KeyboardKit still behaves like on a regular device, it renders with the landscape configuration, which leads to smaller keys. It also doesn’t split the keyboard in two, but it does get the globe and dictation buttons.

Open Keyboard

When the Duo is folded open, things start to behave like normal again. We get a solid landscape keyboard with the globe and dictation buttons placed outside the keyboard.

However, notice how the rows are a bit uneven, with different width. Let’s compare it with the old design, which is still used in the KeyboardKit keyboard.

This works, but the keyboard behaves like on a regular device, with shorter keys, smaller font, and with all rows except the second being even in width.

Conclusion

The iPhone Duo forces us all to adjust our apps to its new form factors, and KeyboardKit is no different. We will tweak the keyboard layout and sizes to the new configurations, and start looking at a split layout.

This work will begin after the KeyboardKit 11 release, which is scheduled for October 1. After that, we hope to get support out shortly after the Duo has been released.

Background

KeyboardKit’s autocomplete engine is built on top of Apple’s on-device technologies, which means that the set of languages that it can autocomplete is determined by the OS, not by KeyboardKit.

When Apple adds or removes languages from the on-device tools, KeyboardKit’s autocomplete changes with it. This is mostly a good thing, since KeyboardKit evolves with the platform, but it also means that things can break.

iOS 27 makes a few such changes, both good and bad, that affects KeyboardKit without any changes on our end.

New Locales

iOS 27 adds support for the following locales:

• 🇵🇭 en_PH - English (Philippines)
• 🇯🇵 ja_JP - Japanese
• 🇰🇷 ko_KR - Korean
• 🇨🇳 zh_Hans - Chinese (Simplified)
• 🇹🇼 zh_Hant - Chinese (Traditional)

Japanese, Korean, and Chinese are big additions, since these are some of the most requested languages that we are yet to support. While autocomplete is not the same as a full input support, it’s a big step forward.

Improved Locales

iOS 27 improves autocomplete for the following locales:

• 🇧🇬 bg - Bulgarian
• 🇮🇱 he_IL - Hebrew (Israel)

While these locales were supported before, we find suggestions & corrections to be noticeably better in iOS 27.

Broken Locales

Unfortunately, iOS 27 breaks autocomplete for the following locales:

• 🇬🇷 el - Greek
• 🇭🇺 hu - Hungarian
• 🇮🇸 is - Icelandic

These languages still work in iOS 26 and earlier, but no longer returns any suggestions in iOS 27. Since this is a system change, there’s nothing KeyboardKit can do to restore the support, other than to report it to Apple.

If your keyboard targets any of these languages, you may want to verify how your keyboard behaves in iOS 27, and consider a remote autocomplete service or a custom AutocompleteService as a fallback.

Conclusion

Since KeyboardKit’s local autocomplete relies on the system text checker, the language support keeps changing with each new iOS version. This means things will improve over time, but that things may also break.

If you notice any other changes in iOS 27, or have any feedback on the KeyboardKit 11 beta, please reach out.

Documentation Changes

The KeyboardKit 11 documentation is updated with regards to the removed, deprecated code, and all the new features in the next major KeyboardKit release.

For instance, the documentation has been updated with information on how to enable host application resolving with the new KeyboardKitHostPlugin and dictation with the new KeyboardKitDictationPlugin.

Since the SDK is simplified in KeyboardKit 11, the updated documentation also removes some developer guides, and instead simplifies the information and puts it directly in the feature article.

Expected Release

The online documentation is still built for KeyboardKit 10, but the updated documentation will replace it as soon as KeyboardKit 11 is released.

We expect to release KeyboardKit 11.0 on October 1st. Don’t hesistate to reach out if you have any feedback on the beta release or the new documentation.