Why your recording app loses your footage.
It's one of the most common gut-punches in mobile video: you film something perfect, the app drops, and the take is just gone — not in Recently Deleted, not anywhere. It's not bad luck. It's a design choice, and you can test for it in thirty seconds.
The bet most recording apps make
Here's what's happening under the hood. While you record, a lot of apps hold the video in a buffer and only write a finished, playable file at the moment you tap stop. It's the simplest way to build a recorder, and on a good day you never notice. The catch is that "tap stop" is doing a lot of quiet work: it's the trigger that finalizes the file. Until it fires, what's on disk (if anything) usually isn't a complete video.
Why an interrupted file won't play
A video file isn't just a stream of frames — it also needs an index (in MP4 and MOV files, the "moov atom") that tells a player where every frame lives and how to sync audio to video. By default that index is written last, when recording ends. If the app is killed before then — a crash, an incoming call seizing the microphone, the battery cutting out, Low Power Mode stepping in — you're left with raw data and no index. To a player, that's not a damaged video; it's not a video at all. That's why there's nothing in Recently Deleted to recover: a finished file was never created.
The alternative: save as you go
The fix is well understood, just more work to build. Instead of buffering until stop, the app writes the recording to disk continuously, in short segments, each one finalized as it's captured. The footage exists on the device the instant it's filmed. If the session is interrupted, the segments are still there, and the app can stitch them back into one seamless file on the next launch. It's the same general approach robust capture pipelines use to make recording survive the messy realities of a phone — calls, notifications, low memory, dying batteries.
Want to know which kind of app you're trusting? Start a short recording, swipe up to the app switcher, and force-quit the app mid-recording. Reopen it. If the footage is simply gone, it was living in memory. If it offers to recover the take — or you can find a partial file — it was writing to disk as it went. Do this before you record something you can't redo.
What to look for
- A recovery prompt on relaunch after an interrupted recording.
- Language like "writes to disk as you record," "chunked," or "automatic recovery" — not just "saves when you stop."
- Behavior that survives the force-quit test above.
This is the problem we built NexCam around: every second is written to disk as you film, and recovery is the first screen you see if a take is ever interrupted. We think it should be the default for any app that records something you care about. Here's how our implementation works, and if you've already lost something, here's what to try.
Frequently asked
Why do recording apps lose video when they crash?
Many buffer the recording and only finalize the file (writing the index that makes it playable) when you tap stop. Interrupted before that, the data on disk has no index and won't play, so there's nothing to recover.
Can you recover a video lost mid-recording?
Only if the app wrote footage to disk as it recorded. Memory-only recordings are usually gone. Segment-based apps can stitch the pieces on relaunch.
How do I test my app?
Record a few seconds, force-quit the app from the app switcher, and reopen it. Gone = memory-buffered. Offered for recovery = saved to disk continuously.