2023.12.25

カスタムAppのアプリ審査についてよくある誤解(4) 〜緊急アップデートができない〜

AppStoreアプリ審査の誤解を解説するシリーズ4回目です。過去3回分は以下をご覧ください。

• カスタムAppのアプリ審査についてよくある誤解(1) 〜審査には時間がかかる〜
• カスタムAppのアプリ審査についてよくある誤解(2) 〜仕様や機密情報を開示する必要がある〜
• カスタムAppのアプリ審査についてよくある誤解(3) 〜特殊なアプリは審査して貰えない〜

今回は、「緊急アップデートは不可である」という誤解についてです。

ADEP(InHouse)なら自社の都合だけで即時配信が可能ですが、審査が必須となるカスタムAppではそうはいきません。とはいえやはり業務用アプリ。業務停止する程のクリティカルな不具合が発覚した時に、現場の端末にアプリを即時配信できないのは困りますよね。

緊急アップデートができないからADEP(InHouse)から移行はできません、という言葉はADP(カスタムApp)移行検討時の現場あるあるです。実際のところはどうなのでしょうか。

 

半分正解。アップデート版の即時配信はやはり不可

カスタムAppは緊急アップデートできない、という理解は半分正解で半分誤りです。まず正解部分を解説します。

理屈上は確かにそうなのです。カスタムAppは緊急アップデートできません。絶対に審査して貰う必要がありますから。例外はありません。

全てのAppStoreアプリは、審査をして貰い、Appleからの回答を待ち、その上で申請者側が「リリース」をする必要があります。業務用の非公開なカスタムAppでも同様です。

(カスタムAppのリリース作業の様子。審査合格で自動リリースする設定も可能だが、業務用では通常手動にする)

細かく流れを並べると以下のようになります。自社でコントロール可能なことを主導権欄に○で示しています。

STEP	内容	主導権
1	App Store Connect で申請する	○
2	Appleから審査OKの連絡を受ける
3	App Store Connect でリリース操作を行う	○
4	当該カスタムAppのアップデートをMDMが検出する
5	MDMは管理下の端末にアップデート命令を送る
6	端末側が当該カスタムAppをアップデートする

コントロールできる範囲が全てではないため、自社都合で即時アップデート配信ができるとはとても言えそうにないですよね。その意味で「緊急アップデートはできない」という理解は正解です。ただ、正解度合いは半分です。

というのも、「緊急」の温度感は各社毎に、アプリ毎に、シチュエーション毎に、全て異なるからです。致命的な不具合が発覚したとして、何時間以内ならokと言えるか。これに明確な答えを出せる現場は少ないでしょう。そもそも「緊急」とは曖昧であり、定量化しにくいものなのです。定性的な表現で物事を断定すべきではありません。

緊急時対策を考える時に大切なのことは、

• (A) 緊急時を極力発生させないように開発・運用すること
• (B) 緊急時の業務フローを定めること

です。

カスタムAppは緊急アップデートができない…と嘆く関係者ほど、カスタムAppを前提としたルールや業務フローを検討すらしていないように感じます。例えば以前の投稿で紹介したような、本番用・テスト用でアプリを分けるといった開発手法を採ってしまっているとかですね。

(A)は開発テクニック論になるので別途紹介することとして、ここで考えたいのは(B)の緊急時の業務フローです。先ほどの表を再掲します。

STEP	内容	主導権
1	App Store Connect で申請する	○
2	Appleから審査OKの連絡を受ける
3	App Store Connect でリリース操作を行う	○
4	当該カスタムAppのアップデートをMDMが検出する
5	MDMは管理下の端末にアップデート命令を送る
6	端末側が当該カスタムAppをアップデートする

実は各手順を細く見ると、カスタムAppでも「緊急」と言えるスピード感で対応できる可能性が見えてきます。

