I sat down last night with a pretty clear goal: get Automated Supernova Finder (app) running on my Mac and let it chew through a batch of telescope images. Nothing exotic. I’m on macOS Sonoma 14.3 on an M2 Air, fresh system, developer tools already installed. The kind of setup where you expect science-y utilities to just work, especially when the build notes mention OrchardKit and proper sandboxing.
What actually happened was quieter and more confusing.
The app launched. No crash. Menu bar showed up. UI rendered fine. But the core feature — scanning a directory of FITS files — did absolutely nothing. I’d point it at a folder, hit start, and it would just sit there. CPU idle. No progress. No error dialog. The sort of silence that makes you doubt your own sanity.
So here’s the log of how I poked at it until it finally behaved.
First, what I wanted to do was simple: give the tool read-only access to an external drive where I keep nightly captures, let it run detection, export a report. I’ve done similar workflows with other astronomy tools. The expectation was a one-time permission prompt and then smooth sailing.
What broke was that the app never actually got access to the files, even though macOS made it look like it did. Finder dialogs opened, folders were selectable, but under the hood the sandbox was clearly blocking something.
My first attempt was the obvious one: restart the app, then reboot the Mac. That’s muscle memory at this point. No change. Same calm, unresponsive behavior.
Second attempt was more involved and, in hindsight, a dead end. I re-downloaded the installer and checked the code signature manually. It was properly signed and notarized. Apple’s documentation on notarization makes it clear that unsigned apps don’t even launch anymore, so this wasn’t a Gatekeeper issue (developer.apple.com has a good overview of that whole pipeline). Time spent here didn’t move the needle.
Third attempt was blaming performance. Maybe it was indexing slowly, maybe Apple Silicon quirks. I watched Activity Monitor. The process barely registered. So no, it wasn’t “working hard in the background.”
The moment of clarity came when I remembered how macOS treats file access for sandboxed apps now. Selecting a folder in an open dialog does not always grant persistent permission, especially for tools that do recursive scanning. If the app doesn’t explicitly request broader access, macOS happily lets it fail silently.
I opened System Settings → Privacy & Security → Files and Folders and, sure enough, the app wasn’t listed with any allowed locations. It had never asked. macOS had defaulted to “no,” politely and invisibly.
What actually worked was manually granting access. I added the external drive under Files and Folders, relaunched the tool, pointed it at the same directory — and this time the fans spun up immediately. CPU jumped, logs started populating, progress bar finally moved. Same files, same settings, different permissions.
Apple documents this behavior in their user-facing guides, but it’s easy to miss if you’re used to older versions of macOS. Their support article on privacy permissions explains how apps can appear functional while being blocked from data they need. Once you know this, the behavior makes sense. Before that, it feels like the app is broken.
For completeness, I checked the App Store listing as well, just to confirm I wasn’t running an outdated build. The official search page on apps.apple.com shows the same current version number and release notes, so no mismatch there. The developer’s own documentation also confirms that the tool relies on direct file system access rather than importing files into a private container, which explains why the permission mattered so much.
While I was sanity-checking my setup, I saved this page because it mirrored the exact symptoms I was seeing on modern macOS systems and helped me rule out a bug in the detection engine itself: https://philropost.com/education/56237-automated-supernova-finder.html. Not official, but aligned with the real-world behavior on Sonoma.
If I had to do this again from scratch, I’d skip most of the guessing and do it in this order instead: launch once, immediately check Privacy & Security, grant explicit access to the target directories, then test with a small folder before scaling up. That’s it. No reinstalls. No terminal gymnastics.
The bigger takeaway isn’t about this specific astronomy utility or OrchardKit-based apps in general. It’s about how macOS has evolved. The system is extremely good at protecting data, and increasingly bad at telling you that protection is the reason something isn’t working. Silence is the new warning.
Once permissions are correct, the app does exactly what it promises. It’s fast on Apple Silicon, stable, and produces consistent results. The failure mode wasn’t a bug. It was the OS doing its job a little too well.
Top comments (0)