PWA と Native、いつどちらを選ぶべきか

PWA の強み

• 1 コードで iOS / Android / Web に対応：メンテナンスコストが激減する。デザインの微修正から新機能の投入まで、1 回のデプロイで 3 プラットフォームに反映できる
• App Store 審査が不要：即日リリース・即日修正が可能。緊急バグの hotfix で心理的余裕が違う
• URL で共有可能：ダウンロード不要で試せる → 摩擦が最小。SNS シェアからの CV 率が Native の 2〜3 倍になることも珍しくない
• SEO の恩恵：URL がインデックスされて Google 検索から流入できる。App Store 検索より広い母集団にリーチ可能
• 初期コストが低い：既存の Web スキルセットでスタートできる。Next.js を書ける人なら即戦力
• ストア手数料 0%：Stripe を挟めば直接決済でき、30% の App Store 税を回避できる（決済モデルによっては年数百万円の差）

PWA の弱み

• iOS Safari の制約が根深い：Widget、Watch complication、Face ID による生体認証、Bluetooth、NFC など、iOS の「アプリらしい体験」の多くが使えない
• App Store / Google Play 経由の獲得ができない：ASO やストア注目枠といったオーガニック導線が使えない（後述の TWA で Android は部分回避可能）
• iOS の ITP による localStorage 7 日削除：ホーム画面追加（A2HS）してもらわない限り、ユーザーのログイン状態が 7 日で吹き飛ぶ
• 広告収益の選択肢が限定：google_mobile_ads（AdMob）非対応、AdSense のみ。eCPM は AdMob の 6〜8 割
• 「アプリとして認識されにくい」：ユーザーが「これブラウザ？」となる。継続率にじわじわ効いてくる

技術要素の対応表（2026 年時点）

よく問い合わせを受ける機能について、PWA と Native の対応状況を一覧化しました。◯＝実用レベル、△＝制約付きで可、✕＝実質不可、を表します。

• Push 通知：PWA △（iOS 16.4 以降で対応、ただし A2HS 済み + 独立ウィンドウ起動が条件、Payload サイズや優先度制御に制約） / Native ◯
• Background Sync：PWA △（Android Chrome は可、iOS は Service Worker のバックグラウンド起動時間が短く実質使えない） / Native ◯
• File System Access API：PWA △（Chromium 系のみ、Safari 非対応） / Native ◯
• Bluetooth / BLE：PWA △（Web Bluetooth は Chrome のみ、iOS 全滅） / Native ◯
• NFC：PWA ✕（Web NFC は Android Chrome のみ試験的） / Native ◯
• ホーム画面 Widget：PWA ✕ / Native ◯（iOS 14+ / Android 12+）
• Apple Watch complication：PWA ✕ / Native ◯（watchOS ネイティブ必須）
• App Store 課金 (IAP / サブスク)：PWA ✕ / Native ◯
• 生体認証 (Face ID / Touch ID)：PWA △（WebAuthn 経由で passkey ならほぼ同等、ただし従来アプリ的な quick unlock はできない） / Native ◯
• 位置情報の精度・バックグラウンド追跡：PWA △（フォアグラウンドのみ、精度も iOS では粗い） / Native ◯
• Camera の RAW / 高度制御：PWA ✕（getUserMedia は自動露出のみ） / Native ◯
• App Clips / Instant Apps：PWA ✕ / Native ◯
• Deep Link / Universal Link：PWA ◯（URL がそのままエントリポイント） / Native ◯
• SEO / 検索流入：PWA ◯ / Native ✕（App Store 検索は別世界）

iOS Safari の PWA 制約、もう少し細かく

• Push 通知：iOS 16.4 でようやく Web Push 対応。ただし発火条件は「ユーザーが A2HS 済み」かつ「アイコンから独立ウィンドウで起動」時に限られる。Safari タブから開いた状態では Push は届かない。Payload は APNs 経由のため VAPID key の管理が必須で、Safari 独自の署名も要る
• ストレージ：ITP（Intelligent Tracking Prevention）により、A2HS していない PWA の localStorage / IndexedDB / cookie は 7 日で削除される。ログイン状態を保つには A2HS を促す UX が必須
• Service Worker：バックグラウンド sync や periodic sync は iOS 未実装。Push を受けて任意処理をさせようとしても、Payload に含めた最小情報だけで通知表示するのが精一杯
• ストレージ容量：iOS では約 50MB を超えると quota exceeded が発生しやすく、Android の 6% 空き容量ルールに比べて厳しい
• フルスクリーン挙動：display: standalone にしてもステータスバーとの境界が残るケースがあり、Native と完全同一の見た目にはならない

Android Chrome の PWA 状況

Android Chrome は iOS に比べて圧倒的に緩く、実用面ではほぼ Native に近い体験が出せます。Push は制約なし、Background Sync / Periodic Sync も動作、Web Bluetooth / Web NFC / Web USB まで揃っており、A2HS も「アプリをインストール」というダイアログが自動で出る。さらにTWA（Trusted Web Activity）を使えば PWA を APK/AAB にラップして Play Store に載せることまでできるため、Android 側は PWA だけでもかなり戦えます。

