【iOS】4.2 Minimum Functionalityの内容と対応事例まとめ

3 min read読了の目安(約2700字

はじめに

iOSアプリを開発している場合、一番遭遇したくないのが4.2 Minimum Functionalityのリジェクトだと思います。
今回は、開発者泣かせと名高い4.2 Minimum Functionalityとは何か?とその対応事例について記事にしたいと思います。

「4.2 Minimum Functionality」とは?

そもそもの話として、AppStoreにアプリを公開するためには、App Store Reviewという審査を通さなければなりません。
法令や内容等、様々な観点からアプリをチェックされます。

そんなApp Store Reviewですが、なかなか厳しい基準であることが知られていおり、不合格の場合は「リジェクト」という形でAppleから返事が来ます。
中でもこの4.2 Minimum Functionalityは個人開発者にとっては最もキツイ内容です。

https://developer.apple.com/jp/app-store/review/guidelines/#design

ガイドラインによると以下のように定義されています。

4.2 最低限の機能

Appを作成する際は、Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するようにしてください。特に便利でも、ユニークでも、「Appらしく」もない場合、そのAppをApp Storeで提供することはできません。Appが何らかの継続的な楽しみを提供できない場合、承認されない可能性があります。Appが単に曲または映画の場合は、iTunes Storeに提出してください。Appが単に書籍またはゲームの攻略本の場合は、Apple Books Storeに提出ください。

要するに「これコンテンツを表示させるだけだったり、機能が少なすぎたりでアプリにする必要ないよね。Webでよくね?」といった内容です。

これの何が厳しいかというと「どうすればよいかが不明確」だからという点に尽きます。

例えば、他のリジェクトだと「4.0 - Design」といいたものがあります。
以下、過去に実際にリジェクトに遭遇した場合の詳細です。

Your app offers Sign in with Apple as a login option but does not use the appropriate Sign in with Apple button design, placement, and/or user interface elements. Specifically:

これはAppleサインイン、という機能をアプリに持たせていたのですが、その際の「サインインボタンのデザインがちょっとおかしいよ」といった内容でした。
このように大概のリジェクトは「どう対応すればよいか」まで明示されていますが、4.2 Minimum Functionalityに関しては「どこまで機能を追加すればOKか」や「何を直せばOKか」が明確でないです。

そういった内容も相まって、開発者泣かせのリジェクトとして扱われています。

対応事例

前述の通り4.2 Minimum Functionalityには明確な対応方法がないため、突破する方法は千差万別です。

そこで、いくつかの対応事例をピックアップしたいと思います。

機能追加で対応

https://hawksnowlog.blogspot.com/2017/07/counterd-for-guideline-422-design-minimum.html

https://note.com/pauchel_candy/n/n88fdcb105936

機能追加で突破したケースです。
ポイントは「アプリならではの機能は何か」を意識することだと思います。
例えば「端末内にデータを保存する」だとか「カメラや音声アクセスをする」のようにWebでできなくもないけど、スマホアプリの方が明らかに便利だよね、という機能を追加すると突破しやすく感じました。

コンセプトの明確化や説明資料を充実させることで対応

https://useful-bee.com/guideline-4-2-design-minimum-functionality/

https://dentakurou.hatenadiary.org/entry/20180721/p1

https://qiita.com/ToyokazuUda/items/7fa4508044360ebd7b01

レビュー担当者にアプリのコンセプトがしっかり伝わっていないのではないか?という発想のアプローチです。
ある程度機能が充実している場合「このアプリは他のアプリとはここが違うんだ」や「こういう価値がある」といった内容を丁寧に説明することで突破できることがあります。
多少交渉スキルが必要になりますが、機能に自信がある場合はチャレンジしてもいいかもしれません。

審査時期やBundle IDの変更で対応

https://kanasys.com/tech/669

https://applimeshi.info/appstore-review/

ちょっとメタ的な対応方法なので、はっきりと効果があるかは不明です。
App Store Reviewも対応しているのは人間です。
そのため、レビューが立て込む繁忙期を狙って申請を出すことでチェックが甘くなることを狙う方法です。

また、人によって審査基準に多少のずれがあるのでBundle IDを変更して別物のアプリとして申請しなおすことで、レビュー担当者そのものを変えてしまうという荒技で突破した例もあるようです。

ただ、仮にこの方法で審査を通したとしても以降のバージョンアップで同様のリジェクトを受ける可能性があるのであまりオススメはしません。
Bundle ID変更については一部記事では非推奨とされていたりします。

まとめ

今回は4.2 Minimum Functionalityの内容と、対応事例について紹介しました。
正直なところリジェクトされたアプリの内容によって、取りやすいアプローチは変わってくると思います。
リジェクトされてから、実際に審査を通した例は意外と数が少なかったので、参考になれば幸いです。