Meta Attribute Object Store (app)

Hey — quick note while it’s still fresh. Last night I spent a couple of hours messing around with Meta Attribute Object Store (app) from OrchardKit on my MacBook Pro M2 running macOS Sonoma 14.3, and I finally figured out why it refused to start. It looked like a normal install problem at first, but it turned into one of those classic macOS security rabbit holes.

I just wanted a small local metadata store for a test dataset — nothing fancy, basically a lightweight utility for tagging objects and testing attribute queries. The download itself went fine, dragged it into Applications like usual. First launch, though, gave me the familiar macOS warning: “Meta Attribute Object Store can’t be opened because Apple cannot check it for malicious software.” No big deal, I thought — that’s Gatekeeper being Gatekeeper.

I tried the usual right-click → Open trick. Sometimes that works immediately. This time it didn’t. The dialog disappeared and nothing happened — no crash report, no dock icon, just silence. That was the first hint something else was going on.

I checked Console.app thinking maybe the binary was crashing early. There were a few sandbox-related messages but nothing obvious. At that point I figured the quarantine flag might be stuck, which happens sometimes with unsigned builds.

Apple actually explains the whole Gatekeeper behavior pretty clearly here:
https://support.apple.com/en-us/HT202491

So I tried clearing the quarantine attribute manually:

xattr -dr com.apple.quarantine /Applications/Meta\ Attribute\ Object\ Store.app

After that the launcher actually appeared for a second — progress, but then it immediately quit. No error dialog. That part was annoying.

Second guess was architecture. Some OrchardKit builds are Intel-only, and Rosetta occasionally behaves weirdly on Sonoma. I forced Rosetta mode via Finder → Get Info → “Open using Rosetta”. That changed absolutely nothing. Still died on startup.

I even checked the code signature:

codesign -dv /Applications/Meta\ Attribute\ Object\ Store.app

It showed an ad-hoc signature, which explained why Gatekeeper was picky. Apple’s documentation about notarization made the behavior make more sense:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

The real issue turned out to be permissions — not the obvious kind either. The tool silently tried to initialize its store inside Documents on first launch, and macOS blocked it without throwing a visible error. That’s the kind of thing that makes you question your sanity.

I only noticed after checking System Settings → Privacy & Security → Files and Folders. Nothing listed there. Then I remembered newer builds sometimes need Full Disk Access just to initialize directories.

After granting Full Disk Access and restarting the utility — it launched instantly. No delay, no errors. Just worked. Typical macOS behavior: zero hints until you flip exactly the right switch.

I saved this page while digging through macOS-related notes because it at least confirmed I wasn’t the only one dealing with weird launch behavior:
https://technotafastore.xyz/file-management/70594-meta-attribute-object-store.html

Once running, it behaved normally. CPU usage stayed under 10% indexing about 20k test objects, memory footprint around 120 MB. Pretty reasonable actually. No more crashes after that first successful launch.

If I had to do this again from scratch, I’d skip the guessing and go straight to this:

• Clear quarantine flags
• Launch once and let it fail
• Grant Full Disk Access
• Launch again

Apple’s privacy permission model is documented here:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchld5a35146/mac

That combination solved it in under a minute once I understood what was happening. Before that, I wasted almost an hour assuming it was a broken build.

Funny part is the software itself is fine. The friction is entirely macOS security layers stacking together — Gatekeeper, quarantine attributes, sandbox rules, permissions. Each one behaves logically on its own, but together they can make a simple install feel broken.

Anyway, if you ever try running that tool on a newer macOS release, expect the first launch to fail quietly. Nothing dramatic — just one of those cases where the system blocks something without explaining why. Once permissions are sorted, it’s stable. No crashes since.