PWA + TWA で Play Store に載せる

Android では、PWA を Play Store 経由で配布する正規ルートが用意されています。手順は以下の通りで、コード追加ゼロで既存 PWA をストア配布できます。

1. Bubblewrap CLI をインストール：npm i -g @bubblewrap/cli。Google 公式ツールで、PWA から TWA プロジェクトを生成する
2. manifest.json を用意：PWA としての要件（icons 192/512、start_url、display: standalone、theme_color）を満たしておく
3. 初期化：bubblewrap init --manifest=https://example.com/manifest.json で Android プロジェクト生成
4. Digital Asset Links の設定：ドメイン側に /.well-known/assetlinks.json を配置し、Play Console 発行の SHA-256 fingerprint を紐付ける。これを忘れると URL バーが上部に表示されてしまい TWA として成立しない
5. AAB 生成 & アップロード：bubblewrap build で AAB が出力され、そのまま Play Console にアップロード可能

TWA で載せたアプリは、Play Store 上では通常の Android アプリと区別されず、ASO・ランキング・レビュー機能すべて利用できます。Android 側だけでも「ストア経由の獲得」を PWA のまま実現できるので、Android 先行のプロダクトなら極めて有効です。iOS 側は同種の仕組みが Apple から提供されておらず、こちらは素直に Native を作るしかありません。

Native の主要選択肢の比較

• Flutter：単一コードから iOS / Android / Web / Desktop まで対応。Widget / Push / 生体認証 / 地図 / カメラなど主要プラグインが揃っており、少人数チームの生産性は最強クラス。Skia 描画のためデザインの再現性が高い
• React Native：Web エンジニアの資産が最大限効くが、ネイティブモジュール周りの Xcode / Gradle トラブルは避けられない。Expo を使えば大部分をラップできる
• SwiftUI + Kotlin ネイティブ：品質・OS 新機能対応・パフォーマンス最強。ただし人月コストは 2 倍
• Kotlin Multiplatform (KMP)：ビジネスロジックは共有、UI は SwiftUI / Compose というハイブリッド。中〜大規模なチーム向き
• Ionic / Capacitor：WebView ベースだが、Native プラグインを差し込める。既存 Web アプリの延命に向く

ClearNets のように少人数（1〜3 名）で複数プロダクトを回すチームでは、Flutter が現状の最適解です。Widget や App Store 課金といった「Native 側でしか取れない要素」もプラグインで一通り揃っており、Web / iOS / Android を 1 コードで維持できるレバレッジが決定的です。

ClearNets の実プロダクトでの判断

• Kotsukotsu（習慣トラッカー）：PWA 先行 → Native 予定。Widget が UX の中核（ホーム画面から 1 タップで「昨日やった」を記録）だから、最終形は Native 必須。ただし MVP では PWA で 3 ヶ月市場検証してから Native 投入する順序を守る
• Merci（チップ決済）：PWA 一本。QR コード読み込み → URL 遷移 → Stripe で決済という導線は URL だけで完結し、Native を作るメリットが皆無。飲食店員・お客のどちらもインストールを求めない設計に価値がある
• Paircon（Family Safety OS）：Native 先行。Google Family Link に近い挙動が要求され、位置情報のバックグラウンド追跡・Widget・通知が中核。PWA では成立しない
• 家族おでかけガイド：Web only。旅行前の下調べ用途で 1 ユーザー月 1〜2 回のアクセス頻度。Native を作るとむしろ DL 摩擦で流入が減る
• Kotodama（AI 占い）：PWA + iOS Native。toC の占い課金は iOS の IAP に慣れているユーザー層が多く、Web の Stripe 決済より iOS Native のサブスク UI の方が CV が伸びた実測がある

収益モデルと選択の関係

• 広告収益：PWA + AdSense で必要十分。AdMob 比で eCPM は 6〜8 割まで落ちるが、Native 開発・保守コストと比べれば圧倒的に PWA 有利
• 買い切りアプリ：iOS Native ほぼ必須。ユーザーは「App Store で買ったもの」以外を買い切りで払う習慣がなく、Web で ¥600 の買い切りを売るのは相当難しい。App Store 手数料 30%（Small Business Program 適用で 15%）は必要コストと割り切る
• サブスク：iOS 17 以降、EU では外部リンクによる外部課金が許可され、日本でも「Reader App」の外部リンク許可が広がった。とはいえ実務上は、CV 率の差を考えると IAP の 30% を払ってでも Native 内で完結させる方が総売上が伸びるケースが多い。外部課金はヘビーユーザー割引として併設する構成が現実解
• チップ / 決済：Stripe を使うなら PWA が有利。App Store 経由で決済を挟むと「デジタルコンテンツ扱い」で IAP 強制の対象になり得るため、飲食・実物サービス系の受け取り決済はブラウザで完結させるのが安全

