What happens if your iPhone dies while exporting or backing up voice memos?

This sits between two failures worth knowing about already. A phone dying mid-recording can genuinely damage the file, because the app is mid-write on the recording itself when the power cuts out. A phone dying mid-transcription cannot touch anything, because transcription only reads a file that was already finished and closed beforehand. Exporting and backing up are their own third case, and neither of those two answers quite fits.

What exporting actually does to your data

Exporting a transcript, sharing a recording’s audio, or building a full backup all start the same way: by reading something that is already saved and complete. A single recording’s .m4a was finalised the moment you stopped it. Its transcript, if you have run one, was already written to the app’s own storage before you ever opened the export screen. None of that gets rewritten to produce an export — it gets read, and a new file gets built from what was read.

That is the part a power failure cannot reach. Whatever the phone was doing when it died, the recording and the transcript it already had were not open for writing at that moment, because export does not write back into them. The source is exactly as safe here as it is when the phone dies while transcribing, and for the same underlying reason.

What a power failure actually can reach

The one file the export is producing. A TXT or JSON transcript export, a full backup JSON — each of those is a new file being assembled and written, and a hard power-off in the middle of that write behaves the way an interrupted file write behaves on any device: the file can come out shorter than intended, empty, or simply never get finished being handed to wherever you were sending it. That is a real thing that can happen, and it is worth naming plainly rather than promising it never does.

What it is not is a threat to your library. Losing that one output file costs you exactly one export attempt — the same recording and the same transcript are still sitting in the app afterward, ready to be exported again, because nothing about producing that file ever depended on keeping them intact. They already were.

Why a full backup is the riskier of the two

A single recording’s TXT or JSON is small and quick to write — title, date, time, location and one transcript’s worth of text is not much data, so the window in which a power failure could catch it mid-write is brief, and the odds of a dead battery landing in exactly that window are low. A full backup is a different scale: it is one JSON covering every recording’s details and transcript in the library at once, so assembling and writing it takes longer, and a bigger library means a bigger file and a longer window. If a phone is going to die partway through any export, a lengthy full backup on a large library is where that is most likely to actually happen.

Telling whether the file you got is actually whole

A TXT file is the easy case — open it and see where it stops. A transcript that ends mid-sentence, or a file that is suspiciously short for a recording you know was long, is its own evidence that the export did not finish. A JSON file is harder to eyeball, but it tends to fail more loudly rather than more quietly: a JSON file cut off mid-write is usually not valid JSON anymore, so whatever you try to open it with — a text editor, a script, an import into another tool — is more likely to throw an error than to open it looking fine while quietly missing the second half. An export that will not open at all is telling you something useful, not being unhelpfully broken.

What to actually do about it

• Open the file before trusting it, especially after a backup made while the battery was already low. A file that opens cleanly and looks complete almost certainly is.
• If it will not open, or looks cut short, just export or back up again. Nothing about the recordings or transcripts changed, so there is no partial state to work around — it is the same request, run a second time.
• For a large full backup specifically, plug the phone in first rather than starting it on a battery you are already watching. The backup itself does not take long relative to a recording, but there is no reason to run it against a clock you cannot see.
• If a backup matters because you are about to be without the phone for a while — a new device on the way, a repair, a trade-in — do it with a healthy battery and check the file afterward, rather than treating a low-battery backup as good enough because it is better than nothing.

How Voice Studio handles this

Exporting a transcript in Voice Studio writes a TXT or JSON of that one recording; sharing a recording hands over the .m4a itself; and a full backup, in Settings, writes everything in the library — every recording’s details and transcript — into one JSON file. Every one of those reads from data that was already saved before the export started, and none of them rewrites the recording or an existing transcript to produce the new file. There is no account and no CloudKit sync behind any of it, so the copy an export or backup produces is the only copy that exists until you have made it — which is exactly why it is worth opening once after you make it, rather than assuming a file that finished writing quickly must have finished writing completely.

Common questions

Can my iPhone dying during an export damage the recording it was exporting from?

No. Exporting only reads a recording and its transcript, both already finished and saved before the export starts — it never rewrites them. A power failure can only affect the new file being produced, not the source it was read from.

Is a full backup more at risk from a dead battery than exporting a single recording?

Yes, in the sense that it takes longer. A single transcript export is small and quick, so the window for a power failure to catch it mid-write is brief. A full backup assembles every recording in the library into one JSON file, which takes longer and gives a dead battery more time to land in the middle of it.

How can I tell if an exported or backed-up file is actually complete?

Open it. A TXT file that stops mid-sentence is its own evidence. A JSON file cut off mid-write is usually no longer valid JSON, so it tends to fail to open at all rather than open looking fine with content quietly missing.

Do I have to redo anything else if my phone dies mid-backup?

Just the backup itself. The recordings and transcripts it was reading from are untouched, so running the export or backup again starts from the same complete data, not from anything partial.