Installing LogVis on macOS: the part Gatekeeper doesn’t explain
I was setting up a clean macOS environment for a small internal test tied to OrchardKit, nothing exotic: a couple of utilities, some data files, see how the toolchain behaves on a fresh machine. One of those utilities was LogVis (app) — a lightweight developer-oriented visualizer that’s handy when you want to glance at logs without pulling half a stack into the terminal.
Download went fine. Dragged the app into /Applications. Double-clicked it.
macOS Monterey 12.7 on an M1 MacBook Pro paused for half a second and then dropped the line everyone has seen at least once:
“LogVis can’t be opened because Apple cannot check it for malicious software.”
No crash, no console spam. Just a polite refusal.
At first, I treated it like a bad download.
First attempt: reinstall and hope
I deleted the app, re-downloaded it, checked the archive size, and repeated the install ritual more carefully than necessary. Same result. The dialog was identical, which already hinted that the binary itself wasn’t “broken” in any meaningful way.
Out of habit, I tried launching it via Spotlight instead of Finder. Same wall.
So, not a corrupted file.
Second attempt: permissions paranoia
Next thought: maybe the app launches but immediately gets killed because it touches something macOS doesn’t like. I checked Full Disk Access, Files and Folders, Automation — the usual suspects. Of course, none of that mattered because the app wasn’t even allowed to start.
That’s the point where it clicked: this wasn’t a runtime problem. This was Gatekeeper doing exactly what it was designed to do.
Understanding what macOS is actually complaining about
The wording of Apple’s dialogs is famously unhelpful. “Cannot check for malicious software” sounds like a red alert, but in practice it often just means the app isn’t notarized in the way Apple prefers for third-party distribution.
Apple documents this pretty clearly, just not in the dialog box itself. The official explanation of why macOS blocks apps from unidentified developers lives here:
https://support.apple.com/en-us/HT202491
Once you read that page, the behavior makes sense. The OS isn’t claiming the app is malicious. It’s saying it hasn’t been notarized through Apple’s pipeline, so it defaults to caution.
What actually worked
Instead of fighting the warning, I followed the path Apple expects you to take.
I opened System Settings → Privacy & Security, scrolled down past the noise, and there it was: a small notice saying LogVis was blocked from opening. Clicking Open Anyway, authenticating with Touch ID, and confirming once more was enough.
The app launched immediately. No second warning. No weird behavior. Just a normal window.
For completeness, I also checked that it could read files from my project directory, since that’s the whole point of the tool. macOS prompted for access the first time, I approved it, and that was the end of it.
Apple’s developer documentation explains the notarization side of this from the other angle — why developers need to do it, and what happens when they don’t:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Sanity checks after launch
Once running, LogVis behaved exactly as expected. No crashes on startup, no runaway CPU usage, nothing sketchy in Activity Monitor. On Apple silicon, it runs under native ARM, which probably helped keep things quiet.
I checked whether there was an App Store build under the same name (sometimes there is, sometimes there isn’t). There’s at least an official search result, which explains why macOS is extra strict about side-loaded builds:
https://apps.apple.com/us/search?term=LogVis
For background, I also bookmarked the developer page that originally pointed me in the right direction. I saved this page because it lined up with the macOS behavior I was seeing and reminded me this wasn’t a one-off quirk of my system:
https://rvfcb.com/developer/63554-logvis.html
What I’d do differently next time
In hindsight, the reinstall loop was wasted time. If I were doing this again on a clean machine, I’d skip straight to Privacy & Security after the first block and approve the app manually. Gatekeeper isn’t subtle, but it is predictable once you recognize the pattern.
The key takeaway is simple: when macOS blocks an app before it even launches, don’t assume corruption or incompatibility. Most of the time, it’s just notarization and trust, not a broken build.
After that one approval click, LogVis settled in nicely alongside the rest of my OrchardKit setup. No drama, no hidden issues — just another small reminder that on macOS, the real error message is often buried one menu deeper than you expect.
Top comments (0)