WebView アプリで既存 Web サイトをラップした iOS アプリのストアレビュー時に、
App Store ガイドライン 2.12 でリジェクトされた経験をされた方は少なからずいることと思います。
先日、開発案件でこのリジェクトに遭遇しましたが、無事アプリをリリース出来ましたので、その時の解決方法を残しておきたいと思います。
目次
- App Store ガイドライン 2.12 詳細内容
- App Store ガイドライン 2.12 対策ロードマップ
- App Store ガイドライン 2.12 対策詳細
- まとめ
App Store ガイドライン 2.12 詳細内容
Apple Store ガイドライン 2.12の内容は以下の通りです。
ユニークではない、あまり有用でない、単にウェブサイトをバンドルしたもの、永続する娯楽価値を提供しないアプリケーションはリジェクトされます
自分の制作したアプリが あまり有用でない と言われるとショックですが、Web アプリを制作しリジェクトとなった場合の本題は、次の 単にウェブサイトをバンドルしたもの の一言に尽きると思います。
この事は開発者泣かせではありますが、単にウェブサイトをバンドルしたもの は Web ブラウザでサイトを閲覧すればいいだけなのですから、わざわざアプリ化する意味がなく、結局 App Store ガイドラインの あまり有用でない という表現は正しいことになります。
しかし、諸事情によりこういった あまり有用でない Web アプリをリリースしなければならない場合、どうすればいいのでしょうか。
次項からその解決方法を説明したいと思います。
App Store ガイドライン 2.12 対策ロードマップ
単にウェブサイトをバンドルしただけのアプリを申請し、その結果 2.12 リジェクトとなったときに立てた対策ロードマップは以下のとおりです。
- プッシュ通知を実装
- Apple レビュワーへの問い合わせ
- 独自メニューと共有機能を実装
- 設定画面を実装
- コンテンツ表示の UITableView 化
App Store ガイドライン 2.12 対策詳細
プッシュ通知を実装
プッシュ通知はアプリ固有の機能です。Web サイトをラップするだけのアプリでも、サイトの更新やサービスのアップデートは必ず発生するので、これら更新情報を配信する機能をアプリに持たせることで、2.12 のリジェクトに対し一定の効果があります。
ただし、これだけでは あまり有用でない ことが理由でリジェクトとなりました。しかしこの時点で 単にウェブサイトをバンドルしたもの ではなくなりました。
Apple レビュワーへの問い合わせ
プッシュ通知だけではリジェクトとなる可能性は十分考えられていたのですが、念のため、「なぜ、アプリ固有の機能であるプッシュ通知を実装したにも関わらず、 2.12 に抵触したのか」という問い合わせを行いました。
この問い合わせは、なぜダメだったのかを知るためではなく、どうすればリジェクトにならないか、をレビュワーに提案してもらうことが目的でした。
このアクションを早めに行うことで、レビュワーに従ってアプリを改善した結果が再びリジェクトとなった場合、訴求することが可能となります。
独自メニューと共有機能を実装
アプリの画面が WebView だけではブラウザそのものなので、アプリ専用メニュー として新しく View を作成し、そこに「進む」「戻る」「共有」と言った機能を追加します。比較的短時間で実装可能なうえ、リジェクトに対し一定の効果があると思いますが、この程度ではリジェクトとなりました。
設定画面を実装
アプリの画面数が1画面だけでは、やはりブラウザと大差がありません。そこでアプリに設定画面の UIViewController を追加 し、上記アプリ専用メニューから設定パネルへ遷移するボタンを追加し、2画面構成 とします。
設定画面では、「プッシュ通知のON/OFF」「サポートページ」「アプリを評価する」「カラースキーム変更」といった、最小リソースで実装が可能な機能を追加します。
このことが アプリを改善した結果 と評価されリリースとなりました。
コンテンツ表示の UITableView 化
Web コンテンツを一旦 CoreData に保存し、UITableView で表示することにより iOS ネイティブ特有の表現を行うためのプランでしたが、設定画面を実装することでアプリがリリースとなったため不必要となりました。
ここまでやれば、もはや 単にウェブサイトをバンドルしただけ のアプリではなくなりますが、この工程は工数が大幅に増大するため、あくまで最終手段として考えていました。
まとめ
この記事を書いた目的は、こうすれば Web をラップしただけのアプリを開発したい場合、こうすればリリースできる、といったことが言いたかったのではありません。
Web サービスをアプリ化しようとする企画段階で、明らかにガイドライン 2.12 に抵触する恐れのあるアプリである場合、アプリ自体の開発を断念し Web サービスそのものの強化や見直し、リーチの拡大に注力するのが賢明だと言うことです。
この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。