Does a teleprompter app save your video if it crashes?
Usually not — and you cannot tell from the store listing, the feature list or the reviews. You can find out in about four minutes, on your own phone, with a script you do not care about.
The honest answer for most apps is no — and the reason is not negligence, it is a default. Writing a video file so that it survives being killed costs a little performance and a little engineering, and if nobody asks for it, nobody does it. It does not show up in a feature list, it never appears in a screenshot, and you find out the first time it matters.
So test it. It takes four minutes, it needs no tools, and it is the single most useful thing you can do before trusting an app with an interview, a client shoot or anything you cannot simply film again.
The four-minute test
Do this once per app, on the phone you actually shoot on. Use a script you do not care about and point the camera at a wall.
- Start a recording and let it run for about thirty seconds. Say the time out loud at the start, so you can tell later how much survived.
- Do not press stop. This is the whole point of the test.
- Force-quit the app. Open the app switcher and swipe it away. On iPhone, swipe up from the bottom and hold, then flick the card up. On Android, open recents and swipe the card away.
- Reopen the app. Give it a moment on the first screen — recovery, where it exists, runs at launch.
- Look in the app’s own library, and then in your camera roll.
Then read the result against this:
| What you see | What it means | Trust it with a long take? |
|---|---|---|
| The take is there and plays, a few seconds short | The app writes its file progressively and reconciles the library at launch. This is the behaviour you want, and the missing seconds are the expected cost. | Yes |
| Something is there but reports 0:00 | The file exists but its index was never written. The data is on disk and no player can read it. | No |
| Nothing is there at all | Either the file was discarded, or it survived and the app has no record of it — which from your side is the same thing. | No |
| The app offers to recover it and names the script | It kept the context as well as the bytes. Rare, and the difference between a usable file and a usable take. | Yes |
Why so many apps fail it
An MP4 needs an index — a table saying where each frame lives. The cheap moment to write that index is when the recording ends, because that is when you know what went in. Until then it sits in memory. Kill the process and the index dies with it, leaving a file of exactly the right size that no player will touch.
The alternative is to flush a small index every few seconds as you go. Apple’s capture output has done this for years, with a default interval of ten seconds, so iOS apps tend to inherit the good behaviour without asking for it. Android’s CameraX ships a muxer that openly reports itself as not interruption-resilient and writes on stop, so an Android app only survives a kill if somebody went looking for the problem.
The failure nobody expects
Surviving bytes are not the same as a reachable take. The app also keeps a list of your recordings, and that entry is normally written when a take finishes cleanly. A crash can therefore leave a perfectly playable file that the app has no record of — not in the library, not reachable by any button. We found two of these on a test device from an earlier build: 34.7 MB / 13.0s and 36.7 MB / 14.0s, both playable, both invisible until a build that knew to go looking adopted them at launch.
Read cloud backup claims carefully
Several apps in this category advertise cloud backup, and it is worth knowing exactly what that covers. The common pattern is that a copy is uploaded after you save or share the recording, and kept for a fixed window. One popular app documents this plainly: a recording discarded without being saved or shared is never backed up at all, and a file that was not saved cannot be recovered if the app crashed.
That is not a criticism — it is a reasonable feature, honestly described. It is simply a different feature from the one this test is about. Backup protects a finished take. Fragmented writing protects an unfinished one. Only the second one helps when the app dies at minute nine of a ten-minute read.
The harsher version of the test
If you are comfortable with developer tools, the honest version of this test does not use
the app switcher at all. adb shell am force-stop <package> sends a SIGKILL
with no lifecycle callbacks whatsoever, which is harsher than a swipe and harsher than most
real crashes.
Running that loop on a OnePlus KB2001 on API 34 left a 20.9 MB file on disk with no library entry, and the next launch adopted it as a playable 8.0-second take out of a roughly 10-second cycle. Losing about two seconds is what “you lose the fragment in flight” means in practice — and it is why we set the fragment interval to two seconds rather than leaving the platform default of ten.
What a good answer looks like
Three things, in order of how much they matter:
- The file stays playable while it is being written, so a kill costs seconds instead of everything.
- The app reconciles disk against its own library at launch, so a surviving file cannot end up invisible.
- Takes that end without being asked — a call, another app taking the camera, backgrounding — are saved with their context, not left as anonymous orphans. This is the one most apps miss, because it is not a crash and so nobody thinks to handle it.
If you have already lost one, the recovery routes are in your recording app crashed mid-take: is the video recoverable? And if you are choosing an app rather than diagnosing one, the related question of what it will let you export is worth settling at the same time.
Run the test on Orate
We built the app around this failure, so we would rather you checked than took our word for it. The prompter and crash-safe recording are free, with no account.
See how Orate works