メグリでプランニングを担当している篠キチです。

Webview (ウェブビュー)という言葉はアプリ開発に関わらないとあまり聞く機会がないと思いますが、これはアプリの中にウェブブラウザの機能を持った枠を作る機能のことを言います。iOS、AndroidともにOS側がこのWebview機能を標準のパーツのような感じで用意してくれています。

詳しくはMGReのサイトにWebviewについて解説した人気コラムがあるので、そちらを読んでいただくとわかりやすいと思います。

ちょっとマニアックな話をすると、アプリ独自でウェブブラウザ機能を1から作ることは基本的にNGなので、ブラウザアプリを作ろうとするとWebviewをベースにしてカスタマイズをすることになります。

広告ブロック機能などで人気のBraveなど、iOSでも標準のMobile Safari以外のブラウザアプリを使うことができるようになっていますが、ブラウザとしての基本部分はWebviewを使っているはずなので、ブラウザ性能的に大きな違いが出ることはあまりありません。

Webviewだけで作られたアプリは承認されないことがある

Webviewを使うと既存のWebサイトのコンテンツを流用してアプリ機能のように見せることが簡単にできるため、実はかなり多用されているアプリ機能だったりします。

弊社が開発しているアプリプラットフォームのMGRe(メグリ) でもWebviewを使った機能は多くあり、先日もMGReのニュース機能のアップデートという形で表示するニュースとしてWebviewを選択できるようにしました。

このWebviewの便利さを知って「Webviewだけでサクッとアプリをリリースしたい」という依頼をいただくことがしばしばあります。

ただ、これはアプリ申請時にNGになるケースがあります。

アップル社がApp Storeに掲載するアプリの審査を行うにあたって、公開しているガイドラインがありますが、この中にWebviewだけで構成されたWebサイトの寄せ集めのような構成のアプリは提供できない、つまり審査でリジェクト(不合格) となると明記されています。

Webview利用は避けるべきなのか

このアップル社が公開しているガイドラインを知り、Webviewを使ったアプリ開発はそもそもリスクがあり、利用を避けるべきなのか？ といった問い合わせをいただくこともあります。

結論としては使い方次第と我々は考えていて、実際Webviewを使っているからリジェクトされたというケースは弊社でお手伝いしているアプリに関してはいまのところありません。

ガイドライン上でも「Webサイトを単に再パッケージしたようなもの」「ユニークでもAppらしくもない」ものをNGとしていて、アプリ全体がブラウザでWebページを見てるのと変わらない、ただのリンク集みたいな内容のアプリがリジェクト対象です。

Webviewの基本機能はブラウザとしてWebページを表示することですが、Webview自体をカスタマイズできますし、これを使ってアプリ内で提供している機能がしっかり作り込んだり、あるいはWebページ側でアプリ用の機能を作り込むなどの工夫がされていれば、基本的に問題はないと考えています。

MGReを導入いただいているサンリオ様の『Sanrio＋』はMGReが提供している標準機能を使いつつ、プリズマティクス様の協力のもとWebの技術を使って高度に作り込まれた多くのアプリ向け機能をWebviewで提供しています。

このことは3社共催で行ったウェビナーでも詳しく語られているので、ぜひご覧ください。(40:50あたりから)

すべてのWebサイトが正常に動くわけではない

これは結構盲点なので注意する必要があります。

Webviewもブラウザの一種なので基本的には動くと考えていいんですが、典型的な例としてtarget="_blank" で新規タブ(ウインドウ) を開くページはWebview側で工夫しないとそのままでは動かなかったり、想定外の挙動をすることがあります。

またWebサイト向けにサービスを展開しているところでも、アプリのWebviewでの動作をサポートしない(保証しない) というものもあります。

有名な例としてAmazon Payが挙げられます。
Amazon Payはセキュリティ上の理由でWebviewでの利用を非推奨としていて、アプリ内ブラウザでAmazonPayを提供する場合はSafariview/Chrome Custom Tabsを使い、通常のWebブラウザとは異なるセキュアな動作となるよう個別対応することを推奨されています。

