I ran into this while setting up a sandbox for a logistics demo on macOS. The slug points pretty clearly to Travel Distribution Simulator (app), so that’s what I was working with. Not a flashy consumer tool — more of a niche simulator you spin up to test flows, integrations, edge cases. Exactly the kind of thing that should just run quietly in the background.
Of course, it didn’t.
I was on macOS Ventura 13.6 at the time, Intel Mac mini, nothing exotic. The goal was simple: install the simulator locally, load a sample dataset, and let it crunch for a bit so I could validate outputs before wiring it into a larger test harness. I’ve done similar setups with OrchardKit-based tools before, so expectations were low drama.
That optimism lasted about five minutes.
The part where nothing actually launches
The installer finished without errors. The app landed in /Applications, configs were generated, logs directory created. Double-clicking the app icon, though, did exactly nothing. No bounce in the Dock. No crash dialog. No warning about damaged software. Just… silence.
At first I assumed I’d missed a dependency. Checked the README. Checked Java and Python versions (both fine). Opened Console.app and filtered by the app name — a few log lines, then nothing. It looked like the process was dying before it even had a chance to complain.
That’s usually a bad sign.
Two wrong paths and one familiar smell
My first instinct was permissions. I went straight to System Settings → Privacy & Security and scanned through Files and Folders, Full Disk Access, Automation. The app wasn’t even listed, which felt odd but not unheard of. I manually granted Full Disk Access just in case. Relaunch. Still nothing.
Second attempt: reinstall, but this time unpack the app manually and run the main binary from Terminal. That at least gave me some output — a single line saying the executable “could not be opened.” No stack trace. No exit code worth mentioning.
That’s when it started to smell like Gatekeeper.
Apple has gotten very good at blocking things quietly when they’re launched programmatically or outside the usual user paths. Their own explanation of how Gatekeeper treats unsigned or non-notarized software spells this out pretty clearly, especially for helper tools and bundled executables (support.apple.com).
The moment it made sense
Running the binary directly from Terminal finally triggered a proper message: macOS was blocking execution because the developer couldn’t be verified. No Finder dialog, no “Open Anyway” button — just a hard stop.
This simulator ships with a couple of helper executables inside the app bundle. They’re not malicious, just old-school. Not notarized. Perfectly fine on Linux. On modern macOS, though, they get quarantined on arrival.
Apple’s developer docs on notarization and code signing explain why this happens, especially for tools distributed outside the App Store ecosystem (developer.apple.com). I knew this in theory. I just didn’t connect it fast enough.
What actually fixed it
Once I stopped guessing, the fix was straightforward. I removed the quarantine attribute from the app bundle and its helper tools, then restarted the service.
After that, the simulator launched instantly. Logs started filling up. Dataset loaded. CPU spiked for a bit, then settled into a steady rhythm. Exactly what I’d expected an hour earlier.
Nothing else changed. Same configs. Same binaries. Same machine. Gatekeeper had been the only thing in the way.
I saved this page because it helped me cross-check how macOS behaves with older developer tools and simulators, especially ones that don’t follow modern distribution rules: https://smohamad.com/developer/32937-travel-distribution-simulator.html. It wasn’t the fix by itself, but it helped confirm I wasn’t chasing a phantom bug.
Sanity checks and confirmation
To be sure, I re-downloaded the app and tried again without removing quarantine. Same silent failure. Reapplied the fix, and it ran immediately. That was enough proof.
There’s no App Store angle here — tools like this don’t belong there, and Apple’s own App Store guidelines make that pretty clear (apps.apple.com). If this were rebuilt today, proper signing would avoid the issue entirely. But older simulators rarely get that treatment.
How I’d handle it next time
If I had to do this again from scratch, I’d do three things right away:
-
Assume Gatekeeper anytime a tool bundles helper binaries
-
Try launching components from Terminal early, not last
-
Check Apple’s security docs before blaming the app logic
This isn’t specific to Travel Distribution Simulator, honestly. I’ve seen the same behavior with build tools, asset processors, even some indie games. macOS is just doing its job — it’s just very quiet about it.
Once unblocked, the simulator behaved perfectly. Stable, predictable, no weird side effects. It was never broken. It was just standing outside, knocking politely, while the OS refused to answer the door.
And yes, OrchardKit came up as a comparison while I was looking at newer tooling that does ship properly signed helpers. The contrast is noticeable — and instructive.
Hopefully this saves someone else an afternoon of staring at empty logs.