この記事は何か？
既存のWebサービスをiOS / AndroidをWebViewでリリースしたので、やったことや反省点書いていきます。基本的には1人で実装してます。
なぜアプリを作る時Web Viewという選択をしたのか？
アプリを作るやり方は大きく分けて４通りあると思います（上から工数がかかならそうなもの）
- PWA型：Webサイトをホーム画面に追加して、アプリのように使う（アプリというかは微妙だけど）
- WebView型：ネイティブのシェルだけ作って、中にWebサイトを表示する
- クロスプラットフォーム型：React Native、Flutterなど
- ネイティブ型：Swift、Kotlinなど
PWA型はすでに実装していたので、候補としては、2,3,4が上がりました。
その中で、WebViewを選んだ理由は
- Webサイトとがあるので最小工数でリリースできるから
- 管理することが増えるから（Webとアプリの両方の修正が必要）
が、主な理由です。
アプリのリリース定義とは
どのような状態になればアプリをリリースできるのか？を2つ定義してました
- 開発イテレーションを落とさない
- アプリストアで必ず高評価を得る
まず、開発イテレーションを落としてはダメです。スタートアップの強みは、いかにイテレーション早くデプロイするかだと考えてます。
なので、アプデのたびに審査を出すのはNGでした。その点、WebViewはいつでも手軽にデプロイできるので最適でした。
次に、アプリの高評価を得ることはアプリの信頼につながります。
なので、リリース前に、Webでどのタイミングに表示したら高評価（星４以上）になるのかをABテストしてました。
具体的には、特定のタイミングで、このアプリを気に入りましたか？Popupを出して、星１ー５まで選ばし、高評価を得たタイミングのデータを集めてから、OSの本物のレビューPopupを出してレビューしてもらうやり方です。
これをすれば、必ず高評価になると考えました。
実際に行ったこと
実際に行ったことは以下です
環境構築
- GithabActionで、Stg or 本番 / Ios or Androidに出し分けてビルドできるようにした
- ビルドしたものを、iOS は TestFlight、Android は Google Play の内部テストへ自動でアップロードするようにした
- Stg環境を作り本番前に確かめられるアプリを作った
設定
- AppleStoreでアプリなど作成
- GooglePlayでアプリなど作成
- アプリのアイコン・表示名を設定
表示・操作の調整
- 画面のダブルタップ・ピンチで拡大しないようにした（WebView なので、拡大すると戻せなくなるため）
- セーフエリアを調整（Android でヘッダーやボタンがステータスバーに隠れて押せなかったため）
- 画面を縦向きに固定
- 下にスワイプでリロード（WebView には標準のリロード機能がないため）
パフォーマンス改善
- 画像や動画容量の圧縮（Webよりアプリの方が読み込みに時間がかかった）
- 電力消費の削減（電力消費が激しいスマホは触りたくないので）
- 画面ダブルタップで、拡大しないように（WebViewなのでダブルタップで拡大しちゃて戻せなくなる問題があるので）
ログイン
- ソーシャルログイン（Google・X・LINE）でブラウザに飛ばないようにした
- Apple でログインを追加（入れないと iOS でリジェクトされたため）
- ログインの有効期限をアプリは 90 日に延長
アプリの機能
- ディープリンク化（メール認証などのリンクをアプリで開けるようにした）
- プッシュ通知（FCM）に対応し、管理画面から配信できるようにした
- ★4 以上をつけた人に、ストアのレビュー画面を出すようにした
- ハフティクスに対応
- Android でお支払い方法に Google Pay を出せるようにした
広告計測
- Adjust を導入（インストールがどの広告から来たかの計測、登録・課金の送信）
- ATT（トラッキング許可の確認）に対応
- アプリ内の成果が Web の広告タグと二重に数えられないようにした
段取りでよかったこと
アプリをリリースするにあたり段取りでよかったことを書きます。
アプリを未完成で審査に出たこと
まず、リリースする上で潰さないといけないのはコントロールできない外部要因です。
アプリを完璧に完成させてから審査に出してはいけません。必ずリジェクトされます。
なので、未完成な状態で現状何がリジェクトされるのか確かめないといけません。
基本的に、審査は１度で通りません
審査が必要があるものを基盤だけ入れて審査に出す
WebViewで審査が必要なものはネイティブコード側なので、Push通知やハフティクスは審査が必要になります。
なので、まだ、本番実装はしないがネイティブコード側の基盤だけ実装して、審査に出すことであとはWeb側でデプロイをコントロールできます。
もっとこうすればよかったと思うこと
課金などの主要機能を早めにQA
AndroidのGoolgePayに、GoogleWallteの審査があることを知らずに、リリースの直前に気がつきました。
課金まわりは核となる機能なので、もっと核となる機能のQAを早めにみておくべきできた。
stgでは大丈夫だけど、本番だとNGなことは多々あるので、本番でもしっかりチェックするべきでした。
あと、周りをもっと巻き込んでQAを協力してもらう体制をつくればよかったです。
Adjustの連携がめっちゃ大変で工数が思ったよりかかった
リリースにマストではないのですが、広告を打っているので、アプリ内広告に対応するAdjustの実装が必要でした。
実装自体は難しくないのですが、概念や設計がとても難しく思ったより時間がかかってしまいました。
特に、Web to App（Web広告できた人が、Webサイトのダウンロードボタンからアプリに移った場合でもWeb広告にCVを返す仕組み）がとても設定が面倒で、広告はデバッグがめちゃくちゃやりにくいので、あってるのかよくわからなく悩む時間が多くなってしまいました。
Adjustの設定を後回しにしてしまったのですが、広告の担当者との連携など外部要因が多いことだったので早めに潰せばよかったと思います。
最後に
WebViewをネイティブのシェルで包んで表示するだけだと思ったのですが、思ったよりやることが多く大変でした。それでも10営業日くらいではできたので、ネイティブで作り直すより断然早くリリースできたと思います。
この経験をもとに、いろんなアプリをリリースしていきたいと思います！