Lightweight applications based on Whisper — an automatic speech recognition system developed by OpenAI — have become increasingly available. Comparable solutions are emerging as well. Some operate entirely offline, without any data upload. From a confidentiality perspective, this makes them particularly attractive.
These tools form a diverse product category, ranging from simple speech-to-text recording to prompt-based formatting and summarisation. What they share is a narrow functional focus: dictation and speech recognition. This makes them especially suitable as lean solutions for professional use.
A potential use case for Article 6(7) DMA?
Apps of this kind are also available for macOS and iOS and can use the smartphone microphone. On iOS, I currently use a local, privacy-preserving solution for note-taking, which works reliably. Alternatively, voice messages (e.g. from messaging apps) can be exported and transcribed externally, as built-in transcription functions are often insufficient.
However, this creates a functional discontinuity: it is not possible to access these solutions directly via the system-level microphone button for dictation.
There is also a functional asymmetry between macOS and iOS. On macOS, some solutions allow system-wide access via the Fn or Globe key, enabling third-party dictation tools. On iOS, by contrast, access to the microphone for third-party keyboards is currently restricted by Apple.
Is this practice compatible with the DMA?
At a preliminary level, it is not immediately apparent why one operating system permits such access while another does not. Apple has been designated as a gatekeeper for iOS and iPadOS and is therefore subject to the obligations set out in Articles 5, 6 and 7 DMA.
The key question is whether Apple may lawfully refuse access to the microphone for alternative speech input providers.
This turns on the interoperability obligations under Article 6(7) DMA. That provision requires gatekeepers to ensure interoperability for hardware and software functionalities that are also available to their own services. Article 6(7), second subparagraph, goes further by focusing on functionalities as such, regardless of how they are technically implemented.
This suggests that access must, in principle, be granted.
When does interoperability apply?
Article 6(7) DMA serves two functions:
- It facilitates third-party access to gatekeeper systems, which may constitute essential infrastructure in functional terms.
- It embeds a principle of non-discriminatory treatment between the gatekeeper and external providers.
Where a gatekeeper opens its operating system to its own services, it must ensure interoperability so that competing providers can offer functionally equivalent services. The competition between third-party dictation apps and Apple’s native dictation function is a paradigmatic example.
The scope of the obligation covers hardware and software functionalities accessed via the operating system. System-wide dictation is precisely such a function: it is invoked at the OS level, not within a standalone application.
The obligation applies where the functionality is available to the gatekeeper’s own services. This condition is fulfilled for system-wide speech input and subsequent text insertion at any location within the OS.
Interoperability under Article 6(7) DMA must be provided free of charge. No fees may be imposed for access to the relevant interface. In addition, Article 13 DMA applies, including:
- the effectiveness principle (full and effective compliance),
- the anti-circumvention rule, including behavioural steering and interface design,
- and the prohibition of hindrance.
Integrity as a possible justification?
Article 6(7), second subparagraph, allows the gatekeeper to raise objections based on the protection of system integrity. Such objections must satisfy three cumulative conditions:
- A demonstrable risk to the integrity of the operating system caused by third-party applications,
- Measures that are necessary and proportionate to address that risk,
- A sufficiently reasoned justification.
Even here, the anti-circumvention principle applies.
Given that comparable dictation functionality is already feasible on macOS, such integrity-based objections appear less convincing in the case of iOS.
That said, targeted technical safeguards to protect users may be permissible — for example, explicit consent mechanisms when enabling alternative speech input. However, such measures must comply with Article 6(3) DMA and must not unduly restrict users’ ability to modify default settings.
Implications
The relevance of this issue does not lie in any single application, but in the architecture of access.
As long as Apple reserves system-level dictation at the decisive point of use, third-party providers remain at a structural disadvantage, even if their applications are otherwise permitted.
This is not merely a question of product design. It may serve as a test case for the scope of Article 6(7) DMA.
That the market has so far addressed this only sporadically likely reflects the early stage of these technologies, rather than the limited significance of the issue. As local and AI-based speech input becomes more widespread, regulatory pressure to open such interfaces will increase.
Anyone seeking to understand the DMA not only in abstract terms, but in its concrete impact on operating system functionalities, should follow these developments closely.
