VSD Viewer on macOS Sonoma: When It Opens but Shows Nothing
Field Report: VSD Viewer (app) on macOS Sonoma — The Case of the Blank Canvas
Machine: MacBook Air M2, macOS Sonoma 14.3
Source: direct download build, supposedly from NimbusApps
Objective
Open a couple of old .vsd diagrams a client sent me. Nothing fancy. Just view, export to PDF, move on with my day.
I grabbed what looked like the most likely candidate from NimbusApps — VSD Viewer (app). The name in the URL matched, so I went with it. Downloaded the DMG, dragged it into Applications, standard routine.
That’s where the easy part ended.
What Broke
The tool launched. No Gatekeeper drama. No “damaged and can’t be opened” warning. Just… a window. Empty. I dropped a Visio file onto it — beachball for three seconds — then nothing. Blank canvas. No error dialog. No crash report. Just silence.
Activity Monitor showed it was alive. CPU near zero. Memory stable. It just refused to render anything.
At first I thought the files were corrupt.
They weren’t.
Attempt #1 — Blame the Files
I opened the same .vsd on a Windows VM. Fine. Exported again. Re-sent. Tried older versions. Same result. Blank.
So not the documents.
Attempt #2 — Rosetta Guess
Because I’m on Apple Silicon, I wondered if it was some awkward Intel-only build misbehaving. I checked the binary with:
file /Applications/VSD\ Viewer.app/Contents/MacOS/*
Yep. x86_64.
So I forced it through Rosetta explicitly. Finder → Get Info → “Open using Rosetta.”
No change. Still blank.
At this point I started suspecting something permission-related. macOS has been aggressively sandboxing file access lately, especially for apps downloaded outside the App Store.
Apple’s own doc on controlling app access to files explains how this works:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-mchld5a35146/mac
And that’s when it clicked.
Attempt #3 — Privacy & Security
I went to:
System Settings → Privacy & Security → Files and Folders
Nothing listed for the tool.
Then I checked Full Disk Access.
Also nothing.
Which is weird, because Sonoma typically prompts the first time an app tries to read user folders. But this one didn’t. It just silently failed.
So I manually added it to Full Disk Access. Relaunched.
Still blank.
Okay.
Attempt #4 — Quarantine Flag
I checked extended attributes:
xattr -l /Applications/VSD\ Viewer.app
Sure enough: com.apple.quarantine.
Normally, that’s fine — notarized apps pass through Gatekeeper automatically. Apple explains the notarization pipeline here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
But if an app isn’t properly notarized, macOS sometimes restricts behavior without throwing obvious errors.
So I removed the quarantine attribute:
xattr -dr com.apple.quarantine /Applications/VSD\ Viewer.app
Relaunched.
Different behavior this time. Instead of staying blank, it actually prompted for file access when I opened a document.
Progress.
What Actually Fixed It
The real fix was a combination of two things:
- Remove the quarantine attribute.
- Launch the app once from Terminal instead of Finder.
When I ran it directly from the binary inside Contents/MacOS, macOS finally triggered the proper file access dialog. After granting permission to Documents, everything worked normally.
The diagrams loaded instantly. Export to PDF worked. No rendering glitches.
I bookmarked this page about macOS file handling and sandbox behavior because it helped me think through the issue:
https://treadmillreviews.online/file-management/21534-vsd-viewer.html
After permissions were properly registered, I could launch it normally from Finder again.
What I’d Do Immediately Next Time
Honestly, I’d skip the guessing and check three things in this order:
- Verify architecture (Intel vs Apple Silicon).
- Inspect quarantine attribute with
xattr. - Manually trigger permissions via Terminal launch if the UI stays silent.
If I didn’t want to deal with direct downloads at all, I’d check whether a Mac App Store build exists, since sandboxing is cleaner there:
https://apps.apple.com/us/genre/mac/id39
NimbusApps doesn’t always distribute through the store, but when they do, it saves headaches.
Final Notes
This wasn’t a performance issue. It wasn’t a broken renderer. It wasn’t corrupt documents.
It was macOS quietly blocking file access without clearly telling me.
That’s the frustrating part about modern macOS security layers — they’re protective, which is good, but sometimes the UX around failures is… subtle.
Once permissions were properly established, the app behaved exactly as expected. Stable. Lightweight. No lag even with larger diagrams.
If I had known from the start that a quarantined, non-notarized build can fail silently when accessing protected folders, I’d have saved myself an hour.
Lesson logged.
