Apple has just announced iOS 8. The new version appears to be more extensible than previous versions, and one of the new possiblities is to allow developers to develop custom keyboards, different than the system's default.

Android has had this feature for quite some time. On Android, those keyboards are known as a possible security threat, most notably by acting as a keylogger.

Does iOS 8 prevent such malicious behaviour from happening? If so, what security mechanisms are in place?

  • The actual keylogger scenario is impossible to prevent -- that's the whole point of building a trusted path between the user and OS for input handling. See discussions on Linux Wayland security to understand why this matters. This being said iOS can leverage on specific characteristics of its UI to limit the risks associated with custom keyboard apps. May 10, 2015 at 14:23

4 Answers 4


There is also a safety feature built into the system itself, that prevents third-party keyboards to type into password fields - when you touch a password field the system will go back to the default keyboard temporarily.

By the way, I wouldn't trust Apple to verify that apps aren't malicious. A lot of apps use libraries provided by analytic providers, and while analytics by themselves are spyware, some of them are careless enough to transmit sensitive data (location, name, email) over plain HTTP and yet be accepted just fine in the App Store.


It's an old issue, but there are still some valid points as of 2022 ;)

Apple, by default, does not allow third-party keyboards to initiate network connections or access parent application's shared group container [1] - all that is protected by sandbox. Access to general pasteboard is also monitored - in iOS 14 user is informed every time an application tries to access general pasteboard, and now, in iOS 16 user must explicitly allow application to access general pasteboard. As for NamedPasteboards, keyboard cannot access it as well. In other words, iOS prevents basically all ways that keyboard could use to extract data.

However, when user explicitly grants OpenAccess [1] permissions to the keyboard (by clicking "Allow" in "Allow full access to (...) keyboard") TCC creates exceptions for networking, shared group container and named pasteboards - so now a malicious third party keyboard might be able to threaten user's privacy and security [2].

The main reason why most people might want to grant OpenAccess permission to third-party keyboard at all, is that it is basically the first thing any custom keyboard extensions will ask - without it there are no custom skins, no prediction, no nothing - which makes a custom keyboard "unattractive" and basically the same as default system keyboard.

  1. https://developer.apple.com/documentation/uikit/keyboards_and_input/creating_a_custom_keyboard/configuring_open_access_for_a_custom_keyboard
  2. https://www.securing.pl/en/third-party-iphone-keyboards-vs-your-ios-application-security/

Yes, these apps could record what you're typing, or generate arbitrary input events in your stead. There is hardly a thing you can do to prevent input-providing processes from abusing their privileges.

This being said, there are some structural factors about how input is handled on mobile UIs that limit the risks of custom keyboards (as opposed to desktops):

  • Keyboard input is only used for in-app input, and not for interacting with the system's UI, switching between apps or launching apps: this makes some attacks impossible such as opening a terminal/app, typing in custom stuff and closing the app behind
  • Keyboard input apps probably don't require an internet connection or statefulness beyond an API imposed by the OS, making it harder for them to act maliciously. There could still be apps that legitimately use an Internet connection (e.g. sync'ing your custom words across devices) or IPC (reading your emails to predict words you use often). As such, the best way to handle custom input providers is to give them a specific permission to handle input rather than run them unsandboxed. That is what iOS does apparently.
  • According to Andre (I didn't check myself :-) ), password input fields are always managed by your native keyboard. Whether that's always a good thing is up for debate -- for instance, mobile users choose notoriously weaker passwords in order to reduce the number of mode changes they need to perform when typing a password, and keyboards with better or more customisable handling of special characters could be used to type stronger passwords on mobile UIs with little extra cost.

I believe the answer is quite simple unlike android, apple does not have multiple app stores and the official app store has relatively strict policies regarding app verification

in other words, even though iOS 8 allows custom keyboards, they still need to be verified before they are put up on the app store. however this is not the case for unofficial app stores and jail-broken device are (as always) at a risk

app/plugin verification aside, in a relatively closed operating system like iOS, it is not so difficult to deny apps/plugins internet access, therefore rendering a keylogger mainly useless.

  • That seems really unlikely. Jun 11, 2014 at 10:55
  • a similar mechanism is already being used in the app store so I don't understand why will it be unlikely? Jun 13, 2014 at 2:33
  • Sorry, I mean it seems really unlikely that the only steps they take are app store review. If that were enough, Apple wouldn't have waited this long. Much more likely is that the new keyboards leverage the new app extensions infrastructure. Jun 13, 2014 at 11:38
  • Aha! so that's what you meant, I totally agree! I wasn't specifically talking about app reviews but more so about the general concept in which apple does not simply allow developers to release apps/extensions whenever and however they want :) Jun 13, 2014 at 16:16
  • At the current time we cannot be certain of the actual technical mechanisms in place, but we can speculate based on the company's history and general policies. Jun 13, 2014 at 16:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .