Custom keyboards in iOS 8: Explained

July 10, 2014

Custom keyboard extensions, part of iOS 8's new Extensibility feature, allow developers to almost completely replace the default, system-wide iOS keyboard with ones of their own devising. (That's in addition to Apple's own, new QuickType predictive keyboard.) Not only does that include favorites from other platforms, like Swype or SwiftKey, but it opens the door to ones that offer new languages, novel input methods, special options, and more. So, how do the new custom keyboard extensions work?

From in app to out

For a while now Apple has let developers create and deploy custom keyboards, but those keyboards could only exist within their own apps. For example, Apple itself created and deployed a custom, spread-sheet optimized keyboard for Numbers.

VNC and Remote Desktop apps have used custom keyboards that include OS X or Windows-specific modifier keys. Social network apps have added rows to the default keyboard that include @mention, #hashtag, and even camera access characters above and beyond those in the default keyboard type layouts. SwiftKey and other third-party keyboard companies have even created note-taking apps just to make their custom keyboards available on iOS within those specific apps.

Now, however, custom keyboards can break free of their app jails and be used system-wide, in every app, and for almost anything.

How custom keyboards work

Even though custom keyboards are designed to work throughout iOS, they still have to be contained in an app. So, for example, to install SwiftKey on your iPhone or iPad, you'll have to download the SwiftKey app. The SwiftKey app's custom keyboard extension will then make itself available system-wide.

The next time the default keyboard appears, you'll be able to tap the globe (keyboard change) button, select the custom keyboard, and start typing with it.

There are still some lingering questions when it comes to implementation. For example, if you install the Swype app to get the Swype keyboard, what would the app itself do when you launch it? If the Swype app is deleted, the custom keyboard extension gets deleted with it, so would there be a warning provided to make sure people know and understand that, especially if they haven't looked at the app in weeks or months and forgotten why it exists?

Download/delete/re-download is a simple process understood my hundreds of millions of iPhone and iPad customers. Extensibility offers new functionality beyond that of the traditional app. Somewhere, somehow, both Apple's procedures and our understandings are going to have to grow and mature.

Custom keyboard limitations

While custom keyboards can, for the first time, exist beyond the confines of their own apps, there are still many limitations placed on them. Some of these are philosophical — Apple has strong opinions on security and privacy. Others may be technical.

To start with, by default custom keyboards are restricted to the local device. They can't access the internet without explicit permissions. They also can't be used in secure text fields, like those for passwords. More on that in the security and privacy section.

Moreover, custom keyboards don't have access to the built-in keyboard toggles in Settings either, but a custom set of settings can be created just as they can for any other type of app. They also don't have access to the phone system (phone pad), which adhere to a strict set of input characters mandated by the carriers.

In all of those cases, the default iOS 8 keyboard will replace the custom keyboard, and then return to it when eligable input fields become available.

Custom keyboards also can't be used to select text or move the input position around. So no PC-style arrow key and cursor simulator keyboards. That kind of functionality is currently only available for the app hosting the keyboard. Likewise, the keyboard can't project its own editing commands, like copy/paste into an app, nor can it currently draw above the top row of the keyboard the way the default one does.

Remember, this is Extensibility 1.0, and doubtless custom keyboard extensions, like everything else, will continue to evolve over future versions of iOS.

Developing custom keyboards

Apple intends for custom keyboards to offer something that's above and beyond what Apple's own keyboard provides, and is useful system-wide, not simply applicable to its own, specific app. That includes things like languages Apple doesn't currently support, and input methods and prediction system different from the ones used by Apple's QuickType.

They can work via taps, swipes, gestures, and anything else supported by multitouch, but they have to work the way people have come to expect. Input has to be taken and output has to be delivered. And they have to not only be functional but feel lively and responsive.

Custom keyboards also have to let people switch to and away from them using something akin to the 'globe' button Apple provides for switching to and away from, or cycling through, the built-in emoji keyboard, for example.

Apple also strongly suggest they provide autocorrection, predictive suggestions, and spell checking, capitalization and punctuation consistent with the built-in keyboard experience, caps lock and ideographic input if appropriate, and dictation support.

These aren't requirements and there aren't APIs to provide support for them "for free", but Apple categorizes their implementation as providing a competitive advantage.

Like other types of extensions, custom keyboards are remote views that get presented to the host app. If a developer wants to provide support for multiple languages, they're encouraged to build a separate keyboard extension for each.

Most importantly, Apple emphasizes trust. Apple emphasizes it over and over again. If a developer doesn't need to use server-side processing, they can keep keyboard functionality local, which enhances trust.

If a developer wants their keyboard to go to the cloud, they need to get explicit permission and offer utility worthy of that permission. For example, auto-complete based on a server-side address book, location mapping, lexicon, prediction, dictation, sync, mobile device management, etc.

Developers need to ensure that people get what they expect, and that if the go to the cloud, data is only ever used for the benefit of the person using it.

Security and privacy

iOS, being a privacy- and security-first operating system, does place some limitations on custom keyboards. First, by default they have to keep everything local to the device. That's to prevent key-logging activity. (Where a malicious app steals what you're typing.) If the keyboard does want to add server-side intelligence (which can improve the system), it has to ask your express permission. Apple will then warn you about the app having access to your credit card or street address information, but let you go ahead if you choose to.

What's more, whenever you move to a secure password field, third party keyboards are temporarily disabled and the standard iOS 8 keyboard is presented instead. This is not only to prevent key-loggers, but to prevent anyone at all from having any access to your passwords whatsoever.

Apple will no doubt also provide appropriate toggles in the Settings app should we wish to change our minds later.

Bottom line

Lack of custom keyboard support has been cited by some as a reason to stay away from iOS. Now that reason is gone. Although there are still limitations, both for security and privacy, and for technical reasons, pretty much any existing third-party keyboard can now be brought to iOS, and new and previously unimagined ones can be created. (Please, I beg you, don't waste this power on Hello Kitty!).

We'll have to wait for fall to see how well they work, but it should amount to the difference between fantastic and phenomenal.