0. 概要
この度、新規のネイティブアプリをiOS/Androidの両プラットフォームにてスケジュール通りにリリース可能な（Apple/Googleによる審査が通過した）状態にすることができました！
※審査時間がとても早かった（通常、初回は2週間ほどを見るのが良いと言われていますが、提出から通過までなんと1営業日…！）というラッキーはありましたが、間違いなく開発チームの努力の成果だと思っています！
チームの中でも私個人は今回、技術的な側面ではなく、アプリが審査基準を満たせているか？審査提出に必要なタスクは何か？といった側面において、リスク回避に努めました。スケジュール通りに何かを成し遂げる際は「不確定要素」をどれだけ減らしていくかといったことが重要だと思いますが、アプリのサービスリリースにおいて最大の不確定要素は「審査でのリジェクト」になるかと思います。今回得た知見で、どなたかの「不確定要素」を減らす手助けが出来れば…！という気持ちです。
1. 公式のガイドラインを読む
兎にも角にもまずは公式のガイドラインを読みました。入り口が分かりづらかったり、各所に情報が散らばっていたり、色々と思うところはありますがまずは一読しておいた方が良いと思います。
iOS
特に注視したのは、App Store Reviewガイドラインです。審査はこちらの基準に則って行われるはずなので、少々文量はありますが、端から端までしっかり読むのが良いと思います。中でも気になった点を以下に紹介しておきます。
アカウントの作成に対応したAppの場合は、App内でアカウントの削除もできるようにする必要があります。
こちらに公式のプレスが載っていますが、アプリ内にてアカウント作成機能を提供している場合は、2022年1月31日よりApp内のアカウント削除機能の提供が必須要件になっています。引用した文章は太字にもなっておらずしれっと記載されています。ググるといくつか記事も見当たりますので、iOSエンジニアの方からすると知っていて当然のニュースという感じかもしれませんが、アプリ開発未経験者からするとあまりにも不親切…と思いました。
ユーザーコンテンツやアプリ内課金がある場合などアプリの要件に合わせて、各項目をしっかりチェックする方が良いと思います。上記のように機能開発が必要なのにも関わらず、審査でリジェクトされるまで気づけないと精神的にかなりきついところがあると思います。当然リリース日は伸びてしまいますし、急ぎで作った機能は品質の面などで不安になってしまうでしょう。今回は他の開発メンバーがプレスに気づき比較的早い段階で対応できましたが、不安要素は早め早めに潰しておくと良いなと改めて感じました。
Android
- https://play.google.com/about/developer-content-policy/?hl=ja
- https://support.google.com/googleplay/android-developer/answer/9859152?hl=ja
こんなことを言うと怒られてしまうかもしれませんが、個人的にAndroidはiOSほど情報が上手くまとまっていないように思いました。昔はそもそも審査がなかったり、審査基準がAppleと比較すると緩いという話もあったりしますし、整備がまだまだ行き届いていないのかもしれません。
私は特に１つ目のデベロッパーポリシーの方を注視しました。こちらもかなりの文量ですが、iOS同様しっかり読むことをおすすめします。中でも気になった点をいくつかご紹介します。
著作権で保護されているコンテンツを使用する場合は、その権利の証拠を示すよう求められることがあります。
例えば、他社からアプリ開発の委託を受けている場合や他社とアライアンスを組んでいる場合など、デベロッパーアカウントの情報と直接に関係のないロゴを使用していると、権限を保有しているのか審査で尋ねられることがあるそうです。私達のアプリは前述の例でいうところの後者に該当するサービスなのですが、幸いなことに今回は指摘がありませんでした。こういった権利周りのセンシティブな情報の外部公開にはそれなりに時間がかかると思います。Googleの審査チームへの事前フォームがあり、ファイルを添付してメッセージを送信できるようになっているので、用意可能な場合は必要書類をフォームで提出しておくと良さそうです。
アプリの Google Play 掲載情報に記載されている主体（デベロッパーや会社等）がプライバシー ポリシーに明記されている、もしくはアプリ名がプライバシーポリシーに明記されている必要があります。
1つの会社でいくつもサービスを持っている場合、全社で共通のプライバシーポリシーを使用しているという場合があると思います。私達が正に同じ状況にあり、該当のプライバシーポリシーにアプリの名称の記載がなかったので困りました。結論、私達はサービス固有のプライバシーポリシーを用意して審査に臨むことにしました。そのため、アプリ名称が記載されていないことでリジェクトされるかどうかは実際にはわからないですが、リスクを可能な限り回避するためには対応しておく方が良いと思います。アプリで使用している第三者サービスのプライバシーポリシーを調査する必要があったり、法務に内容を相談する必要があったり、一朝一夕で用意できるものではないと思うので可能な限り早めに対応しておくと良さそうです。
すべてのデベロッパーは、すべてのアプリについて、ユーザーデータの収集、使用、共有に関する詳細な説明を、データセーフティセクションに明瞭かつ正確に記載する必要があります。
こちらに詳細記載されていますが、データセーフティセクションというものが新設され2022年4月までに内容を申告する必要があるそうです。PlayConsoleにて自身のサービスのプライバシーポリシーをもとにいくつかの質問に回答する形なので、物量はありましたが内容自体そこまで大変なものではありませんでした。
こちらのプライバシーに関する情報提供についてですが、iOSにも似たようなセクションがあり2020年12月より提出が必須になっています。詳細はこちらに記載がありますのでご参照ください。
2. 審査に必要な準備を知る
審査に提出するには何をする必要があるのかチェックリストのようなものがあれば一番良いのですが、残念ながらそういったリストの用意はありません。※Androidの場合はPlayConsoleのダッシュボードの画面にチェックリストが表示されています。
前述のガイドラインをよく読んで審査基準を満たしているか確認するとともに、スクリーンショットや掲載文などのアプリのメタ情報を用意します。公式のヘルプページを見つつ用意する形になると思いますが、実際にデベロッパーコンソールやアプリストアを見つつ、何が必要かどのように使われるのかイメージを掴みながら用意するのが手っ取り早くかつ最も分かりやすいと思います。
- iOS
- Android
ここで忘れがちだったり後回しにしがちだったりするので注意しておきたい点なのですが、審査に提出する（審査をしていただく）ということは審査を行うことのできる環境が必要です。ECなどアプリ上で金銭のやりとりが発生する場合や、WEBが先行で既に本番稼働していてサーバーサイドはアプリと共通といった場合などは、審査の際に実際に操作されてしまうと困るという事情があると思います。私達は後者の例にあてはまったのですが、レビュー時に操作しないでほしいという旨の注意書きと、YouTubeに限定公開した機能説明の動画のリンクを提出するという手法で乗り切りました。実際、審査中に該当の操作を行ったログはなかったですし、審査も無事に通過したので有効な手段ということが言えると思います。MacがあればiMovieなどを使って手軽に動画作成もできるのでおすすめです。
また、アプリ内にアカウントの作成機能がある場合は、審査用にログイン可能なデモアカウントを提出する必要がありますのでご注意ください。私たちの場合、SMS認証が必要なサービスなのでどのように対応するか困ったのですが、FirebaseAuthを使っていたので架空の電話番号と認証コードを用意して対応しました。便利！
3. 最後に
いかがでしたでしょうか？アプリエンジニアの方からすれば知っていて当然のことかもしれないですが、初見の人間からすると知らない、見えない分非常に神経を使う作業でした。
アプリのスクリーンショットは熟練のデザイナーさんが対応してくださったり、掲載文は企画の方が他サービスの調査を踏まえつつ用意してくださったり、品質はQAエンジニアの方が綿密なテストを実施して担保してくださったりと色々な方の協力があったので、私は漠然とした不安を抱えながらも、安心して全体のチェックに時間を割くことができました。アプリの要件としても、金銭のやりとりやユーザーに寄るコンテンツの作成だったり基準の厳しい機能がなかったのも初心者としては対応しやすかったという面もあったと思います。
稚拙な文で大変恐縮ですが、ここまで読んでくださりありがとうございました。私と同じように、これから世の中にアプリを出していこうという方の少しでも手助けとなれば幸いです。また、こちらの文章に記載している記事や公式の審査基準等は今後も更新されていくはずなので、常にApple/Googleの最新の公式ページを確認したり、情報をウォッチしていく必要があると思います。他にも気をつけるべき点などが思い浮かんだ方はぜひ実体験なども踏まえてコメントしていただけると大変ありがたいです。