Document an unsigned preview safely

Sometimes you want feedback on a prebuilt app before paying for the Apple Developer Program. That’s a legitimate stage. There is an honest way to do it and a harmful way, and this lesson is about staying on the honest side.

It starts with labeling. Right next to the download link, say it plainly: this build is unsigned and not notarized. State the source commit it was built from, the build requirements, and what the preview is meant to test. Publish the SHA-256 checksum:

shasum -a 256 Notes-0.9.0-preview.zip

Then document what testers will experience, because you should be the one explaining it — not a confusing error dialog. On first launch, macOS reports it can’t verify the app is free of malware and blocks it. You can see the same verdict yourself:

spctl -a -vv Notes.app

For an unsigned build it prints rejected. That’s Gatekeeper doing its job, not a bug.

Apple provides a per-app override for exactly this situation. The tester tries to open the app once, then goes to System Settings → Privacy & Security, scrolls to the message about the blocked app, and clicks Open Anyway. macOS asks for confirmation, and from then on that one app opens normally.

That flow is deliberately narrow: one user decision, one app, everything else still protected. Which is why the alternatives floating around the internet are unacceptable. Never instruct users to disable Gatekeeper system-wide or to strip the quarantine attribute from downloads with terminal commands. Those recipes turn off protections for everything, to save one click, and they train people to paste security-weakening commands from strangers.

Keep the source-first build instructions published beside the preview, so technical users can build instead of trusting binaries.

And treat friction as a signal. When Open Anyway explanations start filling your support inbox, that’s the moment paid Developer ID signing and notarization pay for themselves.