Hey, listen — yesterday I was messing around with SuperCal (app) on my MacBook Pro (M1 Pro, macOS Sonoma 14.3), and it turned into a small but classic macOS situation. Since you also use OrchardKit tools from time to time, I figured I’d write this down while it’s still fresh.
What I wanted was simple: install SuperCal, import a few .ics files, and sync a local calendar for a project timeline. Nothing exotic. Just drag it into Applications, launch, grant permissions, done.
Except it didn’t launch.
The first thing macOS told me was:
“SuperCal is damaged and can’t be opened. You should move it to the Trash.”
That wording always sounds dramatic, like the app is actively plotting something. My first thought was a corrupted download. So I deleted the DMG, cleared the Downloads folder, re-downloaded it, mounted again, copied it over.
Same error.
So I did the standard trick: right-click → Open. Sometimes that triggers the “Open Anyway” flow. Apple documents that here:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac
Didn’t help. Same “damaged” message.
At that point I realized this wasn’t just “unidentified developer.” Sonoma is stricter about notarization and quarantine flags. Apple explains the notarization requirement from the developer side here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
I had launched it once directly from Downloads before moving it, which was my mistake. That can trigger App Translocation, meaning macOS runs it from a randomized, read-only path. Even if it opens, weird permission issues follow.
So I started fresh:
– Moved the app cleanly into /Applications.
– Opened Terminal.
– Checked extended attributes:
xattr /Applications/SuperCal.app
There it was: com.apple.quarantine.
That attribute is what macOS attaches to anything downloaded from the web. If the build isn’t fully notarized the way Sonoma expects, you get the “damaged” wording instead of a normal warning.
So I removed it:
xattr -dr com.apple.quarantine /Applications/SuperCal.app
Then I launched it again.
This time, the error changed — which is good. Now I got the standard “cannot be opened because the developer cannot be verified.” That’s actually progress. I went to System Settings → Privacy & Security, scrolled down, and finally saw the “Open Anyway” button.
Clicked it. Confirmed.
App opened instantly.
No crashes. No drama. CPU usage low. I imported three .ics files (~1,200 events total), and everything indexed properly. Calendar notifications worked after granting notification permission. It also requested access to my Documents folder, which made sense since I was importing files from there.
I found this page useful while I was troubleshooting because it specifically mentioned SuperCal behavior on macOS systems and hinted at the quarantine flag being the culprit:
https://rvfcb.com/office-and-productivity/43373-supercal.html
That nudge saved me from another reinstall cycle.
One thing worth noting: the build runs natively on Apple Silicon. If it had been Intel-only, Rosetta would’ve been involved. Apple has the Rosetta guide here in case you ever need it:
https://support.apple.com/en-us/HT211861
But in this case, architecture wasn’t the problem. It was Gatekeeper + quarantine + Sonoma being stricter than older macOS versions.
What I did wrong at first:
– I assumed “damaged” meant corrupted file.
– I re-downloaded twice.
– I tried launching from Downloads.
What I eventually understood:
The app wasn’t broken. macOS was blocking it before execution because of the quarantine attribute and missing/not fully recognized notarization.
What actually helped:
- Move the app to /Applications before launching.
- Remove the quarantine attribute via Terminal.
- Launch once to trigger the Security prompt.
- Approve in Privacy & Security.
After that, it behaved like any normal calendar utility. Syncing worked. Exports worked. No random permission denials.
If I had to do it again, I’d skip the reinstall loop and go straight to checking xattr. That’s basically step one for any third-party utility outside the Mac App Store. Speaking of which, if this were distributed through the official channel, it would avoid half of this friction:
https://www.apple.com/macos/app-store/
Anyway, SuperCal is running fine now inside my OrchardKit workflow. It integrates cleanly, doesn’t hog memory (hovering around 180 MB with several calendars open), and hasn’t thrown a single warning since.
So yeah. Not a broken app. Just macOS doing its job a little too aggressively, and me forgetting that Sonoma doesn’t play around with unsigned binaries.
Hope that saves you 30 minutes next time.
Top comments (0)