Does a phone call interrupt transcription on iPhone?

It is a fair thing to wonder. A call arriving mid-recording is one of the most familiar ways an iPhone recording gets cut short, so it is reasonable to assume the same call would do something similar to a transcript running at the same time — pause it, kill it, corrupt it. The two situations look alike from the outside: a call rings, something the phone was doing gets interrupted. Underneath, they are not asking the phone for the same thing at all.

Why a call interrupts a recording in the first place

iOS treats the microphone as a single resource that only one thing can hold at a time, arbitrated by the system rather than by whichever app got there first. When a call arrives, the system takes the microphone away from whatever was using it and tells that app an interruption has begun. A recording in progress is the clearest example of something that needs exactly what a call needs, so it is the thing that visibly stops. This is not a bug or a failure on the app’s part — it is the mechanism working as designed, prioritising the call over anything else asking for live audio.

What transcription actually asks the phone for

Transcribing only starts once a recording is already a complete, closed file sitting on disk — you stop recording, the app finalises the audio, and only after that can you ask for a transcript of it. Turning that file into text hands the already-saved audio to Apple’s speech recognition, on-device first, with a retry against Apple’s server only if that first pass comes back empty or errors. Either way, it is audio in, text out, once, against a file that was done before the request began. At no point does it ask the system for the microphone, because there is no live sound for it to listen to.

Why that means a call has nothing to take

The reason a call can interrupt a recording is specific to what a recording needs: exclusive control of live audio input, the one thing iOS only ever hands to a single app at a time. Transcription was never a contender for that resource. It has no open microphone stream for the system to reassign to the call, and nothing for the call to reclaim. Whether the call is answered, declined, or just rings and stops, none of that changes anything about a transcript that is mid-request, because the transcript was never plugged into the resource a call actually fights over.

The one place a call can still matter, and it is not the call itself

There is a genuine edge case, but it is not about the call — it is about what you were doing with the phone at the moment it arrived. If a transcript is started and the phone is then locked or set aside while it is still working, and a call happens to land during that same stretch, the relevant fact is that the app is sitting in the background, not that a call rang. An audio background allowance, the kind that lets a recording keep running with the screen locked, is built for exactly that — keeping a recording’s session alive. It is a narrower thing than open-ended background processing, and a transcript request is closer to the latter. In ordinary use this rarely comes up at all: a call arriving while the app is open on screen shows as a compact banner rather than pulling the app away, so a transcript in progress keeps running with the app still in view. The case actually worth being aware of is narrower and more specific — leaving a long transcript running and then locking the phone before it finishes, not a call by itself.

What actually happens if a transcript does get cut off

The same as any other interrupted transcription attempt: no partial or garbled text, because the request either finishes and hands back a result or it does not run to completion at all. There is no half-transcript sitting in the app to clean up. The source recording is untouched either way, since it was already saved before the request started, and transcribing it again costs nothing beyond the wait — it is a request you can make against a finished recording as many times as you want, not a one-time opportunity tied to a specific moment.

How this differs from what a call does to a recording

A recording that gets interrupted by a call ends up with a real gap in it, matching however long the call lasted, because the microphone was genuinely unavailable for that stretch and there was nothing to capture during it. A transcript has no equivalent gap to show for a call arriving, because there was never a live stream for the call to take over in the first place — at worst, a request has to be made again from the start, against audio that never changed.

How Voice Studio handles this

Voice Studio watches for the system interruption that a call triggers, and uses it to pause an active recording and resume it into the same file once the call ends — that mechanism exists specifically because a recording needs the microphone. Transcription is a separate, one-shot request against an already-saved .m4a: on-device first, with a retry against Apple’s server only if that pass comes back empty or errors, and neither path ever asks for the microphone. A call arriving while a transcript is running does not pause it, cancel it, or restart it, because the two operations were never competing for the same thing.

Common questions

Will answering a call cancel a transcript that is already running?

No. A call takes over the microphone, and transcribing an already-recorded file never asks for the microphone, so there is nothing for the call to take away from it.

Does this apply to both the on-device pass and the fallback to Apple’s server?

Yes. Neither one holds a live microphone stream open — both work from the same already-saved audio file, whether the recognition itself runs locally or on Apple’s server.

What if I lock my phone right as a call comes in while a transcript is still working?

The call itself still is not the risk. Locking the screen puts the app in the background, and that is a separate question from the microphone contest a call wins against a live recording — worth keeping the app open and the phone unlocked for a transcript you want to finish without a second attempt.

Is this the same mechanism as a call interrupting a recording in progress?

No, the opposite of it. A recording is paused because a call takes the one resource it needs, the microphone. A transcript has no microphone to lose, so the mechanism that interrupts recordings simply has nothing to act on here.