Sparkle自動更新はどう導入する？2026年macOSリリース手順

まず、対象アプリがMac App Store経由か、Webサイトなどから配布するアプリかを確定します。この記事で扱うのは後者です。Mac App Storeの配布とSparkleによる更新は同じ仕組みではありません。配布方式ごとの要件は、AppleのmacOSソフトウェア配布案内で確認してください。

Web配布では、Developer IDによるコード署名と公証が必要になる場合があります。適用要件をAppleの公証に関する公式説明で確認し、Sparkleの更新アーカイブ署名とは別工程として管理します。

次に、すでに配布した版がどのSparkle機能を使っているか、アプリのバージョン表記とビルド番号、更新アーカイブの形式を記録します。過去版が理解できない形式や署名方式を新しい公開側だけで採用すると、更新を検出してもインストールに進めない可能性があります。アップグレード時の互換性はSparkleのアップグレード説明に照らして確認します。

macOS Appの自動更新で最初に固定するのは、アプリが確認する更新フィードのURLです。ダウンロード案内ページ、appcast、appcast内に記載する更新アーカイブのURLは役割が異なります。利用者向けページを更新フィードとして設定しないよう、配布資料と設定値を分けて管理します。

Sparkleの設定項目や対応形式は、公式ドキュメントとカスタマイズ設定で確認してください。実装時は、たとえば SUFeedURL にフィードのURLを設定し、更新対象を示すバージョン情報が既存版より新しいことを確かめます。設定キーや利用条件は導入するSparkleの構成に合わせて照合し、古い説明をそのまま流用しないでください。

更新元を設定する作業

• [ ] アプリの配布経路がWeb配布であることを確認します。
• [ ] フィード用URLと利用者向けダウンロードページを別々に記録します。
• [ ] アプリ内のSparkle設定がフィードを指していることを確認します。
• [ ] 配布済みの旧版が認識する更新情報・アーカイブ形式を調べます。
• [ ] 既存版より新しいビルドで更新判定が行われることを確認します。

AppleのDeveloper IDコード署名は、配布するアプリの身元や改変確認に関係します。一方、SparkleのEdDSA署名は更新アーカイブの検証に使われます。公開鍵をアプリ側に設定し、対応する署名を更新アーカイブに付ける流れは、Sparkleのセキュリティと信頼性の説明で確認します。

Sparkleの署名ツールでアーカイブを処理するときは、生成された署名値とアプリ側の公開鍵設定が対応しているかを検証します。秘密鍵はリポジトリに登録せず、サンプルにも書きません。保管先やアクセス手順は、実際のチームの権限管理と運用に合わせて決めます。確認できない保護方式を「安全」と断言しないでください。

注意：appcastは更新情報を配信するファイルであり、その存在だけで更新アーカイブの真正性が保証されるわけではありません。フィードの配信経路、アーカイブの署名、アプリのコード署名、公証を別々に検証します。

更新パッケージを用意したら、Sparkleの公開手順に従ってappcastを生成または編集します。公式の更新公開ガイドでは、generate_appcast などの公開用ツールを扱っています。自動生成を使う場合も、アプリの表示バージョン、ビルドを識別する値、リリースノート、更新アーカイブの参照先が意図どおりか確認します。

手動編集は細かな調整がしやすい一方、URLやバージョンの転記ミスを見逃しやすくなります。自動生成は作業を揃えやすいものの、出力を確認せず公開してよいわけではありません。どちらの方式でも、フィードが示すファイルを実際に取得できるか、署名値が配布するアーカイブと一致するかを公開前に調べます。

• [ ] 公開対象のアーカイブを確定します。
• [ ] Sparkleの手順に沿って署名を生成し、アプリ内の公開鍵と照合します。
• [ ] appcastに新しいバージョン情報とリリースノートを反映します。
• [ ] appcast内のアーカイブURLからファイルを取得できることを確認します。
• [ ] appcast、アーカイブ、ダウンロード案内ページの公開内容を突き合わせます。

更新公開の完了条件は、最新版を新規インストールできることだけではありません。利用中の旧版が更新を検出し、署名を検証し、インストール後に新版を起動できることまで確かめます。未公開の開発版だけで試すと、旧版の互換性や既存設定に起因する問題を見落とします。

旧版からのアップグレードを確認する

• [ ] 配布済みの旧版を用意し、アプリ内に表示される版とビルド識別子を記録します。
• [ ] 旧版から更新確認を実行し、指定したフィードが読み込まれるか見ます。
• [ ] 更新アーカイブを取得し、Sparkleの署名検証が通るか確認します。
• [ ] インストール後に新版が起動し、アプリ内の版表示が更新されているか確認します。
• [ ] appcastの情報、取得したアーカイブ、表示バージョン、ビルド識別子をリリース記録に残します。

失敗時は、症状をひとまとめにせず切り分けます。フィードを取得できないならURLや配信設定、更新を提示しないなら新旧のバージョン判定、署名で止まるなら公開鍵とアーカイブの対応、インストール後に異常が出るなら起動ログと更新前後の設定を確認します。

公開URLへ接続できることは、無人のリリース処理が検証済みである証拠にはなりません。署名生成から旧版の更新・起動まで、実際の公開経路で一連の確認を行います。

次回以降も、アーカイブ、appcast、リリースノートを同じ変更記録にまとめます。問題が見つかったときに、どの版をどのフィードへ公開したか追える状態を保ち、公開物を戻す手順も事前に決めます。

EdDSA鍵を変更する場合は、新しい鍵を配布済みアプリが受け入れられるかを先に調べます。新しい設定だけで公開すると、旧版が更新アーカイブを検証できなくなる恐れがあります。移行条件と手順はSparkleのEdDSA移行ガイドを参照し、実際の旧版で確認してから切り替えます。

条件に応じて公開環境を選ぶ

• すでに署名可能なMacがあり、公開頻度も低い場合：まずそのMacで手動の更新確認を完了します。運用を増やす前に、署名・公開記録・旧版確認の手順を固めます。
• 公開のたびにmacOS環境が必要で、手元にMacがない場合：遠隔Macをビルド、コード署名、更新検証に使えるか評価します。秘密鍵へのアクセス方法と利用者権限を先に設計します。
• 利用者の旧版を安全に検証できない場合：自動更新の対象を広げず、互換性確認が済むまで従来の配布手段を残します。
• 物理接続機器や常時占有が必要な場合：遠隔環境が要件を満たすとは限りません。実機や専用のローカルMacを優先します。

遠隔MacはmacOS上での構築や署名、リリース確認をまとめる選択肢になりますが、接続できることと公開作業が無人で成功することは別です。利用条件を検討する際は、MESHLAUNCHの案内と、Mac miniの日本向け構成案を見比べ、遠隔利用と自社保有のどちらが公開頻度や鍵管理に合うか判断してください。

ローカルMacを専用の公開機にすると、初期の機器費用、保守、設置場所の確保が必要です。一般的なクラウド環境だけではmacOS固有の署名・ビルド工程を置き換えられず、共有手順だけでは鍵の管理責任も解決しません。公開が断続的で、macOS環境を常時自社保有する必要がないなら、MESHLAUNCHの遠隔Macを一時的な構築・検証環境として比較する余地があります。一方、長期の常時負荷や物理機器への接続が前提なら、自社Macのほうが適する場合があります。Sparkle自動更新の導入では、契約形態より先に、旧版から新版までの更新経路を検証できる運用を選んでください。