With the arrival of iOS 8, developers will be able to offer custom keyboards. If Android is anything to go by, these third-party keyboards could become as lucrative as best-selling apps. But developing a keyboard for iOS is a lot different than developing an app, so we talked to four of the biggest keyboard makers to get their advice on what you need to know.
“The keyboard is arguably the most utilized UI component of a smartphone,” says Ioannis Verdelis, founder and COO of Fleksy, the third-party Android keyboard known for its powerful prediction and auto-correction technology. “It’s really hard to think of another app, or part of the OS, that sees this type of engagement.”
Verdelis tells me that the average Fleksy user sees the keyboard 180 times a day, and the average time a user spends using the keyboard on a smartphone is one hour and 30 minutes.
With that kind of engagement, and considering the iOS keyboard has stayed mostly the same for the last seven years, Verdelis says it’s important to onboard your new users slowly–and to do so in innovative ways.
“Since typing is such a fundamental interaction, we try to strike the perfect balance between bringing something new to the table, while making sure we don’t alienate new users,” he says. “At its core idea, Fleksy has zero learning curve–we use the standard QWERTY layout; the standard way to type, tap typing. [But] we also offer a complementary gesture system which is very popular with users who want to benefit from even faster, more accurate typing,” he says.
To gently guide new users into the more advanced gesture features of Fleksy, the company created a rewards system that makes the onboarding process fun.
“Most users actually discover these using our innovative ‘badges’ system. Basically, we reward users who adopt our advanced features by unlocking badges, free themes, and other premium features. This way, we avoid having to put new users through a tedious onboarding experience–something nobody should need for a keyboard,” he says.
Draven Zhou, senior lead product manager at TouchPal, another Android keyboard set to make its way to iOS 8, agrees that gradually onboarding new users to the more advanced features of third-party keyboards is the way to go. But instead of gamifying the more advanced features with badges, Zhou and his team wanted to display more traditional instructions–yet ones which wouldn’t bore the user or make them feel there was too much to learn up front.
“It’s not a traditional step-by-step tutorial,” Zhou says of TouchPal, which claims to need 90% fewer keystrokes than normal software keyboards. “We hope users can ‘discover’ these interesting features when they want it. For example, users can swipe left on the backspace key to delete the whole word before the cursor. We will not tell the user about this feature in advance. Only when a user taps backspace repeatedly will a hint come up to show the user how this feature works.”
All the custom keyboard developers I spoke with are porting their keyboards from Android–an OS that has been open to third-party keyboards for years now. But while all the developers raved about Apple’s implementation of custom keyboards, they all cautioned that it’s important to understand that Apple handles custom keyboards differently than Android does–and Apple places more limitations on keyboard developers than Android.
“Android is easier–at least at the moment,” says Naveen Durga, lead product manager at KeyPoint Technologies, maker of the Adaptxt keyboard. “Android has supported third-party keyboards ever since its inception, and this means it is quite mature and robust in this respect. However, this is the first time Apple has opened up to third-party keyboards, and we strongly believe that they will gradually scale up their support for developers in this area.”
Durga says the biggest challenge the company faced in bringing Adaptxt to iOS 8 was in accommodating their keyboard solution within the confines of the iOS app extension framework.
“We have developed keyboards for many other platforms and in almost all of them, the keyboard was perceived as a service component,” Durga says. “This means the keyboard application’s life cycle starts when the user selects our keyboard as the primary one and ends when the user switches to another keyboard. On iOS the keyboard’s life cycle is determined by the host application in which the keyboard is used. This was a major challenge as we had to optimize our prediction engine and its life cycle according to the life cycle of the keyboard and–by doing this–we also had to make sure that there was no impact on performance.”
Developers must also keep a baseline level of keyboard consistency, meaning a keyboard must autocorrect, auto-capitalize, quick dot (double-tapping the spacebar to enter a period), and react to the type of field a user is typing into (a keypad for number fields, for example).
And then there are the security restrictions. Unlike on Android, third-party iOS keyboards are unable to directly exchange information with the app in which the keyboard appears. In other words, an app won’t know which keyboard the user is typing with. Another security feature is that Apple will not allow any third-party keyboard to work with password or credit card fields. Instead, iOS’s default keyboard will appear.
But all the developers I spoke with say Apple’s strict custom keyboard guidelines are reasonable.
“The reason [for the security features] is easy to understand,’ says TouchPal’s Zhou. “Apple treats users’ privacy very seriously. So they would rather offer fewer APIs and methods to developers than offering everything developers want. Because keyboard apps are so close to users’ privacy information, it would be very dangerous if there’s no critical policy to restrict developers from what they should do and what they shouldn’t.”
In 2008 when Apple opened iOS to third-party apps there was a mad rush by many developers to quickly throw together an app hoping it would catch on. The problem with those early apps, however, were many of them offered nothing new that the apps that came before them already didn’t offer. The result was these “me too” apps mostly languished unnoticed, tried for only a few seconds before being deleted from a user’s iPhone.
The same goes for custom keyboards on iOS.
“Having grown Fleksy on Android from zero to one of the top players in just six months, my advice to developers is to look hard at their idea/product and be sure that they are offering something new,” Verdelis says.
“There are currently so many keyboards that offer next word predictions; so many that offer some form of gesture typing; so many that offer some kind of emojis. Apple’s own keyboard–and Android’s too–already offer many of these features, which is why many of the third-party products have not gained huge traction.”
If Apple only made smartphones developers would only have to worry about one screen size when designing their keyboards for iOS 8. But to date Apple has sold over 225 million iPads–whose users are clamoring for custom keyboards as well. And while Apple has made it relatively easy to code one universal keyboard for both devices, Fleksy’s Verdelis says developers need to keep one very important thing in mind when developing universal keyboards.
“People type differently on a tablet than a phone,” he says. “On a tablet you have to deal with the fact people type using multiple fingers, or sometimes they hold the tablet with one hand and type with the other. These are subtle differences, but they make a world of difference in the typing experience. It’s not just blowing up the keyboard to be bigger and you are done.”
Developers should also be aware that one of the most popular features of the iPad’s keyboard–the ability to split it into two parts for easy thumb typing–isn’t an API that has been made available to custom keyboard developers. All third-party keyboards must remain whole for now.
Finally, remember that your custom keyboard will be targeting a market of users who aren’t accustomed to having keyboard options at all. If a user isn’t used to having options–or hasn’t played with other third-party keyboards before–it could be hard for them to give accurate feedback because they might not actually know what it is they are looking for in a keyboard–or know how to explain with enough proficiency how they found themselves using it.
That’s why developers might be served best by taking some more creative measures in its user beta tests.
As VP of global communications at SwiftKey‘s Ruth Barnett reveals, “We hold face-to-face, recorded user tests so we can watch users explore our product and check what’s clear and what isn’t. If in doubt, test, test, test.”