Test on a clean standard account

Your Mac is the worst place to judge a release. It has your certificates, your Homebrew packages, your granted permissions, and years of preferences. A release that works there proves almost nothing. The boundary that matters is a Mac that has never met you.

The cheap version of that boundary is a clean standard account. Create a new standard (non-admin) user in System Settings, log into it, and act like a customer.

Start from the public URL — the real one, not a local file copy:

curl -LO https://flaviocopes.com/downloads/Notes-1.2.0.zip
shasum -a 256 Notes-1.2.0.zip

Confirm the hash matches what you published. Then extract, and check what Gatekeeper thinks of the result:

ditto -x -k Notes-1.2.0.zip .
spctl -a -vv Notes.app

You want accepted with source=Notarized Developer ID.

Now run the human part of the test. First launch: no scary dialogs beyond the expected permission prompts. Each prompt shows your purpose string and appears at a sensible moment. Create some data, quit, relaunch, and confirm it persisted. Exercise every feature that touches an external dependency.

What makes the clean account powerful is what it lacks. No development certificates. No /opt/homebrew safety net. No privacy permissions you approved months ago and forgot about. Missing dependencies and missing purpose strings that hide on your account fail loudly here.

It has limits, though. The clean account still shares your macOS version and any system-wide software. For releases that matter, repeat the test on a fresh macOS virtual machine or a second Mac.

Close the loop by recording the result: macOS version, architecture, artifact hash, pass or fail, and anything odd. When a user later reports a problem, that record tells you instantly whether they’re hitting something you tested or something new.