FlutterアプリをPWA化しようとした理由

端的に言うと、主にWebベースの基本的なアプリ（既にGoogle Play Storeで公開中）について、Apple App Storeの費用を回避したかったのです。私のアプリは趣味のプロジェクトとして始まったもので、意味のある収益を上げているわけではないので、$99/年のApple Developer Programの費用を払うのは割に合いません。そこで代替手段を探し始め、PWAが最も有望な選択肢の一つでした。

開発者にとっての究極のユニバーサルアプリの夢

PWAとはProgressive Web App（プログレッシブウェブアプリ）の略で、ネイティブアプリのように動作するよう設計されたウェブアプリケーションの一種です。HTML、CSS、JavaScriptなどのWeb技術で構築され、Android、Windows、Linux、macOS、iOSなど対応デバイスにインストールできます。少なくとも、エンドユーザーの体験はそうあるべきです。「あるべき」の部分については後ほど議論します。

私のような個人インディー開発者にとって特に魅力的だったPWAのメリット：

• 開発コストの低さ - プラットフォーム固有のAPIを使わないFlutterアプリなら、通常はゼロから始めなくてもWeb向けにビルドしてPWAとして準備できる。
• より簡単で迅速なアップデート - アプリの更新は、ホスティングプロバイダーに新しいビルドをプッシュするだけで済む場合があり、キャッシュ設定に応じてリフレッシュやアプリ更新サイクル後にユーザーは最新版を入手できる。
• アプリストアからのパッケージインストール不要 - 技術的にはユーザーはインストールボタンをタップするか「ホーム画面に追加」を使う必要があるが、フルのアプリストアダウンロードフローを経る必要はない。
• ストレージ使用量が少ない - PWAはアセットやアプリデータをキャッシュできるが、オフラインデータを積極的にキャッシュしない限り、ネイティブアプリのような大きなパッケージ感は通常ない。
• リーチの広さ - PWAは検索エンジンで見つけられ、リンクで簡単に共有できるため、ネイティブアプリよりも発見されやすい。
• アプリストアの審査プロセスが不要 - ブラウザ配信のPWAは、ネイティブアプリのようなアプリストア審査プロセスを経る必要がない。

なぜ私のユースケースに合っていたのか？

私のアプリはFlutterベースで、プラットフォーム固有のAPIにはあまり依存していないため、シンプルなflutter build webコマンドでWeb版をビルドできました。最近のスマートフォンはすでにWebアプリに十分最適化されており、PWAの助けを借りれば、ユーザーにネイティブに近い体験を提供できると考えました。

FlutterアプリからPWAビルドを準備した方法

驚くほど簡単でした。web/manifest.jsonファイルを変更し、PWA仕様に沿ったプロパティを追加しました。このファイルは、デバイスにインストールされたときにアプリがどのように表示・動作すべきかを指定します。詳しくはMDN Web App Manifestドキュメントをご覧ください。追加した内容は以下の通りです：

{
  "name": "alt games portal",
  "short_name": "alt games",
  "start_url": ".",
  "display": "standalone",
  "background_color": "#000000",
  "theme_color": "#000000",
  "description": "alt games portal",
  "orientation": "portrait-primary",
  "prefer_related_applications": false,
  "icons": [
    {
      "src": "icons/Icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "icons/Icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    },
    {
      "src": "icons/Icon-maskable-192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "maskable"
    },
    {
      "src": "icons/Icon-maskable-512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "maskable"
    }
  ]
}

アイコン名はAIツールで自動生成したもので、リネームが面倒だったのでそのままです。ご了承ください。

その後、Webビルドを実行しました：

flutter build web

これによりbuild/webフォルダに出力が生成されました。これはFirebase、Netlify、Vercel、Cloudflare Pagesなど、任意のWebアプリホスティングプロバイダーでホストできるWebアプリに過ぎません。私はすでにFirebaseを使っていたので、Firebase HostingでPWAをホストすることにしました。

Firebaseプロジェクトがまだセットアップされていない場合は、Firebase CLIを使って作成できます：

firebase login
firebase init hosting

# これでPWAがFirebase Hostingにデプロイされます
firebase deploy --only hosting

iPhoneでのPWA体験

ついにiPhoneで自分のアプリをテストできると期待を膨らませていましたが、最初のアプリ起動は応答しない白い画面だけでした。開発マシンでflutter run -d chromeコマンドを使ってWebアプリをテストしたところ、Firebase Authに関連するエラーが表示されました。PWAは基本的にWebアプリなので、Firebase側でもWeb向けの設定が必要だとすぐに気づきました。Firebase Flutter向けセットアップフローに従ってWebをサポートプラットフォームとして追加したところ、うまくいきました！PWAがiPhoneでPWAとして「期待通り」に動作するようになりました。

