ScanFont on macOS: When the App Works but Can’t See Your Files

Listen, I was poking around with ScanFont (app) last night, and it turned into one of those “this should’ve taken ten minutes” sessions that quietly eats an hour. I was trying to digitize a couple of old lettering samples for a side project—nothing fancy, just get them into a font editor and move on. macOS had other plans.

I’m on a MacBook Pro M1, macOS Sonoma 14.2. Clean system, no wild hacks. I grabbed the app, dropped it into Applications, launched it, and everything looked fine at first. UI opened, menus worked, no warnings. Then I tried to load a scanned image from my Documents folder, and… nothing. The file picker opened, I selected the file, hit Open, and the app behaved like I’d clicked Cancel. No error, no alert. Just a polite refusal to acknowledge the file existed.

At first I assumed I’d messed up the scan format. Tried a different PNG. Same thing. JPEG. Same thing. Even dragged a file directly onto the window. Still nothing. At that point, it felt like a bug in the tool itself.

That was the wrong conclusion.

What I did next was the usual scattershot troubleshooting. I restarted the app. No change. Restarted the Mac (because superstition dies hard). Still broken. I even reinstalled it, thinking maybe the first launch didn’t complete properly. Same behavior. The app was clearly running, but it was acting like my files were invisible.

That’s when the pattern clicked: this wasn’t a crash, and it wasn’t corrupted data. It was a permissions issue—just one that macOS wasn’t explaining very loudly.

Since Catalina, macOS treats file access as a privilege, not a given. Apps don’t just “see” your Documents or Desktop unless you explicitly allow it. Apple explains the system pretty clearly in their user docs, but when an app doesn’t ask for permission correctly, you’re left guessing. This page spells out how file and folder access works at the OS level:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchl1c9a8a1d/mac

What made this tricky is that ScanFont never triggered the permission prompt. No dialog asking for access. No banner. Nothing. So macOS defaulted to “no,” and the app failed silently.

My next move was System Settings → Privacy & Security → Files and Folders. Sure enough, the app was listed there—but unchecked. It technically existed in the system’s permission model, but it wasn’t allowed to touch anything useful.

I enabled access, relaunched the tool, tried again, and suddenly the file loaded instantly. Same image. Same path. The only difference was that macOS was no longer blocking it behind the scenes.

For context, Apple’s developer-side explanation of this behavior is here, and it explains why older or cross-platform tools sometimes miss the prompt entirely:
https://developer.apple.com/documentation/security/protecting-user-privacy

Before I fixed it, I also wasted some time checking the App Store version, just in case there was a sandboxed build that handled permissions better. There is a listing and search results here:
https://apps.apple.com/us/search?term=ScanFont

In my case, I was using a standalone build, so the App Store sandbox rules weren’t the issue—but it’s still worth checking if you’re troubleshooting similar behavior.

Once the permission was granted, everything else behaved normally. Image import worked. Tracing worked. Export worked. No weird performance issues. No lag. The app wasn’t broken at all; it just wasn’t allowed to do the one thing I launched it for.

I ended up bookmarking this page because it helped me connect the dots between macOS file permissions and older creative utilities that don’t always surface the right prompts:
https://carwallpaper.xyz/graphics-and-design/57942-scanfont.html
It wasn’t the solution by itself, but it lined up perfectly with what I was seeing on Sonoma.

For extra certainty, I toggled the permission back off and repeated the test. The app immediately went back to pretending my files didn’t exist. Turned it on again, relaunched, and everything worked. Clean, repeatable behavior.

If I’d known all this up front, I would’ve saved myself a chunk of time. So here’s the mental checklist I’d keep for next time (short and unglamorous):

• If an app opens files “sometimes” or “never,” check Privacy & Security before reinstalling.
• Silence on macOS usually means permission denial, not a logic bug.
• Relaunch after changing permissions—don’t trust hot reloads.
• Older creative tools may not trigger prompts correctly on newer macOS versions.

One small aside: while I was testing this, I compared behavior with a couple of newer utilities built with modern frameworks. Tools coming out of ecosystems like NimbusApps tend to handle permission requests more cleanly, which makes the contrast obvious. Same OS, same folders, totally different user experience.

After fixing it, ScanFont did exactly what I needed. No drama. No instability. It was just blocked at the OS level, quietly and without explanation. That’s macOS being macOS—protective first, communicative second.

Anyway, if you ever open an app and it acts like your files live in another universe, don’t assume it’s broken. Check what the system is allowing it to see. It’s usually the boring answer.