What happens to a screen recording when the Mac crashes

You're twenty minutes into a product walkthrough when the Mac freezes. You restart, open the recordings folder and find a file of a reasonable size that no player will open. The video is in there somewhere. The file just doesn't know where.

That failure has a specific cause, and ScreenShare was built to avoid it. The fix has two parts. A third decision, about the camera bubble, follows the same thinking.

Why an interrupted movie file won't open

A regular QuickTime or MP4 file keeps an index, a table that says where each frame and each audio sample sits and how long it lasts. The writer can only complete that table once the recording ends, so it writes it last. If the process dies before that point, you're left with a pile of encoded frames and no map to them. Repair tools exist that try to guess the structure back together. Sometimes they manage.

Fragmented writing changes the order of things. The writer closes a small piece of the movie at regular intervals, and each piece carries its own small index. Anything that reads the file can use every closed fragment without waiting for a final table.

ScreenShare closes a fragment every two seconds. If the app or the whole Mac goes down, the fragment that was still open is at risk. Everything before it is already a readable movie.

Knowing which files belong together

Readable video on its own doesn't give you a recording back. A ScreenShare session writes several files into its own folder:

Recording 2026-10-14 11.19.22/
├── recording.json     metadata, bubble keyframes, edit settings
├── recording.mov      screen video + system audio + microphone tracks
├── camera.mov         raw webcam video
└── thumbnail.jpg

If only the movie files survived, you'd have footage without its context. You wouldn't know where the camera bubble sat, which layout was active or where you paused. So the app saves the recording's state every five seconds. On the next launch it notices a session that never finished, recovers it and puts it in the library next to your other recordings.

The two intervals do different jobs. Fragments keep the media readable, and the saved state keeps the pieces assembled. The app has a self-test that records, crashes on purpose and then runs the recovery, so this path gets exercised and isn't only a promise in a feature list:

B=build/ScreenShare.app/Contents/MacOS/ScreenShare
$B --selftest crash 4 && $B --selftest recover "<folder>"

Disk space is the other common way a long recording ends badly, and it gets the same treatment. ScreenShare shows free space and remaining recording time. It won't start below 1 GB and it stops cleanly below 300 MB. A clean stop with room to spare beats a write error at zero bytes.

Why the camera bubble isn't burned in

The obvious way to record a webcam bubble is to paint it onto the screen image while you record. You get one video track and nothing to assemble later. You also get a bubble that can never move again. If it covered the button you were explaining, that's in the video for good.

ScreenShare records the camera on its own, into camera.mov. While you record, it stores the bubble's position, size and shape as keyframes. The bubble only turns into pixels at export, when a Core Image renderer and a custom video compositor draw the screen, the camera and any captions into each final frame.

That leaves you a lot of room after the fact. You can hide the bubble, pin it to a fixed corner, change its size or shape, or mirror it. Layout switches you made during the recording, say from screen with bubble to side by side, stay editable too. Sync offsets of up to 500 ms in either direction fix camera or microphone lag from Bluetooth or USB devices. That only works because the camera is a separate stream that can be shifted against the screen.

The payoff is biggest in formats you didn't plan for. Record in 16:9, then export a 9:16 vertical version, and ScreenShare moves the camera and captions into the free space below the screen. A burned-in bubble would stay where it was in the wide frame, probably half cropped away.

Edits that never touch the originals

The same idea runs through editing. ScreenShare keeps trims and bubble changes as settings in recording.json and captions in their own transcript.json. "Enhance voice" writes a cleaned-up voice-enhanced.m4a and keeps the original microphone track. Exports land in an Exports folder next to the source files. The README puts it in one line: the original files are never modified.

For crash safety this matters more than it seems. If something goes wrong during an export, you lose that export and start it again. The export reads the source files and writes somewhere else, so a failed export leaves them as they were.

There's a small cost to all this. A recording folder holds several files instead of one finished movie, and you need an export step before you can send anything. I think that trade is right for a tool whose main job is to not lose your take. One finished file is convenient right up to the moment it is half written.

ScreenShare needs macOS 15 or later. Install it, grant screen, camera and microphone access, and record something long that you'd hate to redo, like a full demo or a code review walkthrough. Then try the edits that a burned-in recording wouldn't allow. Move the bubble to the other corner, export a 9:16 version and see where the camera ends up. Download and requirements are on the ScreenShare page.