With the release of iOS8 apple introduce a list of extension. One of those extensions is Custom Keyboard.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.

Providing a Way to Switch to Another Keyboard


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 Quick Type.
  • 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 auto correction, 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.

How It Works

In the most basic form we have an application that contains a keyboard extension. A UIInputViewController that controls the keyboard and responds to user events.
The Custom Keyboard template contains a subclass of UIInputViewController, which is the primary view controller of your keyboard. Let’s look at the interface to get a feel of how it works.


classUIInputViewController : UIViewController, UITextInputDelegate, NSObjectProtocol {

varinputView: UIInputView!

vartextDocumentProxy: NSObject! { get }


// This will not provide a complete repository of a language’s vocabulary.
// It is solely intended to supplement existing lexicons.
funcrequestSupplementaryLexiconWithCompletion(completionHandler: ((UILexicon!) -> Void)!)


    • inputView is the view used for the keyboard, it is the same as the view property
    • dismissKeyboard method can be called to dismiss the keyboard
    • advanceToNextInputMode is used to change between keyboards
    • textDocumentProxy is the object that you’ll use to interact with the current text input

self.textDocumentProxy.insertText(“Hello World”) // inserts the string “Hello World” at the insertion point.
self.textDocumentProxy.deleteBackward() // Deletes the character to the left of the insertion point.




Please Contact Us For More Information info@softrefine.com