What happens if your iPhone runs out of storage while importing an audio file?

This one shows up less often than a live recording running out of room, but it catches people harder when it does, because it usually happens in a batch: a backlog of old voice notes, a folder of recordings pulled off a handheld recorder, years of voicemails saved out of another app, all queued up to bring in at once rather than one file trickling in at a time.

Importing is a copy, not a capture

Recording writes new audio to a file as it happens, a few seconds at a time, for as long as you keep talking. Importing is a different kind of operation entirely: the file already exists, complete, somewhere the phone can reach — the Files app, a cloud drive, an AirDrop transfer — and importing it means reading that file and writing a copy of it into the app's own storage. Nothing is being generated on the fly. The full size of what is about to be written is already known before the copy starts, because the source file already has that size.

That distinction is what makes the storage-full case here genuinely different from the recording one. A recording in progress does not know its own eventual length in advance; an import does, from the first instant, because it is reading a file that already ends somewhere.

What actually happens at the moment it fails

The copy stops. iOS reports the write as failed — an error in the share sheet or the import dialog, rather than something that fails silently — and the app is left with either nothing or a partial, incomplete copy that it discards rather than adding to the library as a broken entry. Either way, nothing about the source file changes. Importing only reads from it; it is never opened for writing, so a copy that fails partway through has no way to reach back and damage the original sitting in the Files app, the cloud drive, or wherever it came from.

That is worth being clear about, because it is the opposite of the one genuinely destructive storage failure on this site: a phone dying or running out of room mid-recording can leave the file actually being written in a damaged state, because that file is open and mid-write at the moment things go wrong. An import failing has no equivalent, open, in-progress file of its own being damaged — the only thing "in progress" is a copy, and a copy that does not finish is simply a copy that does not exist yet, not a corrupted one.

Why an imported file is not shrunk by a quality setting the way a new recording is

A new recording made in the app is compressed as it is captured, at whichever of the three quality tiers is set — standard, high or ultra, all mono AAC — and that setting is the real lever over how much space it costs. An imported file skips that step entirely: it already exists in whatever format and size it was created in, and importing does not re-encode it into a smaller one. A voice note that started life as a .wav or .aiff on another device — an old handheld recorder, most commonly, since those formats are still common there — can be considerably larger than an .m4a of the same length ever would be, because it was never compressed the way audio captured natively on the phone already is by the time it reaches disk.

This is the part that catches a big batch import off guard: judging how much room "one recording" needs from what a phone's own recordings usually cost is judging against the wrong number. An hour of an app's own mono AAC and an hour of uncompressed audio from somewhere else are not close in size, and a folder of the second kind can use up far more room than the same duration in native recordings ever would.

The situation this actually shows up in

Almost never a single file. It is migrating away from another recorder app, clearing out an old phone before handing it down, bringing in a batch of recordings from an Android device, or finally dealing with a folder of voicemails or lecture recordings that have been sitting on a computer for years. All of those are "import everything at once" situations by nature, and that is exactly the shape of task where the combined size of a whole folder — rather than any one file in it — is what actually runs into a wall.

Checking before a batch import, not during

• Settings → General → iPhone Storage shows free space directly — worth a glance before a folder of old recordings, not partway through one.
• Check the total size of the folder you are about to import, not just how many files are in it. A dozen short native-style recordings and a dozen long uncompressed ones are very different asks of the phone.
• Import in smaller batches if the total is close to what is free, rather than pointing the whole folder at the app at once and finding out partway through which files made it.

What to do if it happens partway through a batch

Check which files actually made it into the library and which did not, free up space — deleting or offloading a few large videos usually recovers far more room than clearing anything audio-related — and finish the rest afterward. There is no need to re-import anything that already succeeded, and nothing about a failed later file threatens one that already copied cleanly earlier in the same batch.

How Voice Studio handles this

Voice Studio can import an existing audio file straight from the Files app, in any format iOS already plays natively — .m4a, .mp3, .wav and .aiff import directly, and an older format like .amr needs converting to one of those first. An import is a straightforward copy into the app's own on-device storage, with no account, no CloudKit sync and no server of ours standing behind it to fall back on if local space runs out. If storage fills up partway through, the copy simply fails or is left incomplete rather than added to the library, and the source file you were importing from is never touched, since importing only ever reads from it. Once a file is in, it is treated exactly like a native recording — transcription still attempts the on-device path first, the same as anything recorded in the app itself.

Common questions

If an import fails because of storage, is the original file I was importing damaged?

No. Importing only reads the source file to make a copy; it is never opened for writing, so a failed or incomplete copy has no way to affect the file you were importing from.

Does a lower quality setting help free up room for a big import?

No, not for the import itself. The quality setting only affects new recordings made in the app; an imported file keeps whatever size and format it already had, since importing copies it rather than re-encoding it.

Why do old recordings from another device take up more room than expected?

Older handheld recorders and some other apps commonly save uncompressed formats like .wav or .aiff. Those are considerably larger per minute than the compressed .m4a a phone's own microphone produces, so a folder of them can use up far more space than the same duration of native recordings would.

Is it safer to import one file at a time instead of a whole folder?

It removes the guesswork, at least. Importing in smaller batches means a storage problem partway through only affects the files still queued, and you can free up space and finish the rest afterward without wondering which earlier files actually made it in.