Mac App Store以外でmacOSアプリを配布するには、アプリの署名、Appleの公証、自動アップデートの仕組みが必要になる。ここでは、Developer ID署名、公証（notarization）、Sparkleによる自動アップデートを組み合わせて、GitHub Releasesでアプリを配布するまでの手順を、各記事へのリンクとともにまとめる。

Sparkleの更新が正しく動くかは、古いバージョンのアプリを起動して、実際に新しいバージョンへ更新して確認する。手順は次のとおりである。 古いバージョン（v1.0.0）のアプリをインストールして起動する 新しいバージョン（v1.0.1）をリリースする 古いバージョンのアプリで、更新を確認する 更新をインストールして、新しいバージョンで再起動することを確認する 実行例はSparkle 2.10.0、macOS 27.0.1のもの。画面はSparkleの英語のUIで、アプリのメニューは日本語である。リリースは、GitHub Actionsの自動化したワークフローから作成している。

macOSアプリのリリースは、署名、公証、staple、zip化、appcast.xmlの更新、GitHub Releasesへの公開と、手順が多い。タグ（v*）をpushしたときに、これらをすべて自動で実行するGitHub Actionsのワークフローを紹介する。

開発中のXcodeプロジェクトは、署名がAutomatic（自動署名）で、Apple Developmentの証明書を使うのが一般的である。配布用のアプリは、Developer ID Applicationの証明書で署名する。ローカルの設定は変えずに、CIでだけDeveloper IDの署名に切り替えたい。

GitHub ActionsのmacOSランナーでアプリに署名するには、Developer ID Applicationの証明書を、ランナーのキーチェーンにインポートする必要がある。ランナーは毎回新しい環境なので、ワークフローの実行ごとに、証明書をインポートする。

Sparkleのアプリは、Info.plistのSUFeedURLに書かれたURLから、appcast.xmlを取得する。このURLは、アプリに埋め込まれるため、リリースのたびに変えられない。GitHub Releasesのreleases/latest/download/を使うと、最新のリリースに添付したappcast.xmlを、固定のURLで配信できる。

Sparkleは、アプリが更新対象かどうかを、ビルド番号（CFBundleVersion）で判定する。表示用のバージョン番号（CFBundleShortVersionString）は、判定に使われない。Xcodeのビルド設定では、ビルド番号がCURRENT_PROJECT_VERSION、バージョン番号がMARKETING_VERSIONである。

Sparkleのアプリは、更新の情報が書かれたappcast.xmlを定期的に取得して、新しいバージョンがあるかを判断する。generate_appcastは、配布用のzipを置いたディレクトリから、appcast.xmlを生成する。zipの中のInfo.plistからバージョンを読み取り、EdDSAの署名も付ける。

Sparkleは、配布する更新のアーカイブをEdDSA（Ed25519）の署名で検証する。アプリは、Info.plistに埋め込まれた公開鍵で署名を検証し、一致した更新だけをインストールする。署名に使う鍵のペアは、Sparkleに含まれるgenerate_keysで生成する。

Mac App Store外で配布するmacOSアプリに、自動アップデートの機能を組み込むときは、Sparkleを使う。SparkleはmacOS向けのアップデート用フレームワークで、更新の確認、ダウンロード、署名の検証、インストールまでを担当する。