Should I vibe code
Mac screen recorder and multitrack video editor for tutorials
Mic capture is a flag. System audio is a signed driver or an OS version check. That is where the $199 went.
?
Their verdict, the ScreenFlow perpetual licence price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Nothing here can hurt anyone but your own afternoon, so this is a scope disagreement rather than a warning. Screen to a file on macOS really is a sitting — ScreenCaptureKit hands you frames, AVFoundation hands you a container, and it works on the first try. Then someone watches your tutorial and asks why they cannot hear the app you were demonstrating. Recording what the speakers are playing is not a flag. macOS has never handed an ordinary application the system audio mix, and for most of this product category's life the only route was a virtual audio device installed into the operating system — a signed, notarised driver that a user has to approve in Security settings and that somebody has to keep working across releases. Recent macOS versions finally expose audio capture through ScreenCaptureKit, which is a genuine improvement and also means your recorder now needs two code paths and a version check. That one feature — plus the multitrack timeline, the iOS-over-USB capture and the callout animations that make a tutorial watchable — is the two hundred dollars. Build the recorder. It is a genuinely nice afternoon and you will not finish the editor.
What actually breaks
not "if". the specific failures.
- System audio, which is the feature people assume is a checkbox and which is either a signed system extension you maintain forever or a ScreenCaptureKit path that only exists on newer macOS
- Every macOS release, because Apple has now deprecated a generation of capture APIs and a recorder is a piece of software that lives on exactly the surface that keeps moving
- Recording a window that moves between displays with different scale factors, where the output is either soft or cropped and neither is an error
- iOS device capture over USB, which is a whole separate AVFoundation device path and the reason a lot of people buy this specific application
- The long take, when the encoder stalls or the disk fills and the file has no index — an unfinalised MP4 is not a damaged recording, it is not a recording
- The project bundle, which is the first thing you invent and the thing every future version has to keep opening, referencing media that has since been moved
- Undo, once the timeline supports ripple edits, because an editor without a real command history is a place people lose work
- Whatever else was on the screen: notifications, a browser tab, a terminal with a token in the scrollback, now baked into pixels with no redaction step
Is that you?
the verdict is a default, not a law
- You want a recorder: display or window, microphone, straight to a file with defaults you never think about again
- The editing you need is trimming the ends, which is a stream copy and not an editor
- Microphone audio is enough, or you are content to route system audio through something like BlackHole and stop there
- The output goes somewhere forgiving — a bug report, a Slack thread, an internal walkthrough
- You need a timeline with several tracks, ripple edits and undo you can rely on
- System audio is required and you were planning to solve it in an afternoon
- You are recording iOS devices, which is a different capture pipeline wearing the same UI
- Someone else's deadline depends on your render finishing
- You are about to invent a project file format that has to keep opening a year from now
If you build it anyway
the checklist, then the prompt that enforces it
- Decide about system audio before you write anything else, because it determines whether this is an afternoon or a product. Check the OS version, use the ScreenCaptureKit audio path where it exists, and tell the user honestly when it does not rather than recording silence.
- Do not ship your own audio driver. If you truly need system audio on older macOS, depend on an existing virtual device like BlackHole and document the setup — a system extension is a signing, notarisation and support commitment, not a feature.
- Treat Screen Recording permission as an explicit application state. Without the grant macOS hands you a black or desktop-picture-only frame and no exception, which reads as your bug for the first hour.
- Set a constant frame rate at capture and let the encoder duplicate frames. Screen capture is naturally variable-rate and every editor downstream assumes a fixed clock.
- Record audio to a separate file at a known sample rate as well as muxing it. When sync drifts, a standalone WAV is the only thing that lets you fix it rather than re-record.
- Write in short finalised segments so a crash or a full disk costs the last chunk instead of the session, and check free space before the record button does anything.
- Get display geometry right early: capture the display the user chose, at its real backing-store dimensions, and test on a mixed-DPI two-monitor setup before adding a single feature.
- If you invent a project bundle, version it in the first commit, store media by relative path with an absolute fallback, and write the v1 loader before shipping v1.
I want to build a macOS screen recorder, and possibly an editor on top. Keep me
honest about which of those I am actually doing, and handle the capture
correctness before any interface exists.
1. First question back to me: do I need system audio? If yes, explain the two
paths — ScreenCaptureKit audio capture on supported macOS, or a virtual
device such as BlackHole — and refuse to write a driver of our own.
2. Use ScreenCaptureKit rather than deprecated capture APIs, and keep the OS
version check and its fallback in one place so the next deprecation is one edit.
3. Treat the Screen Recording permission as an explicit state with a real error
path. Detect frames arriving black rather than recording nothing for an hour.
4. Capture at an explicit constant frame rate and let the encoder duplicate
frames. Explain why variable frame rate drifts out of sync on long takes.
5. Also write audio to its own file at a known sample rate, alongside muxing
it, so drift can be repaired later instead of re-recorded.
6. Write output in short finalised segments so a crash or a full disk costs the
last segment, not the session. Say what an unfinalised MP4 is worth.
7. Check free disk space before recording starts, estimate bytes per minute at
my settings, and abort loudly at a threshold.
8. Get multi-display and fractional-scaling geometry correct before any feature
work: capture the display I picked, at its real pixel dimensions.
9. Never re-encode when the operation does not need it, and show it in the UI
when it does. Small text in screen recordings is what generational loss ruins.
10. If a project file is unavoidable, version it in the first commit, reference
media by relative path with an absolute fallback, and write the v1 loader
before shipping v1.
11. Warn me before recording that notifications, browser tabs and terminal
scrollback are about to become pixels I cannot redact afterwards.
12. Out of scope: a multitrack timeline, callouts, captions, iOS device capture.
Say so, and note ScreenFlow is $199 once and OBS Studio is free.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment you need a second track, or system audio, or an iPhone screen. Two hundred dollars once — not per month — buys eighteen years of codec and permission edge cases, an undo stack that works, and the capture paths Apple keeps moving underneath everyone. Set against a weekend of your time and every macOS release after it, that is not a close call. If what you actually wanted was the capture, OBS Studio does it free and better than a first attempt, and the honest split is: record with something free, edit with something bought, and write only the small tool in between that does the repetitive thing you keep doing by hand.
There is barely anything to exit, which is the nice part of local software: the recordings are files, the audio is a file next to them, and deleting the app changes nothing about either. The one trap is a proprietary project bundle that references media by internal identifier — build that and quitting means owning a folder of clips you can no longer match to a timeline. Keep the edit decisions in something readable, an ffmpeg concat list or an EDL, and abandoning your editor costs an afternoon of re-cutting.
The mature open-source capture engine, with the permission, multi-display and encoder problems already solved.
Open-source non-linear editor built on MLT; the free answer to the half of ScreenFlow that is a timeline.
Cross-platform open-source video editor, lighter than Kdenlive and native on macOS.
Questions
canivibecodeit says one sitting. Where is the disagreement?
On what ScreenFlow is. They are right that a Mac screen recorder is a sitting — ScreenCaptureKit really does make the first working version trivial. The disagreement is that ScreenFlow is mostly the other things: a multitrack timeline, cursor and callout animation, closed captions, iOS device capture over USB, and system audio. Strip those out and you have something closer to Tella, which is a ship-it here.
Is ScreenFlow still being developed?
Yes. The current tech-specs page lists macOS Tahoe 26 and Sequoia 15 as supported operating systems and Apple Silicon plus Intel Macs, which is not what an abandoned Mac application looks like. It is still sold as a perpetual licence at $199 with discounted paid upgrades, rather than having been moved onto a subscription the way Camtasia was.
Why does system audio keep coming up?
Because macOS has never let an ordinary application read the system audio mix, and every screen recorder that offers the feature has had to solve it. The traditional route is a virtual audio device installed into the operating system: a signed, notarised driver, a user approval in Security settings, and a support burden for as long as you ship it. Recent macOS versions expose audio capture through ScreenCaptureKit, which is much better, and also means anything that still supports older systems carries both paths and a version check between them.
Which part is actually worth building?
The thin piece in the middle, same as Camtasia. Capture with OBS or ScreenCaptureKit, edit in something that exists, and write the small tool that automates the repetitive thing you do by hand every week — batch trimming to markers, normalising loudness, generating thumbnails, exporting the same three presets. That is a real afternoon, genuinely useful, and the version still running next year.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Forty minutes in, the audio is a second ahead of the picture. That is variable frame rate, and it is the job.
Automatic cursor zoom looks like magic because getting it to feel right is genuinely hard.
Screen plus camera to a file is platform APIs. The polish is where the money went.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice