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

各記事の実行例は、Xcode 27.0、macOS 27.0.1、Sparkle 2.10.0のもの。GitHub Actionsのランナーには、Xcode 27.0が入ったxcode-27を使っている。

全体の流れ

アプリのビルドから、ユーザーのアプリが更新を検出するまでの流れは、次のとおりである。

graph TD
  A[アーカイブしてエクスポート] --> B[Developer ID署名]
  B --> C[公証に提出]
  C --> D{公証の結果}
  D -->|Invalid| E[ログで原因を調べて修正]
  E --> B
  D -->|Accepted| F[staple]
  F --> G[配布用のzipを作成]
  G --> H[appcast.xmlを生成]
  H --> I[GitHub Releasesに公開]
  I --> J[アプリが更新を検出]

GitHub Actionsのワークフローでは、タグをpushするだけで、アーカイブからGitHub Releasesへの公開までを自動で実行できる。

必要なもの

手順を始める前に、次のものを用意する。

  • Apple Developer Programのアカウント（Developer ID証明書の作成は、Account Holderの権限が必要）
  • Developer ID Applicationの証明書
  • 公証に使うApple IDとApp用パスワード
  • Sparkleの署名鍵（EdDSA）
  • 公開リポジトリのGitHubリポジトリ（appcast.xmlとzipの配信先）

記事一覧

準備

ビルドと署名

公証

Sparkle

配信

GitHub Actions

仕上げ

つまずきやすい点

つまずきやすい点を、記事の順にまとめる。詳細は、記事一覧の各記事で解説している。

  • Developer ID証明書の作成画面では、Sub-CAの既定が「Previous Sub-CA」で、2027年2月に失効する。「G2 Sub-CA」を選ぶ
  • Homebrewのopenssl（OpenSSL 3）で作った.p12は、security importで失敗する
  • App用パスワードのラベルに、括弧などの記号は使えない
  • notarytool submit --waitは、公証がInvalidでも終了コードが0である
  • 公証していないコピーも、同じ署名であれば、公証済みと判定される
  • キーチェーンにed25519の鍵があると、generate_keysは新しい鍵を作らず、既存の鍵を使う
  • ビルド番号のハイフン以降は、比較に使われない
  • 過去のappcast.xmlは、generate_appcastの対象のディレクトリに置かないと、引き継がれない
  • リリースの作成からlatest/download/への反映まで、時間を要する場合がある

この記事群で扱わないこと

次の内容は、この記事群では扱っていない。

  • Mac App Storeでの配布
  • .pkgインストーラや.dmgでの配布
  • App Store Connect APIキーによる公証の認証
  • App Sandboxを有効にしたアプリでのSparkleの設定
＼第一線のプログラマーの行動原理を学べる！／

プログラマが知るべき97のこと

Amazonで見る