My Sincere Apologies

If you downloaded one of our apps in the last 24 hours and were greeted by this cheerful message from macOS:

“Apple could not verify this software is free of malware that may harm your Mac or compromise your privacy.”

…then I owe you an apology. Your Mac was fine. The app was fine. The only thing that wasn’t fine was my understanding of Apple’s code signing process.

What Happened

Every macOS app distributed outside the App Store needs two things to open without warnings: a Developer ID signature, and notarisation — Apple’s process of scanning the binary and attaching a cryptographic ticket that says “we’ve checked this, it’s not malicious.”

I had the first part (sort of). I was signing builds with an Apple Development certificate, which is the one you use while building and testing on your own machine. It works great in Xcode. It works great on your own Mac. It does not, however, work great on anyone else’s Mac. It’s the software equivalent of a hand-written name badge at a security checkpoint.

What I needed was a Developer ID Application certificate — the proper, notarised, Apple-endorsed ID badge. And for the installer package, I needed its companion, the Developer ID Installer certificate. These are different things. Naturally, I discovered this one certificate at a time.

The Journey

The path to getting here was roughly:

  1. Sign the app. Ship it. Get the Gatekeeper warning.
  2. Google the error. Learn about notarisation. Try to notarise.
  3. Discover I need a different certificate entirely.
  4. Create the certificate. Discover it needs a Certificate Signing Request.
  5. Generate the CSR. Upload it. Download the certificate. Try to install it.
  6. Get told “The System Roots keychain cannot be modified.” Drag it to the correct keychain instead.
  7. Sign and notarise the app. It works.
  8. Try to notarise the installer package. It doesn’t work.
  9. Learn that packages need a different certificate (Developer ID Installer, not Application).
  10. Generate another CSR. Create another certificate. Import another private key.
  11. Sign the package. Notarise it. It works.
  12. Repeat for seven applications.

If this reads like a comedy of errors, that’s because it was. In my defence, Apple’s documentation assumes you already know which of the seventeen types of certificate you need before you start reading the page that explains what they do.

What’s Fixed

Every app on this site has been re-signed with a proper Developer ID certificate, notarised by Apple, and stapled with the verification ticket. You can download any of them and they will open without warnings, without workarounds, without having to right-click and select Open, and without running terminal commands to strip quarantine flags.

The refreshed, notarised releases are available now from their respective GitHub repos:

If you previously downloaded an app and hit the wall, please grab the latest release. This time, it’ll just open. Like software should.

Lesson Learned

Sign properly from day one. Not “it works on my machine” properly — properly properly. Future me will thank past me. And more importantly, future you won’t have to wrestle with Gatekeeper just to try a clipboard manager.

Sorry about that.

Addendum (30 March 2026)

It got worse before it got better.

After publishing the above, I discovered that the signing problems were deeper than wrong certificates. A thorough audit of every app revealed that none of them had their entitlements properly embedded in the signed binaries. Entitlements are the declarations that tell macOS what permissions an app needs — access to your calendar, your camera, the ability to send keystrokes to other apps. The entitlement files existed in the source code. They were referenced in the build configurations. They just weren’t making it into the final product.

The practical consequence: apps that needed permissions simply never asked for them. CalendarUpcoming couldn’t request calendar access. ASCII Saver’s camera agent couldn’t request camera access. ActiveSpace couldn’t switch desktops. The apps would launch, appear to work, and then silently fail at the one thing they were designed to do. No error message. No prompt. Just… nothing.

I also discovered that every app was shipping as Apple Silicon only. If you tried to run any of them on an Intel Mac, they wouldn’t open at all. Given that Intel Macs are still in wide use, this was not a minor oversight.

What I’ve done about it

Every app has been rebuilt as a universal binary (Apple Silicon and Intel), with correct entitlements embedded and verified, proper Developer ID signing, hardened runtime enabled, and full notarisation. But more importantly, I’ve built tooling to make sure this can’t happen again. Every release now goes through an automated pipeline that verifies — at every stage — that the binary is correctly signed, the right certificate was used, hardened runtime is enabled, the expected entitlements are actually present in the signed binary (not just in the source files), and that Apple has accepted the notarisation before anything gets packaged for release.

The pipeline has verification gates. If any check fails, the release stops. No exceptions.

The updated releases

All apps have been re-released. If you downloaded anything before today, please grab the latest version:

I won’t pretend this is the kind of launch experience I wanted. But the software is solid now, the process is robust, and I’ve learned more about Apple’s signing ecosystem in two days than I managed to absorb in the preceding decade. Again — sincerely — sorry.