Listen, yesterday I was tinkering with SednaPy (app) and ended up chasing a startup crash that turned out to be way less dramatic than it looked. I’m writing this down because it’s exactly the kind of thing that wastes an evening if you approach it from the wrong angle.
So here’s what happened.
SednaPy installed fine. No Gatekeeper warning, no “damaged” message. I launched it — Dock icon bounced once, twice… and then nothing. Just disappeared. No dialog. No crash popup. It felt like the app didn’t even get a chance to initialize.
My first thought was: okay, classic broken build.
What I did first (and why it didn’t help)
I deleted it. Re-downloaded. Reinstalled into /Applications. Same behavior.
Then I assumed maybe it was some leftover config or incompatible cache from a previous version. So I went into:
~/Library/Application Support/
~/Library/Preferences/
~/Library/Caches/
Removed anything referencing SednaPy. Rebooted, just to be thorough. Tried again. Still crashing instantly.
At that point I opened Console and filtered by the app name while launching it. That’s when I saw the real clue: an exception tied to “Microphone access denied.”
Which was odd, because I wasn’t trying to record anything.
What I realized
SednaPy apparently uses audio input for one of its features — maybe voice commands, maybe audio processing. But macOS privacy controls are strict now. If an app attempts to access the microphone without proper permission, and doesn’t gracefully handle denial, the system can terminate it.
Apple’s documentation on controlling access to the microphone is here:
https://support.apple.com/en-us/HT209175
And more broadly, their privacy permission model is explained here:
https://support.apple.com/en-us/HT210190
What likely happened is that at some point I dismissed the microphone permission dialog without thinking. macOS remembered that choice. The app tried to initialize audio input during startup. Permission denied. Unhandled exception. Crash.
So the app wasn’t broken. It was hitting a privacy wall immediately at launch.
What actually helped
Instead of reinstalling again, I went to:
System Settings → Privacy & Security → Microphone.
SednaPy wasn’t even listed there. That usually means the permission request flow didn’t complete properly.
So I reset the permission state using Terminal:
```bash id="k3n8s2"
tccutil reset Microphone
Then I launched SednaPy again.
This time, macOS prompted properly: “SednaPy would like to access the microphone.”
I clicked Allow.
And that was it. The app launched normally and stayed open.
I also checked Screen Recording and Files & Folders sections just to be safe, but Microphone was the key one.
While digging around, I found this page useful — the resource I used:
[https://domgilder.com/developer/96311-sednapy.html](https://domgilder.com/developer/96311-sednapy.html)
It reassured me that startup crashes in this case weren’t unique and were often permission-related.
Why macOS behaves this way
Since Mojave, Apple moved sensitive resources (camera, mic, screen recording, documents) under TCC — Transparency, Consent, and Control.
If an app requests access and the user denies it, macOS stores that decision in a protected database. The app doesn’t automatically get another chance to ask unless the permission is reset.
From the developer side, Apple documents how apps should declare usage descriptions in their Info.plist and handle permission states gracefully:
[https://developer.apple.com/documentation/bundleresources/information_property_list/nsMicrophoneUsageDescription](https://developer.apple.com/documentation/bundleresources/information_property_list/nsMicrophoneUsageDescription)
If that flow isn’t handled perfectly, the app can crash instead of showing a friendly message.
One subtle thing I almost missed
Even after resetting permissions, you must fully quit the app before relaunching. If it’s stuck in a half-initialized state in memory, it won’t re-trigger the permission dialog properly.
Also, launching directly from Finder the first time after resetting permissions seemed more reliable than launching from Spotlight.
After the fix
Once microphone access was granted, SednaPy behaved completely normally. No more instant exits. CPU usage stable. No weird background processes. It was clearly never a core bug in the app.
Which is both comforting and slightly annoying.
Because I lost almost an hour assuming corruption when it was just a privacy setting.
What I’ll do differently next time
If an app crashes instantly on launch and Console shows anything related to TCC, microphone, camera, or screen recording, I won’t waste time reinstalling.
I’ll check Privacy & Security first, or reset the specific permission category.
Reinstalling doesn’t reset macOS privacy decisions. That’s stored at the system level.
Quick checklist for future me
* Check Console immediately for TCC or permission errors.
* Go to Privacy & Security → relevant category (Microphone, Camera, etc.).
* If the app isn’t listed, use `tccutil reset` for that permission.
* Fully quit before relaunching.
* Don’t assume startup crash = broken build.
Anyway, that was my little debugging session. It’s funny how modern macOS problems often look like catastrophic app failures, but they’re really just the OS enforcing boundaries in a slightly unforgiving way.
If SednaPy ever just vanishes on startup for you, it’s probably not haunted. It’s probably just waiting for you to let it use the mic.
Top comments (0)