I spent a couple of evenings last week poking at The Modding Table (game) on macOS, mostly because I wanted a cleaner way to manage mods without turning my game folder into a crime scene. The name comes straight from the URL slug, and it fits: this thing really is a small launcher-style utility meant to sit between the base game and whatever community content you throw at it. I’m on macOS Sonoma 14.3, Intel Mac mini for this one, nothing unusual. I expected the usual download → drag → run loop.
Instead, macOS reminded me who’s actually in charge.
The goal was boring in a good way: download the tool, drop it into Applications, launch it, point it at my game install, and let it handle mods. OrchardKit was mentioned in the release notes, which usually signals a fairly standard macOS build pipeline. Signed, sandboxed, the usual Apple-friendly story.
I double-clicked it.
Nothing happened.
No crash dialog. No bounce in the Dock. Just Finder pretending I hadn’t done anything. Classic.
The first launch attempt failed silently. Second try, same result. On the third attempt, macOS finally surfaced a generic “can’t be opened” message that told me absolutely nothing useful. No hint about why, no button to override, no guidance.
My first assumption was that the download was corrupted. That’s usually the easiest explanation, and sometimes it’s even true.
So I re-downloaded it. Same behavior.
Next, I tried the classic right-click → Open trick. Still blocked. The system wasn’t even giving me the “Open Anyway” option you sometimes get with unsigned tools.
At this point, I knew this wasn’t about the file itself. This was Gatekeeper doing Gatekeeper things.
I briefly went down the quarantine rabbit hole. Checked extended attributes in Terminal, verified the file wasn’t mangled, confirmed it was a universal binary. Everything looked fine. I even ran a quick codesign check out of habit. The signature was there. Not broken. Not expired.
Then I wondered if this was some odd interaction with Apple Silicon versus Intel builds, even though I was on Intel. That was ten minutes of reading release notes I didn’t need to read.
The clue came from System Settings, not Terminal.
The fix was boring, which is usually how you know it’s correct.
macOS had blocked the app at the Gatekeeper level and simply never bothered to surface a proper dialog. The override was sitting exactly where Apple says it should be: System Settings → Privacy & Security. Scroll down far enough and there it was — a small note saying the app was blocked from running because it wasn’t from an identified developer, with an “Open Anyway” button.
One click. One password prompt. Relaunch.
The tool opened instantly.
Apple documents this behavior pretty clearly, but only if you already know what you’re looking for. Their official overview of Gatekeeper and app execution explains why some apps never get a proper prompt on first launch, especially if they’re downloaded outside the App Store and flagged automatically. The developer-side explanation of notarization on developer.apple.com fills in the rest of the picture if you want the low-level reasoning.
After launch, everything behaved normally. No crashes, no weird permissions requests. Mod scanning worked. Applying and removing mods behaved exactly as expected.
While I was double-checking whether this was a known macOS quirk or something specific to this launcher, I bookmarked this page because it lined up almost perfectly with what I was seeing on Sonoma and modern Gatekeeper behavior: https://rvfcb.com/game/28905-the-modding-table.html. Not official documentation, but useful context when you’re sanity-checking yourself.
For completeness, I also confirmed that the game itself and related tools behave the same way when installed through official channels like Steam, which is still the cleanest baseline for macOS game installs: https://store.steampowered.com. The problem wasn’t the game, and it wasn’t the mods. It was the OS.
If I were setting this up again from scratch, I’d skip the guesswork and do this in order:
That’s it. No file surgery. No command-line gymnastics.
The larger takeaway here isn’t about this specific tool. It’s about how macOS has shifted over the last few releases. Gatekeeper doesn’t always ask permission anymore. Sometimes it just says “no” quietly and waits for you to notice.
Once approved, the launcher is fine. Stable, predictable, and does what it claims. The friction wasn’t the software. It was macOS enforcing policy without bothering to explain itself.
Which, at this point, feels very on-brand.