Gildav

Listen, yesterday I was tinkering with Gildav (app) and ran into one of those annoying macOS permission walls that looks simple on the surface but ends up eating your evening.

The issue was this: the app launched fine, interface loaded, buttons clickable — but it just wouldn’t access any of my files. Every time I tried to open or save something, nothing happened. No proper error dialog, just silent failure. At first I thought it was a bug in the app itself. Turns out, it was macOS being “helpful.”

What I did first (and what didn’t work)

My first instinct was the classic routine: delete and reinstall. I grabbed a fresh copy, moved it into Applications, relaunched. Same behavior. Then I assumed maybe it didn’t like my working folder, so I tried putting test files on the Desktop. Still nothing.

I even checked file permissions manually via Finder → Get Info to see if something weird was going on with read/write flags. Everything looked normal. I briefly considered that the app was just broken.

Then I remembered how macOS handles file access since Mojave — all that privacy sandboxing. Apps can’t just freely read your Documents, Desktop, Downloads, external drives, etc. They need explicit permission under Privacy & Security.

What I realized

macOS treats access to certain folders as protected. If the app doesn’t explicitly request access the right way — or if you dismissed the permission prompt once — it can silently lose access.

Apple explains this here:
https://support.apple.com/en-us/HT210190

The key section is about granting apps access to files and folders. If the app doesn’t appear there, it might never have been properly registered with the system.

In my case, Gildav wasn’t showing up under “Files and Folders” or “Full Disk Access” at all. Which meant macOS wasn’t letting it touch anything sensitive.

What actually helped

Here’s what finally fixed it:

I went to System Settings → Privacy & Security → Full Disk Access.

Gildav wasn’t listed, so I manually added it using the “+” button and selected the app from Applications. After that, I toggled it on.

Relaunched the app — and suddenly file access worked perfectly. It could open files from Documents, save outputs, even read from an external drive.

That was it. No bug. Just macOS privacy restrictions doing their thing.

For context, Apple’s broader developer documentation on app sandboxing is here:
https://developer.apple.com/documentation/security/app_sandbox

Reading through that made it clearer why this happens. If the developer hasn’t implemented scoped bookmarks or proper entitlement handling, macOS may block access outside the app’s container unless you explicitly grant broader permission.

I also checked whether there was a Mac App Store version, because apps distributed through the store tend to handle permissions more predictably. General App Store search entry point is here:
https://apps.apple.com/

But Gildav seems to be distributed independently, which makes sense why it relies more on manual permission handling.

I found this page useful while digging around for confirmation that others had similar behavior — the resource I used:
https://dejavu-ks.com/developer/85597-gildav.html

It helped me rule out that it was some unique corruption on my machine.

Why this happens more often now

Since macOS Mojave and especially on Ventura and Sonoma, Apple tightened privacy controls significantly. Apps must explicitly request access to:

• Desktop
• Documents
• Downloads
• External volumes
• Network volumes
• Removable media

If the app doesn’t prompt properly, or if you clicked “Don’t Allow” once without realizing, macOS doesn’t keep nagging you. It just quietly blocks access.

That silent failure is the confusing part. There’s no big red warning. The app just behaves as if nothing exists.

One more thing I tested

Before granting Full Disk Access, I tried just enabling it under “Files and Folders.” But since Gildav wasn’t even appearing in that list, there was nothing to toggle. That’s when I understood it wasn’t triggering the standard permission request flow.

Adding it manually to Full Disk Access essentially overrides the sandbox limitation and gives it broad read/write capability. Not something you should do for random apps, but for a trusted utility it’s reasonable.

Also important: after adding it, you must fully quit and relaunch the app. Just closing the window isn’t enough.

On performance and stability

After granting access, everything behaved normally. No crashes, no CPU spikes, no weird background activity. So it clearly wasn’t a stability issue. The app just needed permission to do its job.

It’s funny how often macOS problems look like app bugs when they’re actually OS-level policies.

What I’ll do differently next time

Next time an app “can’t see” my files, I won’t waste time reinstalling first. I’ll immediately check Privacy & Security.

Because reinstalling doesn’t reset macOS privacy decisions the way people think it does. Those permissions are stored separately by the system.

Quick checklist for future me

• If an app can’t access files, check Privacy & Security first.
• Look under “Files and Folders.”
• If it’s not listed, consider adding it to “Full Disk Access.”
• Fully quit and relaunch after changing permissions.
• Only grant broad access to apps you trust.

Honestly, once I understood it was a permissions issue, the fix took under two minutes. The hour before that was me chasing the wrong problem.

Anyway, just sharing in case you ever hit the same wall. macOS security is great in theory, but sometimes it feels like it protects you from your own software.