Release WisprDuck

Build a signed, notarized, and stapled .app, then publish it as a GitHub release.

Target version: $ARGUMENTS

Pre-flight

1. Confirm the working tree is clean (git status). Abort if there are uncommitted changes.
2. Check whether $ARGUMENTS already has a git tag or GitHub release.
   • If it does not exist, proceed normally.
   • If it already exists and the user explicitly asked to overwrite/re-release, run the re-release cleanup before continuing:

     bash
     1gh release delete v$ARGUMENTS --repo kalepail/wispr-duck --yes --cleanup-tag
     2git tag -d v$ARGUMENTS 2>/dev/null || true

   • If it already exists and the user did not ask to overwrite, abort and ask for confirmation.
3. If not on main, merge the current branch into main and switch to it:

   git checkout main
   git merge <branch> --no-edit
   

Step 1 — Bump version numbers

Update all of the following to $ARGUMENTS:

MARKETING_VERSION uses Xcode's short version format (e.g., 1.4 not 1.4.0). The other files use full semver.

Do not touch CURRENT_PROJECT_VERSION (build number) — leave it as-is.

After updating, verify with grep that no stale version strings remain in those files.

Step 2 — Commit and push

git add WisprDuck.xcodeproj/project.pbxproj site/index.html site/package.json
git commit -m "Bump version to $ARGUMENTS"
git push origin main

Step 3 — Archive

Run as a single line (multiline backslash escaping can break in some shell environments):

bash
1xcodebuild archive -project WisprDuck.xcodeproj -scheme WisprDuck -configuration Release -archivePath /tmp/WisprDuck.xcarchive "CODE_SIGN_IDENTITY=Developer ID Application: Tiny Anvil, LLC (T4GBHCYB7P)" DEVELOPMENT_TEAM=T4GBHCYB7P CODE_SIGN_STYLE=Manual

Note: CODE_SIGN_IDENTITY must be quoted because the value contains spaces and a comma.

Confirm output ends with ** ARCHIVE SUCCEEDED **.

Step 4 — Export

Write this ExportOptions.plist to /tmp:

xml
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
3<plist version="1.0">
4<dict>
5  <key>method</key>
6  <string>developer-id</string>
7  <key>teamID</key>
8  <string>T4GBHCYB7P</string>
9  <key>signingStyle</key>
10  <string>manual</string>
11  <key>signingCertificate</key>
12  <string>Developer ID Application</string>
13</dict>
14</plist>

Then export:

bash
1xcodebuild -exportArchive -archivePath /tmp/WisprDuck.xcarchive -exportPath /tmp/WisprDuckExport -exportOptionsPlist /tmp/ExportOptions.plist

Confirm ** EXPORT SUCCEEDED **.

Step 5 — Verify signing

bash
1codesign -dv --verbose=2 /tmp/WisprDuckExport/WisprDuck.app

Confirm:

• Authority=Developer ID Application: Tiny Anvil, LLC (T4GBHCYB7P)
• flags=0x10000(runtime) (hardened runtime)

If signing is wrong, stop and diagnose.

Step 6 — Notarize

bash
1ditto -c -k --keepParent /tmp/WisprDuckExport/WisprDuck.app /tmp/WisprDuck-$ARGUMENTS.zip
2
3xcrun notarytool submit /tmp/WisprDuck-$ARGUMENTS.zip --keychain-profile "WisprDuck-Notarize" --wait

If the keychain profile is missing, ask the user to run:

xcrun notarytool store-credentials "WisprDuck-Notarize" --key ~/Desktop/wispr-duck-certs/AuthKey_4MM3YQXN45.p8 --key-id 4MM3YQXN45 --issuer 69a6de83-bf58-47e3-e053-5b8c7c11a4d1

Then retry. Confirm status is Accepted.

Step 7 — Staple

bash
1xcrun stapler staple /tmp/WisprDuckExport/WisprDuck.app
2xcrun stapler validate /tmp/WisprDuckExport/WisprDuck.app

Confirm The staple and validate action worked!.

Re-create the zip with the stapled app:

bash
1rm /tmp/WisprDuck-$ARGUMENTS.zip
2ditto -c -k --keepParent /tmp/WisprDuckExport/WisprDuck.app /tmp/WisprDuck-$ARGUMENTS.zip

Step 8 — Draft release notes and create GitHub release

Do not use --generate-notes — it only produces a bare changelog link with no useful content.

Instead, draft proper release notes:

1. Run git log <previous-tag>..HEAD --oneline to review all commits since the last release.
2. Read the previous release's notes (gh release view <previous-tag> --repo kalepail/wispr-duck) to match the established tone and format.
3. Write a release body. Scale the detail to the release size:

Patch releases (x.y.Z) — just categorized bullets, no intro paragraph:

markdown
1### <Category>
2
3- **Bold summary** — detail of each meaningful change.
4
5**Full Changelog**: https://github.com/kalepail/wispr-duck/compare/<previous-tag>...v$ARGUMENTS

Minor/major releases (x.Y.0 / X.0.0) — intro paragraph + categorized bullets:

markdown
1## What's New in v$ARGUMENTS
2
3<1-2 sentence summary of the theme of this release.>
4
5### <Category> (e.g. Bug Fixes, UI, Audio, Internal)
6
7- **Bold summary** — detail of each meaningful change.
8
9**Full Changelog**: https://github.com/kalepail/wispr-duck/compare/<previous-tag>...v$ARGUMENTS

Do not repeat boilerplate every release. Installation instructions, system requirements, and signing info belong in the README and on wisprduck.com — not in release notes. Only mention these if something about them changes (e.g., certificate rotation, new OS requirement, changed install steps).

4. Create the release, passing the body via a HEREDOC:

bash
1gh release create v$ARGUMENTS /tmp/WisprDuck-$ARGUMENTS.zip --repo kalepail/wispr-duck --title "WisprDuck v$ARGUMENTS" --notes "$(cat <<'EOF'
2<drafted release notes here>
3EOF
4)"

Print the release URL when done.

Step 9 — Clean up

bash
1rm -rf /tmp/WisprDuck.xcarchive /tmp/WisprDuckExport /tmp/ExportOptions.plist /tmp/WisprDuck-$ARGUMENTS.zip

Troubleshooting