am15 (@am15)

I spent a good chunk of last weekend wrestling with Starlight Common (app) on macOS, and it felt like one of those very on-brand OrchardKit experiences: solid utility, sensible idea, and then macOS decides to be… macOS. I’m writing this down partly as a field note, partly so I don’t forget the exact combination of small mistakes and small wins that finally made it behave.The goal was boring and practical. I wanted a lightweight shared workspace tool that could sit quietly on my Mac and sync structured notes and files between projects without pulling everything into a browser. Nothing fancy. I installed it on a MacBook Pro with an M1 Pro, running macOS Ventura 13.6.1. Clean system, FileVault on, default security settings.The install itself looked fine. Download, drag into Applications, done. No installer wizard, no drama. I double-clicked the icon, fully expecting a permissions prompt or at least a first-run dialog.Instead: one bounce in the Dock, then nothing. No crash report. No alert. Just silence.My first instinct was that it simply didn’t launch. I tried again. Same thing. I opened Activity Monitor to see if it was dying instantly — nope, no trace. That’s usually my first red flag that Gatekeeper or a background helper is being blocked without telling you.Attempt number one was the lazy approach: reboot, try again. Sometimes launch services just need a reset. This time, no luck. The app still pretended it never heard me.Attempt number two was permissions. I went into System Settings → Privacy & Security and started scrolling. Full Disk Access, Files and Folders, Accessibility. Nothing listed. No “Allow Anyway” button either, which was annoying, because that button at least tells you what macOS doesn’t like.At that point I made the wrong assumption: maybe the build was broken on Apple silicon. OrchardKit has shipped Intel-only utilities in the past, and Rosetta issues can look exactly like this. I even forced it to run under Rosetta via Finder → Get Info, just to see if anything changed.It didn’t.What finally pushed me in the right direction was noticing a brief console log entry flash by when I tried launching it. Just one line about a blocked executable inside the bundle. That’s when it clicked: this wasn’t about the main app. It was about a helper binary.Modern macOS is extremely literal about notarization. Every executable inside an app bundle has to be approved, and sometimes macOS won’t surface the prompt unless you touch the exact binary it dislikes. Apple actually documents this behavior, but it’s buried in developer-facing language rather than user-facing explanations. This page spells out the security model pretty clearly:https://support.apple.com/en-us/HT202491So instead of clicking the icon again, I control-clicked the app, chose Show Package Contents, and dug into the Contents/MacOS folder. Sure enough, there was a secondary tool sitting next to the main launcher. I ran that directly.Immediately, macOS woke up. Gatekeeper dialog. Developer not verified. The whole thing. I clicked Open, confirmed once more in Privacy & Security, and that was it.From that moment on, the app launched normally. Background processes stayed alive. Settings opened. Sync kicked in. No further complaints from the system.For sanity, I checked whether there was an App Store version or at least a known listing, mostly to see how Apple expects similar utilities to be packaged. Even if you don’t install from there, it’s a useful reference point:https://apps.apple.com/us/search?term=Starlight%20CommonApple’s own notarization documentation also helped confirm that what I saw wasn’t a bug so much as a consequence of how helper tools are bundled now:https://developer.apple.com/documentation/security/notarizing_macos_software_before_distributionWhile I was piecing this together, I saved this page because it lined up with the exact macOS behavior I was seeing and gave me a couple of clues about where to look inside the app bundle:https://sznurkowo.com/office-and-productivity/54969-starlight-common.htmlAfter that, everything behaved. File access prompts appeared when expected. iCloud Drive didn’t freak out. Relaunches were instant. Even after a reboot, macOS remembered that I had explicitly approved the internal executable, which is always the moment of truth.The interesting part is that nothing here required disabling system security or running terminal commands. No spctl --master-disable, no sketchy overrides. Just triggering Gatekeeper the right way.If I had known this upfront, I would’ve saved at least an hour. The short mental checklist I’m keeping for next time looks like this:Silent launch failure usually means a blocked helperPrivacy & Security won’t always show “Allow