こんにちは。モバイル基盤部のこやまカニ大好きです。

先日行われた DroidKaigi 2021 で「2020年代の WebView 実装」というタイトルで発表させていただいたので、今日はその発表を簡単にまとめようと思います。当日聴いて頂いた参加者の方、本当にありがとうございました。流れていくコメントを眺めていると他社でも WebView 増殖はやっぱり発生するんだなあという気持ちが沸き起こり、胸が熱くなりました。

現時点で話せる内容は大体話せたと思うので、この記事では DroidKaigi公式の動画と発表資料の共有、当日うまく答えられなかった質問への回答だけ記載しようと思います。最高の WebView を作る作業はまだ継続中ですので、完全版 WebView に関しては完成し次第別記事でお知らせいたします。

動画

https://www.youtube.com/watch?v=IOnpHyOg5sc

資料

https://speakerdeck.com/nein37/saikou-no-webview-2021

補足

動画(とコメント)を見直していて、なぜそこまで WebView が必要なのかという部分についてうまく説明できていなかったと思ったので少し補足します。

クックパッドアプリの WebView の用途は大きく分けて３つ存在します。

新規登録などの一部の特殊な画面
- 新規登録画面は過去ネイティブで実装されていましたが、2019年に Web ページ側の新規登録フローを改善した際にアプリでも WebView から新規登録するように変更しました
- この部分の WebView は役割が非常にはっきりしていて分かり易く、クックパッドアプリの WebView の中でもかなり良い使い方だと思います
課金導線(LP)の表示
- LPはキャンペーン施策によって画面表示を一斉に、大きく切り替えたい場合があります
- 利用規約、プライバシーポリシーの変更や無料期間の修正などは即時切り替える必要があります
APIが存在しない機能の表示
- 古いサービスなのでそういうページもあります…
- これはリソースを割けばネイティブなUIに置き換えられますが、リソース配分など様々な理由で現在でも WebView として提供しています

このうち、 1. の用途についてはこれまでほとんど問題なく動作していました。もともとここだけ Kotlin + VIPER で実装されていたという事情もありますが、ネイティブ実装された画面に遷移しづらい新規登録画面ということも大きいと思います。この画面は WebView でかなりうまく動いているので、これからも WebView のままになると思います(10年間 WebView のままかどうかはわかりませんが)

2. の課金導線ページ表示はかなり複雑です。アプリ内の様々な箇所から課金導線ページへの遷移があり、課金導線ページ内からもレシピページなどネイティブ実装された画面への遷移が存在します。課金導線ページはコンテンツの表示をサーバサイドで細かくコントロールしたい事情があるので、これからも WebView で実装され続けることでしょう。この課金導線ページの表示をできるだけ簡単に実装できるようにするのがクックパッドアプリにおける最高の　WebView　への道だと考えています。

3. が存在する理由は単純で、 WebView でしか表示できないコンテンツがあるため WebView を使って表示しています。このパターンのWebページからはネイティブ実装されたレシピ詳細画面や検索結果画面への遷移が頻繁に発生するため、最も複雑な実装になっています。今回の発表にあった Routing に実装したネイティブ画面への遷移処理のほとんどは、このパターンのWebページの表示のために必要になった実装です。 WebView 以外の解決方法としてネイティブ画面で再実装することもできますが、アプリ開発に使えるリソースは有限です。アプリが大きくなるにつれて、大きくコストを割けない機能というものはどうしても出てきます。そういったコンテンツの表示をサポートし、ユーザーに価値を届けられる仕組みとして WebView は必要だと考えています。

クックパッドアプリの実装では 3. 用途の WebView に若干 2. の機能が混ざったりしているので、今後の改修でどんどんシンプルで使いやすい WebView にしていく予定です。