The Good, the Bad, and the Ugly of iOS Third Party Keyboards
Custom third party keyboards have been appealing to iOS users since the first jailbreak was released in 2007. As with all the great features obtained with a jailbreak, though, Apple eventually catches up with its own version. With iOS 8, the company brought third party keyboards to millions of users. At first, only a few third party keyboards were available, but now, three months later, the App Store has a lot of new ways to type. However, I’m not convinced it’s worth switching to custom keyboards because they lack one crucial feature: dictation. That, and the actual keyboard setup process is far too complicated.
Right when iOS 8 was released, I, among many other users I’m sure, downloaded Swype. After using it on Android a few years ago, I thought I would give it a try again. Despite their installation guide, it was unexpectedly difficult setting up the keyboard. Overall it was a few steps, yes, but I didn’t anticipate going deep into Settings and giving the keyboard full access to what I type. But more on that bit later.
Apple could have streamlined this process a lot more. It’s as if they wanted to give users custom keyboards, but keep them hidden away. “You can download them, but we don’t want you to actually use them.” That’s rather ridiculous. There’s no reason users should have to jump through ten loops just to install something. Keyboards should be like any other app: download it, open it, grant it access to everything you type, and begin using it. Of all things, I expected the installation process to take part within the Keyboard’s portion of the iOS Settings. Jumping between apps just doesn’t make sense.
My main reason for not using custom keyboards on my iPhone is not because it takes too long to set up or may not be the best for my privacy (next up), it’s because there’s no dictation.
I love using Siri for dictation. I use it all the time to send emails on the go, write things in Simplenote, and even search for stuff on Amazon. iOS 8’s dictation is the best yet, providing live feedback as you talk. So why, then, would I give it up? Switching between keyboards is not convenient when you’re on the go, and that’s the only way to use iOS’ integrated dictation.
As the Custom Keyboard section in Apple’s App Extension Programming Guide states, “Custom keyboards, like all app extensions in iOS 8.0, have no access to the device microphone, so dictation input is not possible.” As usual, this doesn’t mean dictation will never be available in custom keyboards, but there are a few things that come to mind when considering the privacy implications of such a development.
Autocorrect and prediction information should be exchanged with Apple’s API, much like Touch ID
For one thing, if a keyboard like Flesky did support dictation, what would it use to transcribe your words? There are a few options out there. One of the main ones is NDEV Mobile from Nuance, the developer of Dragon Dictation. It’s free for most basic implementations. You can find it at work in Merriam-Webster’s iOS app, the OnStar RemoteLink app, Dragon Dictation’s own app, and more. If developers were able to access the microphone, they could integrate a service like NDEV into their keyboards to provide dictation.
There’s also another option: Apple could allow access to Siri Dictation through an API that would also protect the user’s speech from being transmitted to a third party server. This is theoretical, of course.
Lastly, I’d like to look at the privacy implications of using third party keyboards. It took Apple years to bring this highly-requested feature to its mobile platform, yet it still manages to punch a hole in the privacy wall. When I tried to use Themeboard, an app with a collection of beautiful custom keyboards, I was greeted with a sad face and “Permission Required” popup. It asked that I allow the keyboard full access to what I’m typing so that it could provide autocorrect and prediction information. There’s simply no way around this. You have to trust that the developer won’t store or sell anything you type.
In the App Extension Programming Guide mentioned above, Apple also states that “An app developer can elect to reject the use of all custom keyboards in their app. For example, the developer of a banking app, or the developer of an app that must conform to the HIPAA privacy rule in the US, might do this.” This does not include Safari, however, and as the user you have no way of making sure the keyboard doesn’t log what you’re typing inside the browser, whether it’s a credit card number or email in Private Browsing mode.
Personally, I don’t like not having dictation when I’m on my bike, in the car, or in a rush. However, the current state of iOS custom keyboards is much more severe than that. Dictation is something I could live without. Lack of privacy is not. I would rather have my information in Apple’s hands than a third party’s, one who may turn out to not be trustworthy.
It shouldn’t be the user’s job to research a developer before downloading their keyboard. Apple should simply put limits on what information is transmitted to the developer’s servers, as doing so would solve both the privacy and ease of use concerns. Autocorrect and prediction information should be exchanged with Apple’s API, similar to how Touch ID‘s third party integration operates. Rather than handling the fingerprint directly, Apple’s onboard chip identifies it and sends a key to the software confirming or denying the authentication request. This is what custom third party keyboards should be like, and this is what I want to see before iOS 9 rolls out next year.