開発・運用コスト実測値

ClearNets の実プロダクト運用から実測した工数目安を共有します。1 人のエンジニアが片手間で維持する前提の数字です。

• PWA 単体：初期 2 週間、以降 週 2 時間で維持可能。デプロイは git push のみ、テストも Playwright を回すだけ
• Flutter Native（1 プラットフォームのみ）：初期 3 週間、以降 週 4 時間。ストア審査・スクリーンショット更新・OS メジャーアップデート対応が乗る
• Flutter Web + iOS + Android の 3 面展開：初期 5 週間、以降 週 6 時間。共通ロジックの恩恵で 3 面のわりに保守が軽い
• 純ネイティブ 2 OS 併走（Swift + Kotlin）：初期 8 週間、以降 週 12 時間。同じ機能を 2 度書く負担が常時のしかかり、少人数チームでは事実上維持不能

リリース速度の違い

• PWA：git push → CI → Vercel / Cloudflare Pages 反映まで5 分。ユーザー側は次回リロードで即最新
• Google Play：内部テスト即時、本番反映は数時間〜1 日。段階公開設定ありなら数日
• App Store：通常審査24〜72 時間、Expedited Review 申請で最短 12 時間程度。緊急 hotfix でも半日待たされる覚悟が要る

MVP や初期グロース期のように「1 日 3 回リリースが普通」というフェーズでは、PWA の即応性が圧倒的な武器になります。ユーザーヒアリング → 30 分でコード修正 → デプロイ → 翌日ヒアリング、というループを 1 日単位で回せる差は決定的です。

意思決定フローチャート

ClearNets 社内では、新規プロダクトの立ち上げ時に次のフローで選定しています。

1. Widget / Push / 生体認証 / バックグラウンド位置 のいずれかが UX の中核か？
   • Yes → Native 確定（Flutter 推奨）。ただし MVP を作れるなら PWA プロトタイプを 1 週間だけ作って仮説検証する
   • No → 次へ
2. 主な課金モデルは？
   • 広告 → PWA
   • サブスク → 両方（PWA 先、Native は 3 ヶ月後）
   • 買い切り → iOS Native ほぼ必須
   • 実物サービスの決済（Stripe） → PWA
3. まだ MVP 段階か？
   • Yes → 上記に関係なく PWA から。仮説が確定してから Native を積む
   • No → 上記の結論に従う
4. Android だけで戦えるか？
   • Yes → PWA + TWA だけで Play Store 配布まで完結できる
   • No（iOS も必要） → Flutter で両 OS 対応

失敗談：判断を間違えた 2 例

Kotodama：Web 単体では toC が刺さらなかった

Kotodama は当初「AI 占いは Web で十分」と判断して、Stripe サブスクを組み込んだ Web アプリとしてローンチしました。3 ヶ月運用した結果、toC 課金は Web の Stripe より iOS の IAP の方が CV 率が明確に高いことが分かり、iOS Native を追加開発する判断になりました。占い層は「App Store で買う」という体験に強く親和的で、Web のカード決済に対する心理障壁が想像以上に高かった。Native を後追いで足すのは無駄になった Web 側の課金 UI 分だけ機会損失があり、最初から iOS Native も視野に入れておけばよかったと反省しています。

Paircon：PWA 版を作りかけて 1 週間で止めた

Paircon は Native 先行で走っていましたが、「Web でも試せた方が親御さんに刺さるのでは」と PWA 版に着手したことがあります。1 週間ほど手を動かしたところで、iOS の Push が Widget と組み合わさって初めて価値が出る UX 設計だと再認識し、PWA 版は破棄しました。「一応 Web も」という気持ちで作り始める前に、UX の中核が何か（Widget＋Push という組み合わせ自体が中核だったのか、Push 単体で成立したのか）を先に言語化しておけば、1 週間の工数は使わずに済みました。

Flutter で両方作る

ClearNets の複数プロダクトは Flutter で開発しています。Flutter は 1 コードから Web / iOS / Android すべてに対応でき、PWA と Native を同じコードベースで管理できます。プロダクトが PWA から Native に移行するタイミングでもコードを 1 から書き直す必要がなく、既存資産の 80% 以上を流用できます。「PWA で MVP → 反応を見て Native」という順序を最も低コストで実現できるスタックだと今のところ考えており、少人数チームで複数プロダクトを回すクラウンネッツの経営スタイルとの相性が抜群です。

まとめ

「PWA と Native、どちらを選ぶか」は二者択一ではなく、プロダクトのフェーズと UX の中核要素で順序が決まる問題です。判断を Widget / Push / 課金モデル / MVP 段階の 4 軸で分解し、Flutter でコード資産を残しながら、PWA で仮説検証 → Native で本気投入、という順序を守るのが、少人数チームで複数プロダクトを回す上での最適解です。ClearNets ではこの方針で 5 プロダクトを並走させており、判断のブレを最小化できています。