Why we don’t ask for Full Access just to type

Install almost any third-party keyboard on iPhone and the first thing it does is ask for Full Access. Most people tap Allow because the keyboard is useless otherwise, and then never think about it again.

It’s worth thinking about, because it’s a bigger permission than it sounds.

What Full Access actually grants

A custom keyboard on iOS runs in a sandbox. Without Full Access it can draw itself and insert text into the field you’re typing in, and that’s roughly it. It cannot reach the network, the clipboard, the photo library, or shared storage.

Turn Full Access on and that wall comes down. The extension can talk to the network and read the system clipboard. That’s why the toggle exists at all, and it’s why iOS shows a warning when you flip it.

So the honest question for any keyboard is not “is Full Access dangerous”, it’s “why does this keyboard need it in order to type?”

Why most keyboards ask anyway

Usually for reasons that have nothing to do with typing:

• The library lives on a server, so inserting a snippet needs a network call.
• Analytics or crash reporting are wired into the extension.
• The keyboard shares state with the app through a mechanism that needs it.

None of those are sinister on their own. But they mean the permission is load-bearing for basic use, so you can’t decline it and still have a working keyboard.

How Fast Reply is built instead

Your library lives on the device, in storage the app and the keyboard both reach directly. Inserting a reply is a local operation: read the text, put it in the field. No network, no clipboard, no permission.

Which means text insertion works with Full Access off, and that’s the default.

Two features do genuinely need it, and only these two:

1. Sending images from the keyboard. Handing an image to another app goes through a path the sandbox doesn’t allow.
2. The {{clipboard}} placeholder. Reading the system clipboard is exactly the capability the permission gates.

If you never use either, you never need to turn it on. If you do, you turn it on for those, and everything else keeps working the way it did.

What we don’t do with it, either way

Whether the toggle is on or off, Fast Reply does not log or transmit what you type. There’s no keystroke history, and the keyboard has no interest in the field you’re in beyond putting your reply into it.

That’s an easy promise to make when the architecture doesn’t depend on breaking it. A keyboard that needs the network to insert a snippet has to be trusted; one that inserts snippets locally doesn’t have to be.

The part that’s genuinely annoying

Being honest about the tradeoff: because the keyboard doesn’t phone home, the app is the thing that syncs. Your library moves between devices through iCloud from the app, not from the keyboard extension. Practically that means an edit shows up after the app has run, not the instant you make it on another device.

We think that’s the right side of the trade. But it is a trade, and you should know which one you’re getting.

If you’re setting the keyboard up for the first time, the snippet keyboard guide walks through it, and this one covers what to do when iOS drops a custom keyboard after an update.