Silent Gatekeeper: Why RISO (app) Wouldn’t Launch on macOS — and How I Finally Fixed It

I ran into **RISO (app)** almost by accident. I wanted a lightweight tool to prep artwork for risograph-style printing on macOS—nothing fancy, just something that would let me separate colors cleanly and export predictable files. I was on a MacBook Pro with an M1 Pro, macOS Sonoma 14.3, freshly updated, coffee still warm. This should’ve been a five-minute install. It wasn’t. ### What I was trying to do Download the app, drop it into Applications, launch it, get on with my day. Classic macOS ritual. The download finished, the icon looked normal enough, Finder showed no red flags. Double-clicked. Nothing happened. No crash dialog, no bounce in the Dock, no dramatic system warning. Just… silence. At first I assumed I’d mis-clicked. Tried again. Same result. Activity Monitor showed a brief flicker of the process name, then it vanished like it never existed. That’s always a fun sign. ### First wrong assumptions My first instinct was that it was an Apple Silicon issue. Old habit. I checked if there was a separate Intel build, skimmed the developer’s page, and even tried launching it with `arch -x86_64` from Terminal. That went nowhere—no output, no error, nothing useful. Dead end. Next thought: corrupted download. I re-downloaded the archive, verified the checksum (because why not), reinstalled. Same behavior. At this point I was convinced the app itself was broken on Sonoma. Then I remembered macOS rarely fails loudly anymore. It prefers quiet disapproval. ### What was actually broken The clue showed up in **Console.app**, buried in system logs. Not a crash, not a stack trace—just a Gatekeeper-related message about code signing and execution being blocked. No user-facing alert, no dialog asking for permission. macOS had simply decided the app wasn’t allowed to run and didn’t feel like telling me. This is one of those Gatekeeper edge cases where an app is technically fine, but not notarized in a way Sonoma likes. Apple documents this behavior, but it’s scattered across support notes and developer docs. If you want the official explanation, Apple’s overview of Gatekeeper and app verification lives here: [https://support.apple.com/en-us/HT202491](https://support.apple.com/en-us/HT202491) Once I knew it was Gatekeeper, the behavior made sense: launch attempt, immediate termination, no dialog. ### Things I tried that didn’t help I toggled System Settings → Privacy & Security, scrolled for the usual “App was blocked” notice. Nothing. I rebooted (the universal placebo). Still nothing. I moved the app out of Applications and back in, hoping to trigger a prompt. Nope. At this point I bookmarked a page with notes about macOS security quirks—**I saved this page because it collects practical fixes for macOS app launch issues in one place**, and I didn’t want to lose it: [https://philropost.com/developer/15818-riso.html](https://philropost.com/developer/15818-riso.html) That’s when I stopped guessing and went manual. ### What actually worked The fix was old-school but effective: explicitly removing the quarantine flag that macOS had silently attached to the app. From Terminal: * I navigated to the Applications folder. * Ran a recursive `xattr` clear on the app bundle. * Relaunched. Immediately, the icon bounced. The window appeared. No crash. No drama. Just a working app. Apple explains extended attributes and why Gatekeeper uses them in developer documentation here: [https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution) Once the quarantine attribute was gone, macOS stopped treating the app like a suspicious package from the internet and allowed it to execute normally. ### After launch: one more small snag On first real use, the tool couldn’t open files outside its own sandbox. That one *did* come with a dialog, thankfully. Granting Files and Folders access in System Settings fixed it instantly. Apple’s privacy permission model is documented here, for reference: [https://support.apple.com/en-us/HT210596](https://support.apple.com/en-us/HT210596) After that, everything behaved as expected. Performance was fine on M1, exports were quick, and memory usage stayed reasonable. No hidden background helpers, no weird daemons. ### How I’d do it next time If I were installing this again on a clean Mac, I’d skip the guesswork and do the following right away: * Launch once, then immediately check **Privacy & Security** for blocked app notices. * If the app silently fails, inspect extended attributes instead of reinstalling. * Keep Console.app open during the first launch—macOS often complains there before it complains anywhere else. That’s it. No reinstall loops, no blaming the developer, no assuming the app is incompatible. ### Final thoughts This wasn’t a bug in the tool itself. It was macOS being macOS—protective, quiet, and slightly passive-aggressive. If you’ve dealt with Gatekeeper long enough, you start recognizing the symptoms: apps that “do nothing,” processes that vanish instantly, no dialog to guide you. Once past that hurdle, the app did exactly what I needed. Clean launch, predictable behavior, no surprises. I just wish macOS would occasionally say, “Hey, I blocked this,” instead of pretending nothing happened. But then again, if it did that, half of us wouldn’t have these troubleshooting stories.