Run the complete release checklist

You now have every piece. This lesson chains them into one run, because a release is exactly that: one traceable chain from a commit to a verified download.

Start by freezing. Pick the release commit, set the version and build, and commit that change. From here, everything must come from this state — no “one more quick fix” between archive and upload.

Build and inspect:

xcodebuild -project Notes.xcodeproj -scheme Notes \
  -configuration Release \
  archive -archivePath build/Notes.xcarchive
xcodebuild -exportArchive -archivePath build/Notes.xcarchive \
  -exportOptionsPlist ExportOptions.plist -exportPath build/export

Check the exported app’s version, entitlements, and signing identity before going further. Catching a debug entitlement now costs a minute; catching it after notarization costs a full round trip.

Notarize, staple, then package the stapled app — in that order:

ditto -c -k --sequesterRsrc --keepParent \
  build/export/Notes.app Notes-1.2.0.zip
xcrun notarytool submit Notes-1.2.0.zip \
  --keychain-profile "notes-notary" --wait
xcrun stapler staple build/export/Notes.app

Remember the ordering rule from the stapling lesson: after stapling the app, rebuild the ZIP from the stapled copy so the published archive contains the ticket. Then verify the final artifact:

shasum -a 256 Notes-1.2.0.zip
codesign --verify --deep --strict build/export/Notes.app
spctl -a -vv build/export/Notes.app

For a source-first release, the equivalent chain is shorter but just as real: tag the commit, verify the documented clean build on a fresh checkout, and label any optional unsigned artifact accurately.

Publish the artifact with its checksum, system requirements, release notes, installation steps, data migration notes, and rollback instructions. Then become a user: download from the public URL on a clean standard account and repeat the smoke test.

Finish with the release record: commit, archive path, version, build, artifact hash, signing identity, notarization submission identifier, and test results. The standard you’re aiming for fits in one sentence — for any release, you can answer which source produced the bytes, who signed them, what Apple accepted, and how a user gets back to a working version.