Field Report / Troubleshooting Log — Vuo on macOS
I sat down to wire a quick motion-reactive visual patch. Nothing fancy: MIDI in, a couple of shaders, export a movie. I grabbed Vuo (the app) on a MacBook Pro with an M1 Pro, macOS Sonoma 14.3. The goal was simple—launch it, sketch the graph, move on with my evening.
That’s not what happened.
First launch: double-click, one bounce in the Dock, then nothing. No dialog, no crash reporter, just silence. I tried again. Same thing. Activity Monitor showed the process blinking in and out like it was embarrassed to exist. My first assumption was a bad build or a half-downloaded archive.
I did the obvious stuff first. Re-downloaded the DMG, verified the checksum, dragged the app to /Applications again. No change. Then I went to System Settings → Privacy & Security expecting the usual Gatekeeper warning, but there was nothing there. No “Open Anyway,” no hint. That’s when I realized this wasn’t a classic “can’t be opened because Apple cannot check it” situation. It was worse: the OS was quietly killing it.
Second attempt was more aggressive. I launched it from Terminal to see if stderr would say anything useful. It didn’t. Just an exit code that screamed codesigning without actually saying so. I even cleared the quarantine attribute manually, which sometimes helps with tools that bundle helpers:
xattr -dr com.apple.quarantine /Applications/Vuo.app
Still nothing. At this point I briefly suspected Rosetta weirdness (even though this build is Apple Silicon native), so I forced it to open using Rosetta as a test. Same result. Dead on arrival.
The breakthrough came when I stopped guessing and actually checked the system logs. Console.app showed Gatekeeper denying execution of a bundled helper inside the app—not the main binary. That’s the kind of detail macOS won’t surface unless you go looking. The helper wasn’t notarized in a way Sonoma liked, so the whole launch chain collapsed silently.
Once I understood that, the fix was boring but effective. I reinstalled using the latest notarized build directly from the developer’s site and made sure the first launch happened via Finder, not Terminal. That triggered the proper security prompt. After approving it once, everything behaved normally. Launch time dropped to about two seconds, and the editor stayed stable even with GPU-heavy nodes.
For reference, Apple’s own notes on how Gatekeeper and notarization interact are still the most accurate explanation of this behavior:
If you’re looking for the official distribution, the Mac App Store search is here (useful just to confirm versioning and requirements):
https://apps.apple.com/us/search?term=Vuo
And the developer documentation is solid, especially around system requirements and helper tools:
https://vuo.org
I also saved this page because it helped me sanity-check macOS security behavior when audio/visual tools fail silently on modern systems: https://deadtriggermod.xyz/graphics-and-design/74818-vuo
What actually worked, in short, was not “fixing” the app but letting macOS do its security dance properly with a build it trusts. Everything else was noise.
If I were doing this again, I’d skip the dead ends and do it this way from the start: install the latest notarized release, launch once from Finder to surface Gatekeeper prompts, verify helper permissions in Privacy & Security, and only then start debugging performance or GPU issues.
Lesson relearned: on modern macOS, when an app doesn’t crash and doesn’t open, it’s usually not broken. It’s just being quietly judged.