Vibe coding a native Netflix macOS app in an afternoon
February 16, 2026·3 min read
API cost is the equivalent if billed per token. Actual cost is a flat subscription.
I had a working macOS app. A floating video player for Nebula.tv. I pointed Claude at the repo and said: make it work with Netflix. Four hours later, seven releases were on GitHub.
That’s not from scratch. The Nebula app already handled always-on-top windows, snap mode, keyboard shortcuts, auto-updates via Sparkle. The Netflix version needed DRM support, different DOM handling, and a UI that made sense for Netflix. Still a real app, just not a blank canvas.
The entire build was 46 prompts across 2 sessions. Most of my inputs were five words or less: “run it”, “yup works”, “commit, push, publish”, or just “1” to pick an option. The project rename alone touched 32 files (Swift classes, test targets, bundle IDs, directory names). I didn’t open Xcode once.
First things first: will it actually work? Netflix needs FairPlay DRM, and if the web view can’t handle it, nothing else matters. So we vibed a quick test. Dead simple, up and running in under a minute. It worked on the first try. That was the luckiest part of the afternoon.
The first release went out at 3:30 PM. By 5 PM I was on v1.0.6 with a welcome sheet, debug overlay, and all the bugs squashed. The bugs were real, though. An about dialog that wouldn’t dismiss when you clicked OK. Stuff that looks correct in code but breaks the moment a human touches it. You have to test everything. Now the rule is: every bug gets a test before it gets a fix. Claude writes the test, then the patch. No regressions, ever.
An afternoon for an auto-updating macOS app distributed on GitHub. But the honest takeaway isn’t “AI is fast.” It’s that AI plus working code plus human direction is fast. The Nebula app did 80% of the heavy lifting by existing. Every app you ship makes the next one almost free to build.