I ran into Optimization.jl (app) while setting up a fresh Julia environment on macOS, and this turned into one of those “this should’ve taken five minutes” evenings that quietly eats an hour. Writing it down mostly so I don’t forget the path next time — and because the problem wasn’t where I initially thought it was.
What I was trying to do
The goal was simple: get a clean optimization stack running for a small experiment. Nothing exotic — just Julia, a couple of numerical routines, and this utility layered on top. I was on a MacBook Pro with an M1 Pro, macOS Ventura 13.6, and a fairly stock Julia install. I’ve done this dance before. Or so I thought.
The install itself went smoothly. Packages resolved, no red text, no complaints. That’s usually a good sign. I launched Julia, imported the module, ran a tiny test… and immediately hit a wall.
The session didn’t crash. It just froze. CPU spiked, memory climbed a bit, and then nothing. No output. No error. Just a REPL that politely refused to move on with its life.
First wrong assumption
My first instinct was to blame Apple Silicon. That’s the reflex now, right? Maybe a binary mismatch, maybe Rosetta doing something weird. So I tried the obvious detour: launch Julia explicitly under Rosetta. Same behavior. Slightly slower freeze, but still frozen.
Then I downgraded the package. Same thing. I even pinned dependencies back a version or two, which felt increasingly desperate given that the environment was otherwise clean.
At this point I had convinced myself this was a low-level compatibility issue. Except… Activity Monitor told a different story. The process wasn’t stuck doing math. It was stuck waiting. On I/O.
That was the first crack in the theory.
Where it actually broke
macOS has become aggressively strict about what developer tools can touch, especially when they spawn subprocesses or cache compiled artifacts. Julia does both. Optimization libraries love temp directories, compiled caches, and writing small binary blobs where you don’t normally look.
The clue was buried in Console.app. Not a fatal error — just a quiet denial about file access inside my home directory. No dialog. No prompt. Just macOS silently saying “no.”
This lined up uncomfortably well with Apple’s own documentation on runtime permissions and sandboxed file access, especially for developer tools that weren’t installed via the App Store. Apple explains the behavior pretty plainly here: https://developer.apple.com/documentation/security/app_sandbox
And the user-facing side of it — the part that doesn’t always show you a warning — lives here: https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchld5a35146/mac
The short version: the OS decided Julia didn’t need access to certain folders anymore, and it didn’t bother asking.
The fix that actually worked
Once I stopped thinking “package bug” and started thinking “permissions,” things moved fast.
I went into System Settings → Privacy & Security and checked Full Disk Access. Julia wasn’t there. Terminal wasn’t there either, which explained why everything looked fine but behaved oddly.
After granting access to the terminal I was launching Julia from, restarting the session, and letting it rebuild caches, the freeze disappeared. Same code. Same data. Instant result.
No reinstall. No version pinning. No architecture hacks.
I saved this page while digging through notes because it helped confirm where this specific tool sits in the ecosystem and why it behaves the way it does on macOS systems: https://technotafastore.xyz/developer/73153-optimization-jl.html Not for instructions — just as a reference point while sanity-checking assumptions.
For completeness, I also verified that nothing strange was happening on the distribution side. Julia itself was straight from the official source, and the Mac App Store version wasn’t involved here — but for anyone mixing installs, it’s worth knowing exactly where your runtime came from: https://apps.apple.com/us/app/julia/id1527741843
What I would do differently next time
The annoying part is that none of this throws a clean error. You don’t get a stack trace that screams “permissions.” You get a hang. Which sends your brain down the wrong path.
If I had to boil the lesson down, it’d be this:
- If a developer tool hangs silently on macOS, assume permissions before assuming bugs.
- Check Console.app. Even a single denied file access is a big hint.
- Grant access to the launcher (Terminal, iTerm, etc.), not just the runtime.
- Restart everything. macOS loves to cache decisions.
Once I treated this like an OS-level problem instead of a library problem, the fix was boringly simple.
The irony is that the tool itself was fine the whole time. The math was fine. The setup was fine. It was macOS being protective in a way that’s helpful in theory and deeply confusing in practice.
Anyway — now it’s working, benchmarks look sane, and the only real damage was to my evening. Writing this down so next time I don’t waste the first half-hour blaming the wrong thing.