Mac App Signing and Notarization in Plain Words

Short answer

Signing puts your name on the app and shows it has not changed. Notarization sends it to Apple's automated scan. Stapling attaches the result, so it can be checked offline. You do them in that order, and you do them last, after the build is final.

If you have only ever run your app from Xcode, this part of shipping can feel like a wall of certificates. The ideas are simple, and there are only three of them. For the full detail, with Apple's documents linked, read what notarization is on a Mac. This post is the short version for makers.

The three steps

Signing is your name on the app. A Developer ID certificate from Apple says who made it, and the signature shows nothing has changed since. Getting that certificate takes an Apple Developer Program membership, at $99 a year.
Notarization is an automated scan. You upload the signed app, Apple's service looks for malicious content and signing problems, and if it finds none, it issues a ticket. No person at Apple uses your app, and it is not App Review.
Stapling attaches that ticket to your file, so a Mac can check it without going online.

If you sell only through the Mac App Store, you skip the last two. Apple signs store apps, and its documentation says the store process has equivalent security checks.

What your users see if you skip it

They get a warning. macOS says it can't verify the app, and since macOS Sequoia, Control-clicking no longer gets past it. They have to go to System Settings and choose Open Anyway. Some people will give up at that point, and I can't blame them. What "Apple could not verify" means shows the same warning from their side, which is worth reading once.

The order that saves you an afternoon

Finish the build. Anything you change after signing breaks the signature.
Sign the nested code first, such as frameworks and helpers, then the app itself. Use the hardened runtime and a secure timestamp, because notarization requires both.
Put it in a DMG if that's how you ship, and sign that too.
Submit it with notarytool. Apple says scanning usually takes less than an hour.
Read the log, even on success.
Staple it with stapler.

Check your own build

spctl -a -vv /Applications/YourApp.app
xcrun stapler validate /Applications/YourApp.app

You want source=Notarized Developer ID from the first, and a success message from the second. Paste whatever you get into the notarization explainer, and it will say what each line means, or tell you if it doesn't recognize something. It reads the text in your browser and sends nothing anywhere.

Then do the test that catches the most: download your own build through a browser on another Mac or user account, and open it. The launch checklist has this and the other steps in order.

What notarized does not mean

It doesn't mean good, private or safe. It means Apple's automated scan found nothing it knew about. Be careful not to promise more than that on your site. How to tell if a Mac app is safe explains what each check can and cannot prove, from a user's point of view.

What MacPip does with this

MacPip asks for signed and notarized downloads. Open source apps are welcome without it, and their report says so. A blue tick means a person checked the app on the date shown, and signature and notarization appear in the report only when we confirmed them on a downloaded copy. It isn't a safety guarantee, and our rules say so. When your build is ready, you can list it for free.