Listen, I was poking around yesterday with GECO (app) and stumbled into a very classic macOS problem that at first looked like “the app is broken,” but turned out to be way more boring — and way more fixable.

GECO, in case you haven’t used it, is that lightweight utility for controlling laboratory power supplies and measurement devices from macOS. Super handy if you don’t want to script everything manually. I grabbed the build I needed, installed it, launched it… and it just bounced once in the Dock and died. No error dialog. No crash report window. Just silence.

That kind of startup failure is annoying because you don’t even get something to Google.

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

My first instinct was to assume the download was corrupted. I deleted the app, re-downloaded it, verified the archive extracted cleanly, and tried again. Same behavior: bounce, disappear.

Then I thought maybe it was a compatibility thing with my macOS version. So I checked Apple’s notes about app compatibility and system security just to make sure I wasn’t missing something obvious:
https://support.apple.com/en-us/HT201475

Nothing there that screamed “this won’t run.”

After that, I tried launching GECO from Terminal so I could at least see console output:

/Applications/GECO.app/Contents/MacOS/GECO

That finally gave me something useful: a permissions-related error tied to hardware access. That was the real clue.

What I realized

GECO needs access to external hardware — typically via USB or serial interfaces. On modern macOS versions, that means the app may require explicit permissions for things like removable volumes, USB devices, or even Full Disk Access depending on how it’s implemented.

macOS has become increasingly strict about privacy and device access. If an app tries to interact with certain system-level resources without proper entitlements or user-granted permissions, it may simply fail at launch.

Apple documents the privacy permission model here:
https://support.apple.com/en-us/HT210029

Reading through that again reminded me that even development or niche technical apps aren’t automatically trusted just because they’re “serious” tools.

So GECO wasn’t crashing randomly. It was being blocked from accessing something it needed, and instead of gracefully handling that, it just exited.

What actually helped

I went into:

System Settings → Privacy & Security

Then I checked several sections:

  • Full Disk Access
  • Files and Folders
  • Bluetooth (just in case)
  • Removable Volumes

GECO wasn’t listed anywhere, which meant macOS hadn’t even prompted me yet.

So I forced the prompt.

I connected the USB instrument, launched GECO again from Terminal, and this time macOS triggered a permission request dialog for device access. I allowed it.

After that, I manually added GECO to Full Disk Access just to eliminate any remaining restrictions. Restarted the app — and it launched cleanly. No bounce-and-die behavior. Full UI loaded, device detected immediately.

It wasn’t a code bug. It was a silent permission block.

While I was double-checking I had the correct build and not some outdated fork, I found this page useful: https://infoblogz.com/developer/80232-geco-.html. It helped confirm the component identity and saved me from second-guessing the version I was running.

For completeness, I also skimmed Apple’s developer documentation on app sandboxing and hardware access:
https://developer.apple.com/documentation/security/app_sandbox

It’s pretty clear that if an app isn’t perfectly aligned with the current permission model, macOS will not hesitate to block it — even at launch time.

I also checked the Mac App Store search just in case there was a notarized build there:
https://apps.apple.com/us/search?term=GECO

No official App Store distribution, so direct install is the normal route. Which means manual trust and manual permission management are part of the deal.

One subtle thing I almost misdiagnosed

At one point, I thought the issue was Gatekeeper — the classic “cannot be opened because Apple cannot check it for malicious software.” But that wasn’t it. Gatekeeper blocks are loud and obvious. This was different. The app technically launched, but failed internally due to restricted access.

That distinction matters.

If you see a clear Gatekeeper warning, that’s one path. If the app just exits immediately, think permissions or entitlements.

Performance after the fix

Once permissions were granted, GECO behaved completely normally. Stable UI, responsive device polling, no random freezes. I left it connected to a bench supply for a couple of hours running periodic logging, and it didn’t hiccup once.

So again — not instability. Just macOS enforcing modern security rules.

For future reference, here’s the short mental checklist I’m keeping:

  • If the app bounces and quits: try launching from Terminal to see console output.
  • Check Privacy & Security for device and file access permissions.
  • Force a permission prompt by reconnecting hardware and relaunching.
  • Add the app to Full Disk Access if it interacts with external devices or logs.
  • Only after that start suspecting actual bugs.

Honestly, the hardest part was that there was no friendly error dialog. Just silence. And silence makes you assume the worst.

Anyway, if you ever install GECO and it refuses to start on macOS, don’t immediately blame the build. Look at system permissions first. macOS security is strict now, especially around hardware communication, and apps that aren’t distributed through the App Store don’t get automatic trust.

It’s one of those cases where once you understand what’s happening, the fix takes five minutes. But until you see it, you can waste an evening reinstalling perfectly good software.

Edit

Pub: 27 Feb 2026 13:57 UTC

Views: 5