2023.10.30
業務用AppStoreアプリで審査にリジェクトされないために読んでおくべき公式ドキュメント
カスタムAppに関連して頂く質問は色々ありますが、定番なのが「Appleの審査でどんなことを審査されるのですか？」「どんなアプリだと審査で落とされますか？」といった審査に対する心配からくる質問です。
カスタムAppは App Store のアプリですので、Appleの審査に通過しなければなりません。頑張って開発しても審査に合格しなければ配信もできませんから心配なのは当然です。ADEP(InHouseアプリ)から移行するアプリの場合は、業務継続すら危ぶまれますので尚のこと気になるでしょう。
そこで本稿では、Apple が審査で何を見るのか、どんな場合にリジェクトをされるのか、を窺い知るのに役立つ情報を紹介します。
順に見ていきましょう。
Apple が公式にNGといっているものを確認する
App Store のアプリでは申請されたアプリに審査員(レビュワー)がつきます。アプリの審査は生身の人間が行うのですね。B2CだろうがB2Bだろうが一緒です。
人間が判断して審査する以上、基準が必要です。それが App Store Review Guideline。公式のルールブックであり、カスタムApp関係者全員が読むべきドキュメントです。
App Store Review Guideline
レビュワーは基本的にこのガイドラインを根拠にアプリの合否を決めます。リジェクト(不合格)となった時には、下図のようにガイドラインの番号付きで指摘されます。
(リジェクトされている様子。不合格理由をガイドラインの番号で示してくれる)
ガイドラインが判断基準となっていることがよく分かりますね。
ルールを知らずにスポーツや競技で勝つことはできません。例えば、オフサイドのルールを知らずしてサッカーの試合にどうすれば勝てるか…を心配するのは滑稽ですよね。
それと同じことです。App Store の審査で勝利(審査通過)を得るには、まずルールを知る必要があります。App Store のルールブックが App Store Review Guideline。審査が心配な人はまずこれをよく読まなければなりません。話はそこからです。
App Store Review Guideline は昔と違って随分親切なドキュメントになっていますので、カスタムApp関係者は是非読んでみて下さい。
App Review
とはいえ、App Store Review Guideline は項目数も多く全部読むのは正直大変。確かにそうなんです。文字数にして数万文字ありますから。
サマリーだけ知りたいという人向けに紹介したいのが、App Store を紹介するページの App Review です。
Apple の審査とは？を基本から教えてくれるドキュメントで、リジェクトされる具体的な例も列挙されていますので、カスタムAppはおろか App Store 向けのアプリすら全くの初めてだ…という方には最初の入口として最適なドキュメントです。
(当たり前の理由でリジェクトされる割合が、案外多いことが分かる)
Apple のソフトウェア哲学を知りリジェクトを避ける
審査のガイドラインのほかに、目を通すべきなのが Human Interface Guideline です。略して HIG と書かれることもあります。 読み方はそのままエイチアイジー、あるいはヒグと呼ぶ方もいますね。
Human Interface Guideline
量は膨大で App Store Review Guideline を遥かに上回ります。AppleはデザインやUX/UIに強いポリシーを持っていて、それを明文化したのが HIG になります。
アプリが分かり易いデザインで使い易い作りになるよう、見た目や操作感の基本原則やベストプラクティスを OS ごとにまとめたものです。UIはこうした方が良いよって Apple 自身が書いてくれてるのですね。
例えばボタンのセクション。
そのページにベストプラクティスというセクションがあり、以下のようなことが書いてあります。
「ユーザが使いやすいボタン」とは一体何なのか、「目的が明確に伝わる」とはどういうことか、解説してくれています。ボタンはこうすべきと Apple が言っているわけですから従っていないとリジェクトになる可能性は高まります。
(研修資料より。ユーザ体験が損なわれることを Apple はとても嫌う)
前述の App Store Review Guideline でもHIGはアプリが従うべきガイドであると明記されています。
ただ、弊社経験の感触ですが、App Store Review Guideline ほどの重要度は高くないように思います。従っていないと思われるアプリも実際たくさんありますので。リジェクトを極力避けるという意味で目を通すべきですが、UIを設計するデザイン担当の方以外は副読本的な捉え方で良いかも知れません。
iOSアプリのプランニング
公式の副読本的な読み物は他にもあります。次に紹介するのはiOSアプリのプランニングというドキュメントです。
iOSの世界に相応しいiOSアプリをどのように開発していくのか、初めてiOSアプリを開発する方に向けたドキュメントという位置づけです。下図のようにページ中程に、開発観点でのアドバイスがあります。
ベストプラクティスに違反するアプリの仕様とならないよう最初から意識しておくと良いでしょう。実装方針を誤ってしまう…といったことが避けられます。
iPadOSアプリのプランニング
前述の iOSアプリのプランニングのiPad版です。名称はそのまま。iPadOSアプリのプランニングと言います。iPadOS に特化した文書です。
共通している箇所も多いですので、iPad専用アプリを作る場合は、最初からこちらを確認すれば良いでしょう。iOS/iPadOS両対応の場合は、大変ですが両方ですね。
Apple 公式の最新情報を常に確認する
ここまででご紹介した App Store Review Guideline も Human Interface Guideline も結構頻繁に更新されます。WWDCが開催される毎年6月や、新製品の発表のある9,10月あたりは要注意。それ以外でも Apple の文書は度々更新されます。
そこで読むことをお勧めしているのが、最新情報を配信してくれるニュースとアップデートのぺージです。冒頭に紹介した App Store Review Guideline が更新されたらこのページに掲載されます。
(2023年6月に更新された際の掲載内容。どこが変わったのか詳細が示される)
他にも、App Store に審査提出する時のSDK/Xcodeの制限情報や、全てのアプリに求められる新たな条件等の情報もこのページに掲載されます。
(2023年4月からXcode15以上でなければ審査提出すらできなくなるという重大なことがシレッと書かれている)
エンドユーザ企業というよりもアプリ開発会社が見ておくべきページといえます。この確認を怠ると、無駄なリジェクトを受ける可能性が高まったり、そもそも審査提出すらできず手戻り作業が発生する等の事態に遭遇することになります。
想定外の工数増を強いられる変化もありますから、必ずチェックしなければなりません。WWDCのキーノートや各セッションの動画を普段見ている開発会社や開発者の方は問題ありませんが(情報感度が高い)、そうでない場合は要注意です。
アプリ開発案件の商流の間にいるSIerやコンサル会社におかれては、再委託先の開発会社がこの種の情報にアンテナを張っているかどうかはチェックしたほうが良いでしょう。
ちなみに本ページを「更新されていないか？」と毎日チェックするのは大変です。なので、公式のRSSを購読することが推奨されます。
フィードリーダを使っても良いですし、slack 等のチャットサービスでRSSを解釈して通知してくれるBOT等を導入しても良いでしょう。
(RSSを購読すれば更新があればすぐ分かる。macOSのRSSフィードリーダ Vienna)
Apple が開発会社に届ける情報を確実に受け取り、取り残されないようにしたいものです。
開発会社が見るべき情報については過去の投稿でも言及しています。ニュースとアップデートを開発者向け専用アプリで閲覧することもできますので、併せて確認して下さい。
誰が何の情報をみるべきか
ここまでで紹介した情報は全て公式のものです。審査について心配する前に、そしてググるより前に、確認すべき情報が沢山あり、それを Apple 自身が膨大に発信してくれていることが理解頂けたと思います。
理想は関係者全員が全部の文書に目を通すことですが、普通は余り現実的ではありません。そこで、どの公式ドキュメントを誰が読むべきか、重要度別に表にまとめましたので参考にして下さい。
◎が絶対、◯が可能であれば、- は興味があれば、ぐらいの感じです。
| エンドユーザ企業 | デザイン会社 | 開発会社 | |
|---|---|---|---|
| App Store Review Guideline | ◎ | ◎ | ◎ |
| App Review | ◎ | ◯ | ◯ |
| Human Inteface Guidline | ◯ | ◎ | ◯ |
| iOSアプリのプランニング | ◯ | ◯ | ◯ |
| iPadOSアプリのプランニング | ◯ | ◯ | ◯ |
| ニュースとアップデート | – | – | ◎ |
アプリを外注し、デザイン会社と開発会社が分かれてるようなプロジェクトを想定しています。プロジェクト体制によって「会社」を「担当」や「部署」と読み替えて下さい。
以上、リジェクトを避けるために読むべきドキュメントを紹介しました。
iOSが日本に上陸した2008年当時は、この種のドキュメントは余り整備されていませんでした。App Store Review Guideline もいい加減なもので、理不尽・不可解なリジェクトも多々聞かれました。(弊社も色々体験しました😅)
が、現状は違います。
ドキュメントも豊富で、事前の準備でリジェクト回避が相当可能になります。面倒くさがらずにドキュメントを読み、Apple の審査で合格を勝ち取れるようにしていきたいものです。
