2023.5.29
実録！ADEPの更新を拒否されるまでの全て (3)
ADEPの更新申請と reject について解説する連載の3回目です。前2回は以下となります。
検索エンジンでいきなりこのページに到達された方はまず (1) (2) をご覧下さい。本稿は (2) の続きで、ADEP更新申請の3,4ページ目の質問と回答例を示し、最後に申請結果も紹介します。
Page3 : Code Sharing and Security
3ページ目は、他のページと違って選択肢によって設問が増減し、最小5問、最大7問と幅があります。少しややこしい(特殊な)ことをやっているとより多くの説明が求められます。順に見ていきましょう。
Do you re-sign compiled apps from other developers to use within your organization? (他の開発者がビルドしたアプリを受け取って自社利用のために再署名していますか？)
iOSアプリの署名の仕組みを理解していなければ、この設問の意味は理解に苦しむと思います。多くの企業では No になる筈です。iOSアプリの署名については以下の投稿を参考にして下さい。
通常は、ユーザ企業自身のADEP契約配下で証明書やProvisioning Profileを作成し、それを使ってXcodeで署名した InHouse の .ipa ファイルをユーザ企業内で配布します。自社開発でも外注する場合でも基本はこのスタイルです。
が、実は .ipa ファイルは、「再署名」することでアプリの名義を変更することができるのです。
- (1) 外注先の開発企業には、その企業の ADEP や ADP 契約の証明書・Provisioning Profile を使って署名した .ipa ファイル(外注先名義)を納品して貰う
- (2) 受け取ったユーザ企業側で自社のADEP契約の証明書やProvisioning Profileを使って署名をし直した .ipa ファイル(ユーザ企業名義)を生成する
- (3) 結果、InHouse アプリとなるのでそれを社内で配布する
これが「再署名」です。ADEPのユーザアカウントに外注先の人を入れたくない、作るのが現実的でないぐらいに外注先が多い…といった場合に使われる手法です。
このような運用をしている場合、この設問には Yes と応える必要があります。そして、Yes を選ぶと現れる下図の追加入力欄に詳細を記述しなければなりません。
具体的な手順を書くと良いでしょう。弊社は該当しませんので No を選びました。
Do you act as an app development contractor for other organizations? (他組織のアプリ開発請負者として活動していますか？)
次ですね。こちらの設問も多くの場合は No になる筈です。もし自社でADEP契約をしていながら、他社アプリの受託開発をしている場合は Yes を選択して下さい。以下のような追加入力欄が現れます。
Describe your process for giving completed apps and source code to other organizations. とある通り、ipa とソースコードの納品方法について記述しましょう。
弊社の場合、過去には該当していました(ADEPを自社で持ちながら他社ADEP向けアプリを受託開発)が、今回のADEP更新時点で全てのお客様にカスタムApp(ADP)へ移行して頂いてましたので No と回答しました。
What mechanisms have you put in place to ensure your apps can only be installed by your employees and permitted users? (従業員や許可されたユーザだけがインストールできるようにするどんな仕組みを用意していますか？)
用意しているものの詳細を書きましょう。弊社は、MDMを使っていること、限られたユーザだけがMDMアクセスできること、を強調して上図のように書きました。
Who has access to the sign in credentials of the Account Holder and Enterprise App Distribution Certificates? (Account Holder とInHouseアプリ用配布証明書にアクセス権限を持っているのは誰ですか？)
Account Holder のアクセス権限をどう扱っているか書きます。また Enterprise App Distribution Certificates は、ここでは配布用(Distribution)の証明書を発行できる権限を持っている人の事を指していると考えられます。
Apple公式ドキュメントプログラムにおける役割によると「配布用証明書の作成と無効化」という権限があり、それを Account Holder 以外の Admin や App Manager にも付与できることが示されています。
(配布用証明書はADEPを特別たらしめている要(かなめ)。作成権限を持てるユーザは限られている)
もし Admin や App Manager のアカウントユーザをADEP配下で作成しているなら、それらのアカウントユーザの扱いについても記述しておきましょう。
How do you monitor and control access to your Enterprise App Distribution Certificates? (InHouseアプリ用配布証明書へのアクセスをどのように管理・制御していますか？)
ここでいう Enterprise App Distribution Certificates は InHouse 用の証明書、つまり.p12 ファイルです。厳密に言うと Certificates は .p12 ファイルの中に含まれるAppleにより署名された公開鍵のことを指していますが、.p12 ファイルをどう管理しているか問われていると考えて良いでしょう。
ADEPでの InHouse 用 .p12 ファイルは、業務用iOSアプリ開発における最重要ファイルです。開発担当者に渡す際にはアクセスコントロール可能な仕組みを使って厳密に扱う必要があるものです。普段どのように扱っているかを書きましょう。
Page4 : App Testing
4ページ目ではテストについてや、ADEPの応用的利活用について問われます。ADEP での InHouse アプリを特別な用途で使っていない限り英文記述はありません。
Do you use program resources to test apps before publishing them on the App Store? (ADEPをAppStoreでの公開前テストに使っていますか？)
審査無く無制限にアプリを配布できるのがADEPの特徴でした。その特徴を、自社内の業務用アプリのためではなく、AppStore 公開アプリや他社からの受託開発アプリの開発で社内テストに活用している場合があります。
実際に便利ですし、弊社も昔はそうしていました。テスト用途で InHouse を使用しているならこの設問は Yes です。弊社では既にTestFlightに移行していましたので No としました。
Which of the following uses of the program are necessary for your organization? (あなたの組織でADEPが必要な理由となっているのは以下のうちどの用途ですか？)
即時配信(Immediate distribution)、複数バージョンの共存(Availability of multiple app versions)、App testing outside of TestFlight(TestFlight外のアプリテスト) から該当する利用方法があればチェックを入れます。いずれも ADEP の InHouse 活用テクニックです。
3つの意味が分からない場合はチェック不要です。また、3つの選択肢以外の用途で使っている場合は Other にチェックを入れて詳細を記述しましょう。弊社の場合は、本サイトでの検証用に使っていることを書きました。(ここでアピールすれば通るかも知れないという実験😁)
以上の項目で最後です。お疲れさまでした。確認画面を経て最終の Submit をすると、受理されてADEP更新の申請手続きは完了となります。直後に Account Holder に以下のようなメールが届きます。
(5営業日以内とあるが、これ以上かかる場合もある模様)
更新申請の審査結果
メールでは5営業日以内とされていましたが、弊社の場合は申請の翌日に Apple から連絡がありました。結果は reject(拒否) です。
メールには、従業員100人以上の組織というADEPの契約条件を満たさないため更新は認めないと。まさに予想通りでした。これは最も分かり易い reject(拒否) 理由でしょう。
ADEPの期限日情報や、その日から90日でInHouseアプリが起動しなくなることも記載されています。その他は、ADEP期限の90日前や30日前に届いていたメールと一緒ですね。カスタムApp移行を始めとする next action の紹介文です。
reject された後、ADEP の画面は以下のようになります。
そして、実際に期限日が到来すると以下のような画面に変わります。期限日前の上図と異なり、証明書や Provisioning Profile の編集リンクが消えていることが分かります。
以前に別の投稿で紹介した通りですが、このrejectをもって「InHouseアプリが突然使えなくなるタイムリミット」に向けたカウントダウンが始まります。残り90日というわけですね。
ただ、90日後よりも前に配布済み InHouse アプリの署名に使われていた Provisioning Profile の期限切れ日が到来するなら、その日がタイムリミットになる点は注意して下さい。詳しくは以下投稿を参照して下さい。
– ADEP契約を更新せず放置するとInHouseアプリはどうなるのか
ADEP更新拒否のその後
ADEPの更新を reject されて1ヶ月すると、Apple から残り60日ですというメールが届きます。
このメールが届いた60日後には InHouse アプリは動かなくなる筈です。…が、実際にはそうならなかった例もありますので以下も参照して下さい。
この90日後の挙動については、改めて検証したいと思っています。結果はまたこの投稿に追記するか、別の投稿にまとめたいと思います。
ということで、ADEPの更新申請について詳細を書いてきました。ADEP更新申請に直面された方のお役に立てたら幸いです。
