Can one voice memo transcript be partly on-device and partly in the cloud?

Most explanations of on-device versus cloud transcription — this site's included — describe it as something that happens to a recording: the on-device pass runs, and either it succeeds or the request falls back to Apple's server. That framing is accurate for a short voice note, transcribed in one pass. It quietly stops being the whole picture the moment a recording runs long enough to be split up before it ever reaches the recognizer.

A long recording is not one request

Speech recognition on iOS is not built to take an hour of audio and hand back an hour of text in a single round trip. Implementations that use Apple's Speech framework work through longer audio in sections, submitting each one as its own recognition request. A three-minute voice note might be one section. A lecture, an interview, or anything that runs long is several, processed one after another.

That detail matters here specifically because the rule that decides on-device versus server does not apply once, to the recording as a whole — it applies separately, to every section. Each one gets its own attempt at recognizing speech locally, and each one is free to end up on a different path from its neighbours.

What sends one section to the server while another stays local

The retry rule is the same one that governs a short recording: on-device recognition is attempted first, and only if that attempt comes back with nothing usable, or throws an error, does the same audio get retried with on-device recognition turned off — which is the path that sends it to Apple's speech service. Apply that section by section and the outcome follows naturally from what is actually in each stretch of audio. A section full of clear, continuous speech usually succeeds locally and the fallback never fires. A section that is mostly silence, distant noise, a burst of static, or speech in a language the on-device model was not built for is exactly the shape of audio that comes back empty — and empty is the one condition that triggers the retry.

None of that requires anything unusual about the recording. It happens inside an ordinary meeting that has a quiet stretch while people find their seats, a lecture with a long pause for questions, or a voice note that opens with some fumbling before anyone starts talking. The parts that are easy for a local model sail through on-device. The parts that are not are the ones that end up asking the server for help — and a single recording routinely contains both.

So the finished transcript can genuinely be mixed

Put those two facts together and the answer to the question in the title is not a hedge — it is what the mechanism actually does. A forty-minute recording can have its first ten minutes handled entirely on-device, a two-minute stretch of ambient noise in the middle fall back to the server, and the rest go local again, all inside one transcript you read as a single continuous piece of text. There is no requirement that a recording go one way or the other. The two paths were never mutually exclusive at the level of a whole file — only at the level of one section.

Why the transcript does not show you where the seam is

This is where it gets genuinely hard to reason about after the fact. A finished transcript reads as one continuous piece of text because the app is doing exactly what you would want it to: stitching the sections back together in order and showing you the words, not the plumbing that produced them. There is no marker, no colour change, no note in an exported TXT or JSON file distinguishing a sentence that came back from an on-device pass from one that came back from a server retry. Both arrive through the same call and get displayed the same way, so by the time you are reading the result, the part of the recording that stayed entirely on your phone and the part that touched Apple's servers look identical.

That also means a spot check does not settle it for the whole file. Testing one part of a long recording in Airplane Mode — or noticing that most of a transcript came back quickly, a rough sign of a local pass — tells you about the section you tested, not about a two-minute stretch of noise twenty minutes later that never got checked.

What this changes about how you should think about it

• Stop treating "did this recording go to the cloud" as a single yes-or-no question once the recording is longer than a couple of minutes. The honest version is "which parts of it," and the honest answer is usually some of each.
• A recording that is continuous, clear speech from one person start to finish is the case least likely to have any section fall back — there is little in it that would come back empty from a local pass.
• A recording with real gaps in it — silence, background noise, a switch to a second language partway through — is the case most likely to have at least one section handed to the server, precisely because those are the stretches a local model struggles with.
• If a specific recording matters enough that you need certainty for its entire length, not just a sample of it, the only method that actually covers the whole file is transcribing the whole thing in Airplane Mode, start to finish, in one pass.

What Airplane Mode actually guarantees here

Turning the network off before transcribing does not make every section succeed — a section that would have needed the server to come back with anything usable still fails, the same as it would offline in a short recording. What it guarantees is narrower and still worth having: with no network route available, no section, anywhere in the file, has anywhere to send its audio. You trade the words that only the server pass would have recovered for certainty that nothing from any part of the recording went out. For a recording where every word matters more than that guarantee, that is a real cost. For one where the guarantee is the point, it is the only method that actually delivers it end to end rather than for a sample.

How Voice Studio fits into this

Voice Studio uses Apple's Speech framework the same way described here: on-device recognition attempted first, with a retry against Apple's server only for whatever comes back empty or throws an error, and long recordings worked through as more than one request rather than one. That means a long transcript in the app can be a genuine mix — some of it produced entirely on the phone, some of it only after a retry that reached Apple's speech service — with nothing in the app's interface or its TXT or JSON export marking which sentence came from which pass, because the app itself is not tracking that distinction either. Voice Studio has no account, no server of its own and no analytics SDK, so Apple's speech service is the only place any audio can ever go; if a particular recording needs a guarantee that covers the whole file rather than a spot check, transcribing it in Airplane Mode is the one way to get that, for the reasons above.

Common questions

Does a long recording get sent to the cloud all at once, or in pieces?

In pieces. Longer audio is worked through in sections, and each section is submitted for recognition on its own, which is also why each one makes its own on-device-or-server decision independently of the others.

If most of my recording transcribed quickly, does that mean none of it reached the server?

Not necessarily. A recording can be overwhelmingly clear speech that transcribes locally in seconds and still contain one short stretch of noise or silence that came back empty and triggered a retry for just that section.

Can I tell afterward which sentences in a transcript came from which path?

No. The finished text looks identical either way, and nothing in the app's interface or in a TXT or JSON export marks which section was produced on-device versus by the server retry.

Does transcribing in Airplane Mode guarantee nothing from a long recording was sent anywhere?

Yes, for the whole file, because there is no network route for any section to use. The trade-off is that sections which would have needed the server simply come back empty instead of coming back with text.