これは通常アプリだけでなくECサイト側での対応が必要になり負担が大きかったのですが、MGReではアプリ側の設定のみでAmazon推奨方式でAmazonPay利用を可能にするアップデートを行っています

また、オンラインフィッティングサービスとしてアパレルECサイトに多く導入されているメイキップ社のunisizeはアプリでの動作をサポートしていませんでしたが、これもMGRe側でWebviewのカスタマイズ対応を行うことで正式にアプリ上でも動作できるようになっています。

このようにWebviewがブラウザとはいえ、アプリ内で表示するWebサイトがきちんと動作するかどうかは検証する必要がありますし、Amazon Payやunisizeの例のようにカスタマイズ対応しないと期待した動作がアプリで得られないということが起こります。

Webviewで無制限にWebアクセスができると成人向けアプリになる

現在のガイドライン上ではこれに該当する項目は見つけられなかったんですが、Webviewを使ってアプリ内で表示するWebサイトにドメイン等で制限をかけていなかった場合に、審査時にレーティングを17＋（成人向け）に設定するよう指示を受けたことがあります。

アプリ用のWebコンテンツがアプリ専用に作られていて、そもそも外部に遷移する導線がない場合は特に問題ないですが、既存のWebサイトをそのまま表示している場合だと、リンクをたどり続けることで無限に遷移することができます。

これがアプリで成人向けのWebサイトにアクセス可能な手段を提供してしまっているという判断だと考えられます。リジェクト要件ではないですが、アプリによっては成人向けのレーティングでのリリースを避けたいものもありますので注意が必要です。

アプリとWebのヘッダメニューが2重に表示される

これは典型的なWebviewあるある話だと思います。ちょっと古い画像ですが、こんな感じになるやつです。

これについては以前、個人のnoteに書いたことがあるので興味あればご覧ください。

対処法はいくつかあり、アプリのWebview側で表示しているWebサイトのヘッダを消してしまう方法もありますが、あまりスマートではないのでおすすめはしていません。

Webview利用を積極的に検討すべきシーン

典型的なパターンとしてあるのはECサイトのアプリ組込です。

ECサイトは規模も大きく、機能が多岐にわたります。また会員認証や決済などシステムに高い信頼性が要求されます。

このようなサービスをアプリでも同様に提供しようとすると、相当なコストがかかりますし、リリースした後の維持費・運用負担も考えなくてはいけません。

このことも以前、個人で書いたnoteにも詳しく書いています。

Webviewをカスタマイズし付加価値をつける

しかしECサイトも単に表示するだけでは「Webサイトを単に再パッケージしたようなもの」と判断される可能性が残ります。

また、ユーザー視点で考えてもわざわざアプリをインストールして利用するからには、Webサイトをブラウザで開く以上の利便性を当然期待します。

MGReではWebviewをカスタマイズしてECサイトへ自動ログインさせる機能を提供し、アプリの付加価値を高める対応を多く行っています。詳しく書かれたnote記事があるのでそちらもご覧ください。

こういった対応はWebviewに限らず、アプリ側にもWeb側(この場合はECサイト) にもカスタマイズ開発が欠かせなくなってきますが、アプリプラットフォームでありながらMGReのようにカスタマイズができるサービスは多くないと思います。

Webview利用であればWebサイトの流用だけで済むので、カスタマイズなどは考えなくてもいいと思われがちですが、きちんと審査に通るというレベルでの対応から、同じWebサイトの提供でもユーザーにとって付加価値の高いサービスへと引き上げられるようなカスタマイズが可能な開発会社・プラットフォームを選ぶことが実は重要です。

弊社ではWebview活用はもちろん、アプリ開発に関する様々な悩み事・相談に経験豊富なスタッフが対応可能ですので、ぜひお気軽にお問い合わせください。