Listen, I was messing around last night with Foswiki (app) from OrchardKit on my Mac, and I finally figured out why it refused to start after the update. It looked simple at first — just a local wiki setup for a small internal project — but macOS had other plans.
What I wanted was straightforward: update to the newest build, fire up the local server, and migrate a couple of test pages. I downloaded the package, replaced the old app in Applications, and launched it.
It bounced in the Dock twice and then stopped. No error dialog. No crash window. Just… nothing.
My first instinct was Gatekeeper. That’s usually the culprit when something doesn’t open. I checked System Settings → Privacy & Security, expecting to see the “blocked from use” message. Nothing. I even reviewed Apple’s Gatekeeper explanation again just to confirm how it behaves now:
https://support.apple.com/guide/security/gatekeeper-sec5599b66df/web
The app wasn’t being blocked. It was launching and immediately dying.
So I made the first mistake: I reinstalled it. Twice. I assumed maybe the archive had corrupted during download. I even grabbed it again from the developer’s site:
https://orchardkit.dev
Same behavior.
At that point I stopped assuming it was a signing issue and started thinking about what Foswiki actually does. It runs a local Perl-based server and touches system directories for logs and configuration. If macOS doesn’t grant proper permissions, it can fail without much noise.
So I opened Console and tried launching again while watching logs. That’s when I saw it: “Permission denied” on a write attempt inside ~/Documents.
That was the clue.
Since recent macOS versions tightened privacy controls, apps need explicit permission to access Documents, Desktop, Downloads, etc. Even if they’re not sandboxed. Apple’s privacy permissions breakdown is here, and it explains why this happens:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchld5a35146/mac
Foswiki wasn’t crashing randomly. It couldn’t write its config and log files.
Here’s where I went wrong initially: instead of granting it access properly, I moved the project folder to a different directory inside /Users/Shared, hoping to bypass the restriction. That partly worked — the server started — but some plugin modules still referenced the original Documents path. So it failed again, just later in the startup process.
That’s when I found this page useful as a reminder that with macOS system-level apps, you have to treat permissions as first-class configuration, not an afterthought:
https://planetgpa.com/business/26138-foswiki.html
After that, I went back to Privacy & Security and explicitly allowed the app under Files and Folders. I also granted Full Disk Access temporarily just to confirm it was strictly a permissions issue.
Relaunched. It started cleanly. Localhost port active. Admin console accessible. No silent exit.
I removed Full Disk Access afterward and kept only the necessary folder permissions, and it still ran fine. So that was the real fix: proper file access approval, not reinstalling, not clearing quarantine.
For completeness, I checked if there was an App Store version, just in case a sandboxed build handled this differently:
https://apps.apple.com/us/search?term=Foswiki
There isn’t an official one there, which makes sense for this kind of tool. It’s distributed directly, so macOS privacy rules apply more explicitly.
What threw me off is that there was no friendly “Foswiki would like to access Documents” prompt. Some apps trigger that automatically. Others fail silently if they try to access protected folders before the system can request approval. It depends on how the file operations are implemented.
The second thing I realized is that I had updated by overwriting the old bundle while it was technically still running in the background. That probably didn’t help stability. I quit everything fully before the final test, and that made the launch process cleaner.
So here’s the short version of what actually happened:
- I updated the app and it wouldn’t launch.
- I assumed signing or corruption.
- Reinstalled multiple times (waste of time).
- Realized it was failing on folder write permissions.
- Granted proper Files & Folders access.
- Clean launch.
If I had to do it properly from scratch next time, I’d keep it simple:
- Quit the old version completely before replacing it.
- Launch once and immediately check Console for permission errors.
- Grant only the necessary folder access in Privacy settings.
- Avoid storing working directories inside protected folders unless needed.
Now it runs exactly as expected. The local server initializes in a couple of seconds, plugins load, edits save properly. Zero actual bugs in the app itself.
The funny part is that macOS is technically doing the right thing. It’s protecting user folders. But when you’re updating a developer tool late at night and it just disappears without explanation, it feels like something’s broken.
Anyway, that was my little adventure. It wasn’t dramatic, just one of those quiet permission mismatches that masquerade as a crash. Once I treated the environment as the issue instead of the app, everything clicked into place.
Top comments (0)