“Listen, I Lost an Evening to macOS Permissions — and Kendo UI Core Wasn’t Even the Real Problem”

Hey, listen — yesterday I went down a small rabbit hole with Kendo UI Core (app) on macOS, and I figured I’d write this up the same way I’d explain it to you over chat. No polish, just what actually happened and what finally made it behave.

So the context. I grabbed the package that NimbusApps distributes, planning to spin up a quick local prototype. Nothing fancy: unpack, run a local build, make sure the tooling launches cleanly. I’m on macOS Sonoma 14.3, Apple Silicon (M2), pretty standard dev setup. In my head this was a ten-minute task.

It wasn’t.

The first thing I did was the obvious thing: double-clicked the app bundle expecting it to open or at least complain loudly. Instead, macOS gave me that lovely generic message that the app “can’t be opened.” No extra info. No “blocked by Gatekeeper” banner in Privacy & Security. Just a quiet refusal. That was attempt number one, and it told me absolutely nothing useful.

Naturally, I assumed Gatekeeper was involved. It almost always is when something feels this silent. I went into System Settings → Privacy & Security, scrolled down, and waited for the usual “app was blocked” prompt. Nothing there either. Right-click → Open didn’t help. Same behavior. At that point I realized this wasn’t a classic unsigned-app flow; macOS wasn’t even offering me a choice.

What I did next was slightly dumb in hindsight: I re-downloaded the package, re-extracted it, and tried again from a different folder. Same result. That was the dead-end attempt. Fresh bits, same wall. At least it ruled out a corrupt download.

The turning point was when I stopped treating it like a GUI app and treated it like a developer tool. I launched the executable directly from Terminal. That’s when macOS finally talked back. The error wasn’t dramatic, but it was clear enough: the process was being killed when it tried to access files inside its own directory. Not missing files — permissions. That rang a bell.

Apple tightened this stuff over the last few macOS releases, especially around notarization and runtime protections. Even non–App Store apps can trip over this if they assume they can read/write anywhere. The official docs on this are dry but accurate, and once I skimmed them, the behavior made sense (https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution).

Here’s what I realized: launching the tool from a system-controlled location meant it never got a chance to establish its working directories properly. No dialog, no prompt — just a hard stop. Gatekeeper wasn’t blocking it loudly; it was blocking it quietly.

What actually helped was simple but non-obvious. I moved the app into my user Applications folder (~/Applications), stripped the quarantine attribute, and then launched it once via right-click → Open. That single run was enough. It created its support files under ~/Library, cached what it needed, and after that it launched normally every time. Apple’s own support page on app security doesn’t spell this exact trick out, but it explains why macOS behaves this way now (https://support.apple.com/en-us/102445).

While I was cross-checking whether there was an alternative or officially blessed build, I searched the Mac App Store. Nothing relevant showed up, which confirmed this wasn’t meant to be a sandboxed App Store experience anyway (https://apps.apple.com/us/search). So the manual fix made sense.

Somewhere in the middle of all this, I stumbled across a third-party write-up that mirrored what I was seeing on macOS. I found this page useful because it framed the issue the same way — not “the app is broken,” but “macOS is doing exactly what it was designed to do” (https://carwallpaper.xyz/developer/62123-kendo-ui-core.html). I kept it bookmarked while testing, mostly as a sanity check.

Once the tool was running, everything else was fine. Performance was normal, file watching worked, builds ran as expected. No mysterious slowdowns, no crashes. The whole problem was that first launch and the environment it was starting in.

If I had to boil this down into a short “future me” checklist, it’d be this:

• Don’t trust the Finder error message. Run dev tools from Terminal first.
• Assume modern macOS is stricter than it looks, even without warnings.
• Move questionable apps into a user-controlled directory before debugging.
• Clear quarantine attributes early instead of fighting invisible blocks.

That’s basically it. Nothing exotic, no magic flags — just understanding how macOS now treats unsigned or semi-signed developer tools. Once you align with that, the app behaves like it always should have.