What happens if your connection drops during transcription on iPhone?

This question usually comes from somewhere specific: a transcript was running, a lift arrived, a tunnel started, the phone moved from Wi-Fi to cellular on the way out the door, and the result afterward was either nothing or an obvious mess. It is worth separating what actually happened from what it felt like happened, because the two failure paths on iPhone are not the same thing and do not carry the same consequences.

The two attempts do not have the same relationship to your connection

iOS always tries on-device speech recognition first. That pass runs entirely against a language model already stored on the phone — it has no network step to interrupt, so a Wi-Fi drop or a dead cellular signal during that part changes nothing about the outcome. If the on-device pass alone is what produced your transcript, a connection dropping at any point during it was never a factor.

The part that actually depends on a connection is the retry: if the on-device pass comes back empty or throws an error, the usual next step is a second attempt with on-device recognition turned off, which sends the audio to Apple’s speech service and waits for text to come back. That is the one moment in the whole process where losing your connection can actually do something to the result.

What a dropped connection does to that request

The server fallback is not a stream that fills in words as it goes and could plausibly leave you with the first half of a sentence. It is sent as one request and answered with one response — audio in, text out, or nothing at all. There is no partial state in between where the phone has received three-quarters of a transcript. If the connection cuts out while that request is in flight, the request simply fails to complete, and what you are left with is the same as any other failed attempt: an empty or missing transcript, not a garbled or truncated one.

That also means there is no cleanup to do on your end. A failed request does not leave a corrupted file, a stuck process, or a half-written transcript sitting in the app. It leaves exactly what a failure that never involved the network at all would leave — nothing changed, one attempt used up, try again when the conditions are different.

Does a dropped connection mean audio still went out

This is the honest, slightly unsatisfying part of the answer. A request that fails partway through is not the same as a request that never started — some amount of audio can genuinely have left the phone before the connection cut, even though no transcript ever came back for it. There is no reliable way for an app sitting on top of the system’s speech framework to tell you how far a doomed request got before it died. What you can say with confidence is narrower but still useful: a failed request produces no result, so nothing was gained by whatever partial data made it out, and the source recording on your phone is never touched by any of this either way. If a guarantee that literally nothing leaves the phone is what you actually need for a particular file, the reliable way to get it is not watching for a lucky drop — it is transcribing in Airplane Mode, where the fallback request has no route out to begin with and the on-device pass is the only one that can possibly run.

How this looks different from a transcript that is blank for other reasons

A blank or missing transcript caused by a connection drop looks identical, from the outside, to one caused by quiet audio, the wrong language selected, or a missing on-device model — in every case you end up looking at an empty result with no error message spelling out why. The way to tell them apart is to notice your own conditions rather than the transcript: if you know the connection was unstable at the time, that is the more likely explanation, and the fix is different too. A language mismatch needs the setting corrected. Quiet audio needs a closer microphone next time. A dropped connection needs nothing changed at all — just a stable connection and another attempt at the exact same file.

What to actually do about it

• Wait until you have a connection you trust, then transcribe the same recording again. Nothing about the audio file has changed, so there is no reason a second attempt behaves any differently once the network is stable.
• If you are moving between Wi-Fi and cellular a lot — walking out of a building, a commute, a drive with patchy signal — that is worth recognizing as the likely cause before you assume anything is wrong with the recording.
• If a language does have its on-device model installed on your phone, a connection drop during the first attempt is irrelevant, since that attempt never needed the network. A drop only matters when the on-device pass has already failed and the retry is the one in flight.
• For anything you cannot afford to lose the wording of, transcribe it once you are somewhere with a connection you are confident in, rather than while walking through the one dead spot on your usual route.

How Voice Studio handles this

Voice Studio follows the same two-step process: on-device recognition first, and only a retry against Apple’s server if that first pass comes back empty or errors. If your connection drops while that retry is in flight, the transcription attempt fails and the transcript comes back empty rather than partial or corrupted — the recording itself is completely unaffected, since transcribing is a separate step you can run again at any time. There is nothing to undo and no state to fix; running transcription again once you have a steadier connection is the entire remedy.

Common questions

Can a dropped connection corrupt or shorten my recording?

No. The audio file is finished and saved before you ever tap transcribe. A failed network request during transcription has no way to reach back and change a recording that already exists.

Do I get a partial transcript if the connection drops partway through?

No. The server fallback is answered as one complete response or not at all — there is no partial transcript state. A dropped connection produces an empty or missing result, the same as any other failed attempt.

How can I tell if a blank transcript was caused by a connection drop or something else?

The transcript itself will not say. Your own memory of the conditions is the better signal — an unstable connection at the time points to a network failure, while a language mismatch or very quiet audio points elsewhere.

Is there a way to guarantee nothing left my phone even if the connection was flaky?

Yes: transcribe in Airplane Mode. With no network available at all, the fallback request has nowhere to go, so only the on-device pass can run — you either get a transcript produced entirely on the phone, or nothing, with no ambiguous middle case.