Potentially Unfair Limitation for Third-Party Keyboard Developers

When developing a custom keyboard on iOS, even after enabling Full Access (RequestsOpenAccess = true), it is still not possible to record audio — the recording simply does not start.

This is despite the fact that:

  • the user is explicitly warned
  • the user provides informed consent by enabling Full Access

According to Apple’s documentation: https://developer.apple.com/documentation/uikit/configuring-open-access-for-a-custom-keyboard

“However, with RequestsOpenAccess set to true, the keyboard has all the capabilities in the preceding list.”

At the same time, the preceding list includes:

“No access to microphone and speaker”

This creates ambiguity. The wording suggests that enabling Full Access should lift prior restrictions, yet in practice, microphone access remains unavailable to third-party keyboards.

Why this is concerning

With Full Access enabled, a keyboard already has:

  • network access
  • the ability to transmit user input

From a privacy standpoint, this is already highly sensitive. Preventing microphone access while allowing these capabilities appears inconsistent.

Meanwhile, Apple’s own system keyboard supports voice dictation, which creates a functional gap between first-party and third-party keyboards.

Competition perspective

This raises a broader question about equal access to platform capabilities.

Restricting third-party keyboards from using the microphone — while first-party solutions can — may be seen as:

  • unequal treatment of developers
  • a limitation of competition in input methods

Such differences are increasingly scrutinized under EU regulations like the Digital Markets Act and Article 102 TFEU, which emphasize fair access to platform features and prohibit self-preferencing by dominant platforms.

Request for clarification

  • Is microphone access intentionally restricted for all third-party keyboards, even with Full Access enabled?
  • If so, what is the technical or policy justification?
  • Are there plans to provide a secure and user-consented way to enable audio input for custom keyboards?

Clarification on this would help developers better understand platform limitations and design decisions.

Potentially Unfair Limitation for Third-Party Keyboard Developers
 
 
Q