1,3はAppleを待つ時間ではありません。自社の問題です。誰がどのようにやるかを決めて正しい設定をすれば瞬殺で完了できるタスクです。また5,6はADEP(InHouse)を使っている場合でも一緒ですから考慮は不要。4はMDMの実装や仕様によりますので、MDMベンダーに確認し最短化する方法を提案して貰うことができます。

1,3,4,5,6は自分達が頑張れば瞬殺または最小化できること。では、残った2はどうでしょう。ここはAppleに依存する部分です。

 

緊急審査の要請ができる

余り知られていませんが、先ほどの表の1と2の間に、緊急審査要請を行うことができます。実は、公式ドキュメント App Review のページの中ほどに書いています。

唯一、自社だけの努力ではどうにもならない、かつ一番時間がかかりそうな Apple 審査の所要時間について、短縮の要請が可能になっているのです。もちろん然るべき理由は必要で、常に認められるわけではありません。

リンク先から専用のフォームを開くと、以下のようにどのアプリについてなぜ緊急審査が必要なのか入力を求められます。

(ADPのユーザとしてサインインした状態で入力する)

この緊急審査要請が受け入れられると、ものの数時間で審査して貰えてリリースが可能だということです。ただ、繰り返しになりますが理由が妥当でなければなりません。理由が不適切なら緊急審査を受理して貰えない場合もあります。

また、下図の注意表記(特に赤枠部分)は英文だからとスルーせずよく目を通しておきましょう。

過度な申請は将来の申請受理を難しくすると書いてありますね。従って乱用は避けるべきです。メールのタイトルにいつも「緊急」と書く人が信用されなくなるのと一緒です。

本当の緊急時に緊急審査をして貰えなくなる可能性がありますので気をつける必要がありますし、勝手に申請しないよう社内関係者や(AdminやAppManager権限を付与している)委託先にも注意を促しておくのが良いでしょう。

 

そもそも緊急審査要請は必要か？

実は、緊急審査の有用性は下がっています。

以前の投稿でも紹介した通り、90%のアプリが24時間以内に審査されていると公式に表明されていて、実際に数時間で審査が完了する場合もままあるからです。緊急審査要請の画面でも強調されています。

文頭から「今は平均で90%が24時間以内に審査されますよ。それにも関わらず御社は…」と書いてありますね。

審査を開始して貰うにも2週間かかっていた…という時代ならまだしも、審査スピードが上がっている昨今では、「Appleに緊急対応を求めても恥ずかしくない程度に、自社の緊急時体制は果たして整備されているか？」をまず問うことをお勧めします。

企業によっては非現実的なこともありますが、例えば以下のような検討/確認を行なって、体制を整えておくのが良いでしょう。

• 外部委託では商流段数を少なくし App Store の知見を持つ企業を選定する
• App Store アプリ申請の手順や役割分担を明確にする
• 本番用アプリとテスト用アプリを分けて開発しない
• TestFlight を活用して本番用アプリ想定で十分なテストを行う
• 端末側で TestFlight を配信し過去バージョンに戻せる体制を作っておく
• AdHoc 配布を併用することで有事のワークアラウンドにできないか検討する
• 初回バージョン以降は審査時間が短い傾向を活用し事前に初回審査を通しておく
• そもそも本当にアプリである必要があるかを考え、場合によってはWebアプリ化してWebClipでMDM配信する

緊急時を気にすればこそ色々と考えることがあるということですね。

 

以上、AppStoreアプリでは緊急アップデートができないという誤解について解説しました。半分正解で半分誤りです。なぜそう言えるのか、また緊急時対応が気になるアプリで事前に検討できる項目についても紹介しました。

アプリの緊急アップデートができないことを理由に、ADEP(InHouse)からADP(カスタムApp)には移行しないと決めてしまうのも一つの選択です。しかし、ADEPの将来が明るいとは考えにくいため、契約継続が難しくなる場合に備え本稿等を参考にして頂き諸々検討しておくことをお勧めします。