Publish checksums and release notes

Two small things separate a professional release from a bare file link: an integrity checksum and honest release notes.

The SHA-256 checksum is a fingerprint of the exact bytes you published. Compute it from the final file — the one you actually upload, after any re-zipping or renaming:

shasum -a 256 Notes-1.2.0.zip

Publish the filename and the hash right next to the download link. A user (or your future self) verifies a download by recomputing it:

shasum -a 256 ~/Downloads/Notes-1.2.0.zip

The two hex strings must match exactly. A mismatch means the bytes differ — a corrupted download, a stale mirror, or a tampered file — and the right response is to not run it.

Be clear about what a checksum is and isn’t. It detects corruption and lets careful users confirm they received what you published. It does not establish who you are — that’s the job of code signing. You want both.

The sneaky failure: you compute the hash, then notice a typo in the filename, re-create the archive, and upload the new one. Compression timestamps differ, so the published hash no longer matches the published file — and every careful user now thinks your release is compromised. Hash last, upload immediately, then verify the uploaded file once more.

Release notes are the other half. State the version and build, the minimum macOS version, supported architectures, what changed, what you fixed, any data migrations, and known issues. “Bug fixes and improvements” helps nobody.

If you offer multiple artifacts, write separate installation instructions for each: source builds, the signed and notarized download, and any unsigned preview. Never blur the line between them — an unsigned artifact must never be described in a way that implies Apple notarized it.