また、iOSではPWAをホーム画面に追加するのが意図的に難しくなっていることも注目に値します。Androidやデスクトップブラウザのようにインストールプロンプトを簡単にトリガーすることはできません。共有シートを開いて「ホーム画面に追加」ボタンをクリックする必要があります。テクノロジーに詳しい人にとっては簡単かもしれませんが、そうでない人にとってはかなり面倒です。実用的な対策としては、ホーム画面への追加方法を分かりやすく視覚的に案内するバナーを追加することです。

インストール以外にも、iOSには制限や粗い部分があります：

• 画面の向き - ブラウザの画面回転ロックのサポートはまだ一貫していない。Android/Chromeではより多くのケースに対応できるが、iOSでは私のアプリにとって十分な信頼性がなかった。私のアプリにはポートレートとランドスケープモードを頻繁に切り替える必要がある機能がある。
• プッシュ通知 - iOS/iPadOS 16.4以降、ホーム画面のWebアプリがWeb Pushをサポートするようになり改善されている。ただし、ホーム画面に追加されていることが前提で、ユーザーアクション後にユーザーの許可が必要で、適切なWeb Push実装も必要。私のシンプルなPWA実験では、ネイティブプッシュと同じプラグアンドプレイの手軽さではなかった。
• バックグラウンド同期 - ブラウザ間、特にiOSでのバックグラウンド同期にはまだ頼れない。つまり、ユーザーがアプリを閉じた場合、ネイティブアプリのようにバックグラウンドでデータ同期が続くとは想定できない。
• 最小化時の状態消失 - テストでは、アプリを最小化するとPWAの状態が失われることがあった。つまり、ユーザーが別のアプリに切り替えてPWAに戻ると、進捗が失われる可能性がある。
• レンダリングとアニメーションの違い - 使用していたトランジションやアニメーションがiOSでは壊れていたり、まったく動作しなかったりした。例えば、ヒーローアニメーションは非常に奇妙な見た目になった。

PWAのマネタイズ

マネタイズは、PWAがネイティブアプリに比べて不利なもう一つの側面です。PWAをマネタイズする方法はありますが、ネイティブアプリほど簡単ではありません。広告SDKはネイティブSDKほど成熟しておらず、PWA内での広告配置にも制限があります。例えば、AdMobはAndroid、iOS、Unity、C++、FlutterアプリターゲットなどのモバイルアプリSDK向けに構築されており、Web PWA向けではありません。Google AdSenseはWebサイトで使えますが、従うべきポリシーと配置ルールがあります。私のPWAは動的なツールに大きく依存しているため、AdSenseのクローラーにはクロール可能なコンテンツが少なすぎるように見える可能性があり、特に注意が必要です。

ネイティブアプリとウェブサイトの間に…PWA体験

AndroidでのPWA体験はかなり良好でしたが、それでもネイティブアプリとは違いました。ブラウザで動いているWebアプリのように感じました。最大の問題は、十分にサクサク動かないことでした。レンダリングのちらつき、画面遷移時の遅延があり、ネイティブアプリほどスムーズには感じられませんでした。チューニングを重ねれば最適化できたかもしれませんが、私のプロジェクトにとってはそこまでする価値がありませんでした。唯一の利点は、Apple App Storeの煩わしさなしにiOSユーザーにリーチできることでした。とはいえ、先述したようにiOSにも制約があり、それほど魅力的でもありませんでした。

まとめ

今回のプロジェクトではPWAを採用しませんでしたが、特定のユースケースにとっては素晴らしい技術だと思います。プラットフォーム固有のAPIにあまり依存しないシンプルなアプリを作っていて、Apple App Storeの煩わしさなしにiOSユーザーを含む幅広いユーザーにリーチしたいなら、PWAは素晴らしい選択肢になるでしょう。アプリストアの審査なしに、より幅広いオーディエンスにアプリのアイデアをテストする方法としても優れています。ただし、ユーザー体験を損なわないように、デザインと開発に特に注意を払う必要があります。

PWAが時間とともに改善され、将来的にもっとサポートが充実することを願っています。PWAの可能性には魅力を感じていますが、まだ本格的に使える段階かどうかは確信が持てません。大手プレイヤーがもっと真剣に取り組めば、大きなポテンシャルがあることは間違いありません。