Appleは、公証サービスとのやりとりにnotarytoolとNotary APIの2つの方法を案内しています。Notary APIの概要によると、公証の提出と状態確認だけなら、Notary APIを使ってその部分をmacOSから切り離せます。ただし、アプリの構築、署名、チケットの装着、配布前の受け入れ確認までMac不要になるわけではありません。
今週の判断：すでにXcodeとMacで構築・署名しているなら、まずnotarytoolを既存の流れに組み込みます。WindowsやLinuxから公証サービスへ接続する必要が明確な場合に限り、Notary APIへの切り替えを検討してください。
この記事は、macOSアプリをサイト外に配布する独立開発者向けです。
WindowsまたはLinuxの公開パイプラインで、公証提出まで扱えるかを見極めたい人にも役立ちます。
署名情報や公開前の受け入れ確認を担当する小規模チームも対象です。
SECTION 01 公証のどの工程をMacから切り離せるのか
公証は「アプリを送信すれば配布完了」という単独の処理ではありません。構築、署名、公証サービスへの提出、結果の確認、ログの確認、チケットの装着、実際に配布する成果物の受け入れを、別々の工程として管理してください。
AppleのNotary APIによるウェブ経由の提出手順では、APIを通じた公証の提出に加えて、処理状況やログを扱う手順が示されています。したがって、Notary APIが置き換えられるのは主に公証サービスとの通信部分であり、Mac上のXcodeや署名ツールまで提供するものではありません。
一方、Appleのnotarytoolを使う公証ワークフローでは、コマンドラインから公証サービスに接続する方法を案内しています。Xcodeを使う既存のMac環境があるなら、別途APIクライアントを保守する前に、現在のビルド手順へnotarytoolをつなげられるか確認する方が、運用箇所を増やさずに済みます。
notarytoolはWindowsやLinuxでもそのまま動かせますか？
notarytoolはAppleが案内するコマンドラインの公証ツールで、Mac上のXcode関連ツールと組み合わせる経路です。Appleのコマンドラインツールのインストール説明を踏まえると、WindowsやLinuxで同じ実行ファイルを使う前提にはできません。非Mac環境から公証のやりとりを行いたい場合は、Notary APIを検討します。
SECTION 02 Xcode中心の開発者は既存のMac経路を優先
すでにMac上でXcodeを使い、アプリの構築と署名も同じ環境で行っているなら、公証だけをNotary APIへ移す利点があるかを先に確かめましょう。API呼び出しの実装、認証情報の保管、エラー時の再試行やログの管理が新たに必要になる一方、Mac側の構築や署名工程は残ります。
AppleのXcodeによる配布準備の説明では、公証の前後に行う配布準備が案内されています。公証を通過したという結果だけで配布用ファイルが完成したと判断せず、チケット装着後の成果物まで確認してください。
Notary APIはnotarytoolを完全に置き換えられますか？
公証サービスへの提出や状態確認をAPI経由にすることはできますが、それだけで構築、署名、チケット装着の手段まで置き換わるわけではありません。すでにXcode中心のMac経路が安定している場合は、API化の効果が「提出環境を分離する必要」に見合うかを基準にしてください。
SECTION 03 Windows・Linuxの公開担当者はAPIの境界を確認
WindowsやLinuxにあるパイプラインから公証を提出する場合、Notary APIは公証サービスとのやりとりを非Mac環境へ移す選択肢になります。ただし、そこで得られるのはMacのビルド環境ではありません。Macを使わずにアプリの構築や署名まで行えると解釈しないでください。
AppleのNotary APIの説明に沿って、APIが担う提出、処理状況の確認、ログ取得と、パイプライン内の他の工程を分けます。アプリを作る環境、署名する環境、公証を提出する環境、配布物を検査する環境をそれぞれ書き出せば、API導入後も残るMac作業が見えます。
Mac以外から提出したあとも、staplerは必要ですか？
チケットを配布物に装着する必要がある構成では、公証の提出・通過とは別に装着工程を扱います。Appleのアプリを配布用に準備する手順で対象の成果物と必要な処理を確認し、APIが装着まで自動で済ませるとは見なさないでください。最終的には、実際に配布するファイルを対象に受け入れ確認を行います。
公証の提出が成功したことと、ユーザーへ渡せる成果物が完成したことは別の判定です。提出結果、チケット装着後の状態、配布対象ファイルを別々に記録してください。
SECTION 04 外部ビルドを使うチームは責任範囲を先に固定
別のビルドシステムでmacOSアプリを生成していて、公証提出だけを既存のWindowsまたはLinuxパイプラインに入れたい場合は、notarytoolを動かすMac工程を残す案と、Notary APIを呼び出す案を比較します。判断点は、どちらが新しいかではなく、提出処理を実行する場所と、その場所で必要になる資格情報を誰が管理するかです。
Notary APIの認証ではJWTが使われ、提出時のアップロードに関わる一時的な認証情報も扱われます。ウェブ経由の提出手順を参照し、秘密鍵や一時情報をソースコード、共有ログ、再利用可能な成果物へ書き込まない運用にしてください。認証情報の保管先、参照できる担当者、失効・更新時の手順を決めずにAPI化すると、実行環境を広げた分だけ漏えい時の確認範囲も広がります。
Xcodeの構築工程がある場合、どの段階でNotary APIを選びますか？
非Macのパイプラインから公証提出を行う必要がある、または提出処理をビルド環境から明確に分離したい場合に、API化を評価します。それ以外でMac上のXcode経路が機能しているなら、まずnotarytoolを使い、APIの保守コストを増やす根拠があるかを確認してください。
SECTION 05 公証方式を決めるチェックリスト
次の項目にチェックを付け、該当する分岐で方式を選んでください。
-
[ ] 構築と署名をMac上のXcodeで行い、公証提出も同じMacから実行できる
→ まずnotarytoolを選びます。提出だけをAPI化する明確な要件がなければ、クライアント実装や認証情報の管理を増やす必要はありません。 -
[ ] WindowsまたはLinuxのパイプラインから公証提出や状態確認を行う必要がある
→ Notary APIを候補にします。ただし、アプリの構築・署名やチケット装着、配布前の確認に必要な環境は別途確保してください。 -
[ ] 外部ビルドで成果物を作り、公証提出の責任範囲をビルド環境から分けたい
→ APIを追加する保守負担と、Macでnotarytoolを実行する運用負担を比較します。秘密鍵の保管、ログ確認者、失敗時の対応を決められない場合は、移行を保留してください。 -
[ ] 公証の成功だけを見て、そのまま公開している
→ 方式を変える前に、チケット装着の要否と実際の配布物の受け入れ確認をリリース手順に追加します。提出方法を変えても、これらの確認は省略できません。
最初の2項目のうち、Macから提出できる条件だけに当てはまるならnotarytool、非Macから提出する必要にも当てはまるならNotary APIを検討します。どちらを選んでも、構築・署名・装着・最終確認の担当環境は別に記録してください。
SECTION 06 リリース前の確認をマイルストーンで進める
- 工程を分解する：構築、署名、公証提出、状態確認、ログ確認、チケット装着、配布前確認を、担当環境ごとに記録します。
- 現在の成功経路を基準にする：XcodeとMacで公開できているなら、まず現在の
notarytool運用を確認し、APIへ移す必要がある工程を特定します。 - 非Macへ移す範囲を決める：WindowsまたはLinuxから提出・状態確認を行う必要がある場合だけ、Notary APIを候補に加えます。
- 認証情報の扱いを点検する：JWT用の秘密鍵と一時的なアップロード情報が、ログや成果物へ残らないことを確認します。
- 提出後の状態とログを確認する：成功・失敗を記録し、問題があればAppleの公証でよくある問題の解決手順に照らして原因を切り分けます。
- 配布物を受け入れ確認する：必要なチケット装着を行い、実際に配布するファイルが公開要件を満たすか、別工程として確認します。
いまのMac公開経路を維持する場合、専用機の購入には初期費用や保守が伴い、手元のMacだけに集約すると利用可能時間や空き容量が制約になり、非MacのパイプラインだけではXcode関連作業やチケット装着を担えないことがあります。こうした不足する工程を一時的に補いたいなら、VPSNIXの利用案内でリモートMacの利用方法を確認し、構築・署名・装着が実際の作業環境で行えるかを判断できます。
短期の公開作業や検証用環境にはレンタルが選択肢になりますが、長期間の高負荷運用や物理機器への接続が欠かせない場合は、自前のMacを含めて比べてください。費用を検討する際はVPSNIXの料金案内も参照し、公証提出だけを理由にMacが不要だと決めず、リリース全体に必要な環境から選びましょう。