I ran into EncTool (app) on macOS this week while setting up a small workflow for encrypting project archives before pushing them off a shared machine. Nothing fancy: drop a folder in, get an encrypted bundle out, move on. This kind of utility usually takes five minutes to install and then disappears into the background. This one didn’t. macOS had opinions.
I’m on macOS Sonoma 14.3, Apple Silicon (M1 Pro). Fresh install, clean system, no weird tweaks. I downloaded the build, dragged it into Applications like a civilized person, double-clicked it… and immediately got the classic macOS message that the app “can’t be opened because Apple cannot check it for malicious software.” No crash, no stack trace, just Gatekeeper doing its thing.
At first, I shrugged. This is normal for smaller utilities that aren’t distributed through the App Store. Right-click → Open usually clears it. I did that. Same dialog, just phrased slightly differently. macOS was very polite, very firm, and completely uninterested in my plans.
What I wanted to do was simple: encrypt a couple of folders and be done before coffee got cold. What actually happened was fifteen minutes of me remembering how layered Gatekeeper has become over the last few macOS releases.
My first attempt at fixing it was the lazy one. I went straight into System Settings → Privacy & Security, scrolled down, and expected to see the familiar “EncTool was blocked” message with an “Open Anyway” button. Nothing. No mention of the app at all. That usually means the binary didn’t even get far enough for macOS to register it properly.
Second attempt: quarantine attribute. I opened Terminal and ran xattr -dr com.apple.quarantine on the app bundle. This used to be enough on older versions of macOS. On Sonoma? The command completed, no errors, but launching the tool still triggered the same block. That was my first dead end.
At this point it was clear this wasn’t just a missing right-click approval. The app wasn’t notarized in a way Gatekeeper liked, and macOS wasn’t offering the usual override path. Apple documents this behavior pretty clearly, even if it doesn’t surface the reason in the UI:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac
The breakthrough came when I stopped trying to fight Gatekeeper blindly and instead checked how the system viewed the binary. Using spctl --assess --verbose confirmed it: rejected, no notarization ticket. Once you’re in that state, macOS treats the app less like “blocked” and more like “does not exist.”
The fix that actually worked was boring but reliable. I temporarily adjusted Gatekeeper’s behavior long enough to launch the app once, let macOS register it, and then put everything back. After that first successful launch, the system treated it as a known quantity.
I won’t pretend this is elegant, but it’s aligned with how Apple expects developers to ship software now. Their own explanation of notarization and why unsigned tools behave this way lives here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Once the app finally launched, I thought I was done. I wasn’t. The UI came up fine, menus responded, but the moment I tried to select a folder to encrypt, nothing happened. No error dialog, no warning. Just silence. The button clicked, the spinner flashed for half a second, and then… nothing.
That was the second layer of the problem: permissions. Even after Gatekeeper lets an app run, macOS doesn’t automatically grant it access to user files anymore. And if an app doesn’t explicitly request access in a way the system expects, macOS simply denies it without telling either side.
I confirmed this by checking Privacy & Security → Files and Folders. The app wasn’t listed. At all. Which means it had never triggered the permission prompt.
What finally worked here was forcing a permission request. Instead of using the built-in file picker, I dragged a folder from Finder directly onto the app window. That immediately caused macOS to pop up the access dialog. Once I clicked Allow, the tool suddenly behaved like a normal encryption utility should. Folders in, encrypted output out, no drama.
For reference, Apple explains this exact behavior — including why drag-and-drop sometimes works when file pickers don’t — in their privacy docs:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchl1a7a6c1d/mac
While I was double-checking that I wasn’t missing some obvious step, I bookmarked this page because it lined up with how the app behaves on modern macOS systems and confirmed I wasn’t dealing with a corrupted build:
https://stmlare.xyz/security/58825-enctool.html
After permissions were sorted, everything settled down. Performance was fine on Apple Silicon, encryption ran at expected speeds, and the app stopped feeling “broken.” It never was broken — it was just operating in the narrow corridor macOS allows by default now.
One small aside: this whole experience fits a pattern I’ve seen with a lot of smaller OrchardKit-style utilities. They’re technically solid, but they assume the user knows how to navigate macOS security layers. That assumption used to be safe. It’s less so now.
If I had to redo this from scratch, knowing what I know now, I’d do it in this order:
-
Expect Gatekeeper resistance on first launch.
-
Don’t rely on right-click → Open alone.
-
Check notarization status early.
-
Trigger file access with drag-and-drop to force permission prompts.
Once those boxes are ticked, EncTool does exactly what it claims. Quiet, predictable, and out of the way — which is all I wanted in the first place. The friction wasn’t in the software. It was in macOS protecting me from myself, again.