Why a voice keyboard cannot record audio on iOS

A voice keyboard cannot record audio on iOS because Apple's keyboard extensions run in a separate, sandboxed process that never gets microphone access. Parlo's keyboard hands the mic tap to its Full Access app instead: the app records and transcribes, then the keyboard inserts the finished text once you swipe back to the field you left.

By Eric Friedman. Last updated 2026-09-08.

Why can't a keyboard extension record audio?

iOS treats a custom keyboard as an app extension: a small program that runs inside whatever app's text field you are typing into. Apple's rules for extensions keep them away from the microphone, even when the extension asks for it. The restriction protects you. A keyboard sees everything you type, so Apple does not also let it listen. Parlo's keyboard, like every other keyboard on iOS, cannot record audio. The keyboard extension cannot access the microphone, so recording and transcription happen in the Parlo app instead.

This is not a Parlo limitation to work around later. It is a platform rule that applies to any voice dictation keyboard on iOS, Parlo included.

How does Parlo work around the limit?

Parlo splits the job across two programs that share one App Group, a private container both programs can read. The keyboard is the part you type in day to day. The app is the part with microphone access. When you tap the mic key, the keyboard hands off to the app:

1. You tap the mic key in the Parlo keyboard.
2. The Parlo app opens and starts recording.
3. You speak, then stop. The app transcribes and cleans up the text on your device.
4. You swipe back to the app you were using.
5. The keyboard inserts the finished text where your cursor was.

The swipe back in step 4 is manual. iOS requires it. Nothing brings you back to the field automatically, and no keyboard extension can do that on your behalf.

What does Full Access actually grant?

The keyboard asks for Full Access during setup, with the setup screen explaining that Parlo needs it to hand text back to the keyboard. Full Access lets a keyboard extension share data with its companion app through the shared App Group. Parlo uses that container to pass your dictated text from the app back to the keyboard. Apple's own documentation for custom keyboards describes, in general terms, what Full Access permits an extension to do, including network access it would not otherwise have. Full Access does not grant microphone access. That stays off limits for every keyboard extension on iOS, with or without Full Access.

Does the keyboard ever touch iCloud or sync?

No. The keyboard never links the sync stack and never talks to CloudKit. It reads the App Group and nothing else. Recording, transcription, and any iCloud sync of your history happen in the Parlo app, a separate program from the keyboard even though they feel like one experience while you dictate.

Could the keyboard just insert text automatically once it's ready?

It inserts only when it is on screen in the field you left, and only once. Results expire rather than sitting around waiting for a chance to land somewhere else. That rule exists so a finished dictation cannot land in the wrong app or the wrong field days later, and so nothing gets inserted twice by accident.

What breaks in practice if you deny Full Access?

Typing still works normally. Without Full Access, the app cannot hand your dictated text back to the keyboard, so dictation itself does not work. You can turn Full Access on later in Settings without reinstalling anything, and dictation starts working from that point on.

Is this an Apple rule or a Parlo choice?

It is an Apple rule, and it applies to every third-party keyboard, not only Parlo's. Any keyboard extension that wants to offer dictation needs a companion app with microphone access, since the extension itself can never get one. The manual swipe back is also an Apple requirement, not a design choice any keyboard maker gets to skip.

What can the keyboard do on its own, without opening the app?

The keyboard has its own history panel: recent notes, tap to insert, long-press to copy, swipe to delete. None of that needs the microphone, so it works entirely inside the keyboard extension. It has no search. Starting a new dictation is the one action that always needs the app, because recording can only happen there.

Why keep the app and the keyboard as two separate programs at all?

Keeping them separate is what makes the microphone restriction survivable rather than a dead end. If Parlo tried to build one program that was both a keyboard and a recorder, iOS would still refuse it microphone access as a keyboard extension, and dictation simply would not work. Splitting the work lets the app do what only an app can do, recording and transcribing, while the keyboard stays focused on typing, suggestions, and inserting the result. It also keeps the keyboard small: it does not carry the audio pipeline or the sync stack, so it stays under the memory budget Apple sets for keyboard extensions.

Does this restriction ever get lifted for keyboards with Full Access?

No. Full Access changes what a keyboard extension can share with its companion app and what network access it has. It does not touch the microphone restriction, which is a separate rule that applies to the extension category itself, not to any specific permission you grant afterward. A keyboard with Full Access and a keyboard without it are equally unable to record audio.

If you want to see the handoff in practice rather than read about it, the setup guide walks through installing the keyboard and dictating for the first time.