証明書とプロビジョニングは扱いにくいトピックになる可能性があるため、うっかりして面倒なことになる前に、まず質問することをお勧めします。
Q1: アカウントごとに配布証明書は 1 つだけですか?
はい、個人および企業のアカウントは、会員年度ごとに 1 つの有効な配布証明書に制限されていますが、この証明書は、個人または企業が必要と判断した場合 (公開/秘密キーの侵害、従業員の解雇)、いつでも取り消され、再発行される場合があります。秘密鍵へのアクセスなど）。最近、 「コード署名 ID とは何ですか?」という質問に回答しました。これは、プロビジョニング プロファイルにエンコードされる情報と、デバイス ビルドの実行時に Xcode がこの情報を検索する方法に関する追加のコンテキストを提供するのに役立つ場合があります。使用するプロビジョニング プロファイルの種類 (開発と配布) に応じて、プロビジョニング プロファイルでエンコードされる証明書とテスト デバイスの数と種類が変わることに注意してください。
また、準備中/作成中の 2 番目のアプリケーションのアプリ ID/バンドル ID でエンコードされたまったく新しいプロビジョニング プロファイルのセットを使用して、既存の配布証明書を再利用するという点でも完全に正しいです。
Q2: キーチェーンにインストールされるのは、プロビジョニング プロファイルではなく証明書ですか? ビルド マシンはどのような影響を受けますか?
はい、これは正しいです。開発証明書と配布証明書の両方がキーチェーンにインストールされ、プロビジョニング プロファイルはコード署名操作で使用するために Xcode 内の特別なディレクトリにインストールされます。
ビルド マシンのセットアップが完了し、最初のアプリの作業が完了したと仮定すると、多くの大変な作業が完了したことになります。まだやらなければならないことのハイレベルなリスト:
- 既存の証明書を使用して、新しい AppId の一連のプロビジョニング プロファイルを生成します
- ビルド環境にプロビジョニング プロファイルをインストールする
- Xcode プロジェクトの「コード署名 ID」ビルド設定が、新しく作成されたプロビジョニング プロファイルを使用するように構成されていることを確認するか、プロジェクト構成で許可されている場合は「自動プロファイル セレクター」を使用するのがより理想的です。
- ビルド システムを構成して、実際に新しいアプリを作成します。
これらの高レベル タスクの特定の HOWTO は、プロジェクトとビルド システムのセットアップ方法に多少依存しますが、通常、最初のアプリを構築するときに使用したのと同じワークフローに従う必要があります。
Q3: ビルド環境を別のマシンに分割する必要はありますか?
この質問の「必要な」部分に関しては、いいえ、これらのアプリを並べてビルドできるようにするために、ビルド環境を物理的または仮想的に分離する必要はありませんが、ビジネスの場合はそうすることを選択できますアプリケーションごとに専用のビルド環境が必要になるようなニーズがありました。
技術的な観点から見ると、プロビジョニング プロファイルは、並行して構築できるようにするために必要なパーティショニングの 99% を提供します。物理的または仮想的なパーティション分割が必要になる状況に遭遇するのは、2 つ以上の iOS 開発プログラムのメンバーであり、これらの各チームによって発行された証明書の「共通名」が一致した場合のみです (例: 「iPhone ディストリビューション: MyCompany」はチーム 1 からの証明書の共通名であり、チーム 2 によって発行された証明書と完全に同一でした)。このような場合、Xcode で次のような警告とエラーが表示されます。
コード署名エラー: 証明書 ID 'iPhone ディストリビューション: MyName' がキーチェーンに複数回表示されます。コードサイン ツールでは、1 つだけ存在する必要があります。
それ以外の場合はすべて、証明書とプロビジョニング プロファイルの両方がインストールされていて、Code Signing Identity の値が正しく設定されていると仮定すると、Code Sign はそれ自体で問題を解決できます。
Q4: 両方のアプリで同じプッシュ証明書を再利用しても問題ありませんか?
これはしっかりした「いいえ」です。各アプリ ID には、プッシュ通知を含む一連の資格が付随する独自のプロビジョニング プロファイルのセットがあります。プッシュ通知資格を使用して新しいプロビジョニング プロファイルを作成する場合、新しいプッシュ証明書を生成するよう求められます -- 既存の証明書を Apple に提供する機会はありません。これは、プッシュ通知の「プロバイダー」(Apple のプッシュ ゲートウェイに送信されるプッシュ通知ペイロードを作成するサーバー) が、iOS エコシステム内で見られるのと同様の方法でサンドボックス化されるようにするために行われます。 AppId ごとのサンドボックス。
セキュリティの観点から、これにより、Apple のプッシュ ゲートウェイで有効なプッシュ トークンとペイロードを提供するだけで、攻撃者がスパムのようなプッシュ通知をユーザーに送信するのを防ぐことができます。プロバイダー コードの 2 番目のインスタンスをセットアップし、新しいプロビジョニング プロファイルの作成中に生成されたプッシュ証明書を使用するか、既存のプロバイダーを更新して、アプリケーションごとのレベルでプッシュ通知トークンを追跡し、プッシュ通知ペイロードの送信時に適切な証明書を使用します。アップルへ。残念ながら、この決定を行うことができるのはあなた (またはあなたの同僚) だけです。その決定は、既存のプロバイダーの技術的能力と、あなた/あなたの会社が同じプロバイダー インスタンスでプッシュ通知を統合するリスクの程度によって左右されるためです。
他の人はここにパイプを張って、独自のプロバイダーをセットアップする方法について追加の洞察を提供するかもしれませんが、あるアプリのプッシュ通知の更新がまったく別のアプリのプッシュ通知を壊す可能性があるというシナリオを防ぐために、完全に別のインスタンスを使用しました.