プログレッシブウェブアプリ：PWAがネイティブに勝つとき

プログレッシブウェブアプリ開発は、英国の発注者がプロジェクト開始から最初の10分で候補から外し、18か月後、2つ目のネイティブコードベースが静かに予算を食い尽くしたあとで再発見する選択肢です。外される理由は、この話題について書かれたもののほとんどが二つの陣営のどちらかに落ちるからです。iOSがやろうとしない部分を飛ばす擁護論か、プラットフォームが本当にそれをできなかった2019年から受け継がれた懐疑論か、そのどちらかです。

どちらも今は間違っており、しかも計算を変えるかたちで間違っています。SafariはiOS 16.4以降、ホーム画面に追加したウェブアプリでプッシュ通知に対応しています。Chromeはインストールの要件からサービスワーカーを外しました。英国の規制当局は2025年10月、モバイルブラウザとブラウザエンジンについてAppleとGoogleを戦略的市場地位にあると指定しました。同時にiOSは今もバックグラウンド実行を拒み、こちらが制御できない規則で保存データを削除し、ウェブアプリをApp Storeに掲載することは決してありません。

以下は、1つのコードベースと3つのどちらを選ぶか迷っている顧客に私が渡す版です。ここに書いた機能の主張はすべて、2026年9月にベンダー自身のドキュメントで確認しました。この分野は、通説が決まって2年遅れているからです。

PWAはどんなときネイティブアプリに勝つのか。 利用者がiPhoneと同じくらいAndroidとデスクトップにもいるとき、アプリが端末ではなくサーバーのフロントエンドであるとき、そして人々がストアではなく検索であなたを見つけるときです。バックグラウンド位置情報、ホーム画面ウィジェット、iPhoneでのBluetooth、ストア課金が必要なら、PWAは負けます。得られるのは3つではなく1つのコードベースで、英国の相場ではおよそ£40,000から£120,000の構築費と、その後は毎年の請求額が目に見えて小さくなることです。

プログレッシブウェブアプリとは実際に何なのか

用語は緩く使われていて、同じ会議にいる二人が別々のものを指すことがあります。技術的な定義は狭く、守る価値があります。

MDNはプログレッシブウェブアプリを、ウェブプラットフォームの技術で作られ、プラットフォーム固有のアプリのような体験を利用者に与えるアプリだと説明しています。1つのコードベースから複数のプラットフォームで動き、インストールでき、オフラインで動作し、オペレーティングシステムと統合できます。

実務上それは3つの成果物を意味し、そのどれか1つでも欠けているサイトは、PWAではなく野心のあるウェブサイトです。

ウェブアプリマニフェスト

マニフェストは、アプリの名前、使うアイコン、起動時に開くURL、そしてブラウザの枠の中で動かすか単独で動かすかをオペレーティングシステムに伝えるJSONファイルです。これがなければ、ブラウザにはインストールするものがありません。小さく、静的で、この作業全体のなかで最も安上がりな部分です。

サービスワーカー

サービスワーカーは、ページとは別に動き、アプリとネットワークのあいだに座り、キャッシュからリクエストに応答できるスクリプトです。オフライン動作を可能にし、プッシュメッセージを受け取るのがこれです。同時に、うまくいかなくなる部分でもあります。スコープの設計を誤ったキャッシュは、何週間も古いコードを利用者に配り続けるからです。

HTTPS

サービスワーカー、プッシュ、位置情報、カメラへのアクセスはすべてセキュアコンテキストに限られます。今日のホスティングではこれは無料で自動なので、費用ではなく制約です。

インストール済みという言葉の意味はプラットフォームごとに違う

発注者はインストールを1つの挙動だと思い込みます。実際には3つあり、その違いは商売に直結します。

Android

Android版Chromeは最もネイティブに近い状態を与えます。アプリはホーム画面のアイコンを得て、アプリスイッチャーに独自の項目を持ち、独自のストレージを持ち、ラッパーを通じてPlayストアに掲載できます。ブラウザが該当のイベントを発火したあとなら、自前のUIからインストールを促せるので、いつ尋ねるかを自分で決められます。

iOSとiPadOS

Safariは共有シートと「ホーム画面に追加」の項目からインストールします。こちらから起動できるページ内のインストールプロンプトはなく、Appleが代わりに出してくれるバナーもなく、利用者が追加したかどうかを確実に検知する方法もありません。この1つの操作上の差が、プラットフォーム間で最も大きな実務上の違いであり、それは技術の問題ではなく設計の問題です。利用者に操作を教える必要があるからです。

デスクトップ

Chrome、Edge、macOS版Safariはいずれも、ウェブアプリを独自のウィンドウとしてドックやタスクバーにインストールします。デスクトップはPWAが最も論争を呼ばず、最も活用されていない領域で、とくに誰も保守したがらないElectronビルドが代替になっている社内ツールでそうです。

Chromeはインストール要件を変えたが、多くの解説は気づいていない

長年どの記事も同じチェックリストを繰り返してきました。マニフェスト、アイコン、HTTPS、そしてfetchハンドラを持つサービスワーカーです。最後の項目は、メニューからのインストール経路についてはもう当てはまりません。

Googleはメニューからのインストールについて、fetchを実装したサービスワーカーの要件を撤廃し、モバイルではバージョン108、デスクトップでは112からそうなりました。今では、自前のものを用意しないサイトに既定のオフラインページを提供しています。インストールプロンプトのアルゴリズムは依然としてfetchハンドラを求めますが、インストール可能性そのものはもうそれに依存しません。

その波及はツールにも及びました。Lighthouseはバージョン12.0.0でPWAカテゴリをまるごと削除しました。2024年4月に公開された版で、それらの監査は、もう当てはまらない条件を検査するために存在していたからです。ビルドパイプラインがいまだにPWAスコアの欠如で失敗するなら、それはGoogleが廃止したものを検査しています。

実務的な読み方は、インストールとオフライン機能が切り離されたということです。オフラインの仕組みをまったく持たないインストール可能なアプリを出荷でき、それはしばしば最初のリリースとして正しく、電波のないところで人々が実際に使う画面がわかってからキャッシュを足せばよいのです。

オフラインは費用を伴う設計上の判断

オフラインという言葉は膨大な範囲を隠しています。最後に取得したデータを表示するキャッシュ済みのシェルなら1週間の作業です。書き込みをキューに入れ、競合を解決し、再接続時に突き合わせる真のオフラインファーストなアプリは、別の製品です。

キャッシュ戦略

サービスワーカーのキャッシュは4つのパターンと、リソース種別ごとの判断に落ち着きます。キャッシュ優先は保存済みの複製を返して確認しないので、フォントやハッシュ付きのビルド成果物に向いています。ネットワーク優先はサーバーを試して駄目なら退避するので、常に最新でなければならないデータに合います。stale while revalidateはキャッシュを即座に返して背後で更新するので、コンテンツの通常の選択肢です。ネットワーク専用は、決済のように古い複製から応答してはならないものに使います。

ここを誤るのが、私が見るPWAの失敗として最も多いものです。アプリケーションシェルにキャッシュ優先を当てると、何かが更新を強制するまで先月のJavaScriptを再訪者に配り続け、届くバグ報告は現在のコードには存在しない症状を説明することになります。

バックグラウンド同期

オフライン中の書き込みをキューに入れ、接続が戻ったときに流し込むのがBackground Synchronization APIの役割です。MDNはこれを限定的な利用可能性と記載し、Baselineではないと明記しています。つまり、最も広く使われているブラウザの一部では動きません。

そこでiOSでは退避策を自分で書きます。IndexedDBにキューを永続化し、次にアプリが開かれたときに流すのです。それで動きますし、利用者も受け入れますし、APIなら午後の数時間で済んだところが、おおむね3日から5日の工数になります。

プッシュ通知は何より多くのプロジェクトを左右する

1つの機能がPWAの提案を沈めるとすれば、それはこれで、たいていは2022年には正しかった事実に基づいています。

Androidとデスクトップ

Android版Chrome、デスクトップ版Chrome、Edge、Firefoxのウェブプッシュは、Push API、Notifications API、サービスワーカーの連携によって何年も前から動いています。配信はブラウザベンダーのプッシュサービスが担い、許可は標準的なプロンプトで、購読済みの利用者にサーバーがメッセージを送るという一般的な用途では、ネイティブアプリとの意味のある差はありません。

iOSとiPadOS

AppleはiOSとiPadOS 16.4でWeb Pushを追加しました。付いている条件が見落とされる部分です。WebKitは、ウェブアプリがホーム画面に追加されている必要があると述べており、許可は購読ボタンのタップのような直接的なユーザー操作に応じて要求しなければなりません。Safariのタブに置かれたままのサイトでは、ウェブプッシュは動きません。

マニフェストはdisplayをstandaloneかfullscreenに設定する必要があり、そうすれば通知は他のアプリと同じように振る舞います。ロック画面、通知センター、ペアリングしたApple Watch、そして設定でのアプリごとの制御です。バッジも機能します。

Appleはのちに、もっと簡単な経路を追加しました。宣言的Web PushはSafari 18.4で登場し、iOSとiPadOS 18.4でホーム画面に追加したウェブアプリで利用でき、サービスワーカーを動かさなくても標準化されたJSONペイロードから通知を表示します。作業は減ります。ホーム画面という条件はなくなりません。

iOSの差を正確に述べる

差は実在し、評判よりは小さいものです。それを正確に述べるほうが、文句を言うのにも、埋まったふりをするのにも勝ります。

ストレージの削除

WebKitは最近使われていない順にウェブサイトのデータを削除し、最後の使用は最後のユーザー操作またはストレージ操作から測られます。ストレージポリシーの文書は、オリジンごとの割り当てをブラウザアプリではディスクの最大60%、その他のアプリでは最大15%とし、全体の割り当てをそれぞれ80%と20%と定め、単独動作のホーム画面ウェブアプリはブラウザと同じ割り当てを得ると確認しています。

続くことは2つです。ストレージは想像されるような制約ではないこと、そして削除は容量ではなく時期のリスクだということ。端末をキャッシュ、サーバーを正本として扱えば、削除は製品の欠陥ではなくなります。

バックグラウンド実行

iOSには、ネイティブのバックグラウンドタスクに相当するものがありません。定期的な取得も、バックグラウンドの位置情報も、アプリが閉じているあいだの静かな処理もありません。決まった時刻に起きなければならないことはサーバーで起き、利用者に見えるプッシュメッセージを通じて端末に届きます。

App Storeに存在しない

PWAはApp Storeに掲載できません。顧客のうち相当な割合が、ストアであなたのブランドを検索して見つけると期待しているなら、それはウェブ側の技術ではまったく解決できない問題です。

ブラウザエンジン、DMA、CMA

ここは報道が一次資料を追い越している部分なので、実際に文書化されていることについて狭く述べる価値があります。

Appleは今、代替ブラウザエンジンを許可していますが、これが欧州連合でのみ適用されると明示しています。iOS 17.4以降とiPadOS 18以降で、公開されたセキュリティ、プライバシー、テストスイートの基準を満たす開発者に与えられる2つのエンタイトルメントを通じてです。AppleはWeb Platform Testsの90%とTest262の80%の合格、JITなしでの動作、そして大半の脆弱性を30日以内に解決することを求めています。

英国の事業者にとって、そこには今日何かを変えるものはありません。エンタイトルメントは法域に紐づいており、英国の通信事業者を使う英国の利用者は、どのブラウザのアイコンを押したとしてもWebKitを動かしています。

英国の状況は別に動いています。2025年10月22日、CMAはAppleとGoogleがモバイルプラットフォームで戦略的市場地位にあると指定し、オペレーティングシステム、アプリ配信、ブラウザ、ブラウザエンジンを5年間にわたって対象としました。指定は行動要件を課す権限であって、要件そのものではありません。プラットフォームは今日の振る舞いを前提に計画し、緩和はすべて上振れとして扱ってください。

ハードウェアとデバイスAPI、思い込みではなく検証で

ウェブはハードウェアにアクセスできないというのは、私が最もよく聞く反論であり、具体的な場面で最もよく間違っている反論です。

ほぼどこでも動くもの

getUserMediaによるカメラとマイクへのアクセスはMDNでBaselineとされ、2017年からブラウザをまたいで動いています。位置情報、デバイスの向き、モバイルでのカメラ撮影を含むファイルのアップロード、クリップボードへのアクセス、モバイルのWeb Share API、そしてFace IDや指紋を認証器とするWebAuthnによるパスキーは、いずれも現行のモバイルブラウザで動きます。カメラのストリームを使ったバーコードとQRコードの読み取りも日常的です。

業務アプリの大多数にとって、その一覧がハードウェア要件のすべてです。

Chromiumのみ、モバイルでは事実上Androidのみのもの

Web Bluetoothは、GoogleによってChromeOS、Chrome for Android 6.0、Chrome 56以降のmacOS、Chrome 70以降のWindows 10で利用可能と文書化されており、iOSの対応は挙げられておらず、MDNもBaselineではなく限定的な利用可能性としています。Web NFCはさらに狭く、GoogleはChrome 89のAndroidで利用可能と記載しています。

利用者が選んだファイルを読み書きするFile System Access APIも同様にChromiumの領域ですが、オリジンプライベートファイルシステムが、ブラウザをまたいでアプリ内部のストレージ要件の大半を満たします。

アプリストアでの配信は技術ではなく商業の問題

チームはストア配信を機能の問題であるかのように議論します。実際には4つの商業的な変数の問題で、そのうちストアに明確に有利なのは1つだけです。

発見は正直な利点です。消費者はApp StoreとPlayをブランドとカテゴリで検索しますし、ストアに存在しない事業者はその経路を放棄します。認知度のある名前を持つ消費者向け製品にとっては非常に大きく、1社の従業員200人が使う道具にとってはごくわずかです。

信頼は実在し、利用者層によって非対称です。年齢が高く技術に詳しくない利用者は、ストアの掲載を安全の合図として読みます。若い利用者はますますそうではなく、同じ利用者が同じ電話で銀行のウェブサイトを平気で使います。

それに対してストアは、あなたと利用者のあいだに審査の列を、変わり続ける規則による却下のリスクを、そしてアプリ内で売るものへの手数料を加えます。PWAにはそのどれもありません。出す時期は自分で決め、重大な修正は審査を経てではなく次の読み込みですべての利用者に届きます。

ストアが実際に取る額

手数料の数字は、記憶に頼るのが賢明でない程度には頻繁に動きます。以下はベンダー自身が公開している条件で、2026年9月に確認しました。

Appleはデジタル商品とサービスの標準手数料として30%を取ります。App Store Small Business Programは、前暦年の収益が1,000,000 USDまでの開発者についてこれを15%に下げます。新規の開発者も対象で、年内にその閾値を超えると、以後の売上には標準料率が戻ります。

Googleは段階的なGoogle Playのサービス手数料を公開しています。各年の開発者収益の最初の100万USDには15%、それを超える分には30%、自動更新の定期購読には収益にかかわらず15%です。同じページは、2026年6月30日からEEA、英国、米国で発効する別の体系も示しており、インストールが新規か既存かに応じて10%または20%に5%の請求手数料を加えるものです。

両ベンダーとも米ドルで公開しています。月額£9.99の定期購読をストア経由で15%で売ると購読者1人あたり年間およそ£18、30%ならおよそ£36の費用になります。ストアが無料だと決める前に、購読者数を掛けてください。

PWAはGoogle Play経由でも出せる

Androidは両方の選択肢を同時に与えます。これはプラットフォーム比較における本物の非対称であり、めったに触れられません。

Trusted Web Activityは、自分のPWAをブラウザのクロームなしで全画面に開くAndroidアプリで、Digital Asset Linksによって自分のものだと検証されます。AndroidではChrome 72以降を必要とし、ホストアプリはウェブコンテンツのCookieやストレージにアクセスできません。実際には、マニフェストから生成した薄いラッパーを、他のアプリと同じようにPlayへ提出するだけです。

したがってAndroidでは、選択はストアかウェブかではありません。PWAを公開し、それを包み、同じコードベースから、数日のパッケージング作業と年間の開発者アカウント費用でストアの掲載も得られます。

iOSに同等のものはありません。Appleの審査ガイドラインは長らく、ウェブサイトを包んだだけのものはそれ自体では不十分だと扱ってきたので、iOSのストア経路は本当にネイティブなものを作ることを意味します。どのAPIの差よりも、この非対称が以下の費用表を形づくっています。

2つのネイティブコードベースと比べたプログレッシブウェブアプリの開発費用

人が行う比較は構築費で、それは小さいほうの半分です。結果を決める比較は3年間の総費用です。ネイティブの支出は繰り返し発生するからです。

これらは中程度の複雑さの業務アプリに対する英国の代理店の相場帯であって、見積もりではありません。この形のPWAは通常、2人か3人のエンジニア1チームで3か月から5か月です。2つのネイティブコードベースにウェブ上の存在を加えると、3つのチーム、3つのリリース工程、そして毎年3組のプラットフォーム更新になります。

1行目と3行目の差、構築でおよそ£75,000から£175,000、その後の年額でおよそ£27,000から£60,000が、ネイティブを買うときに買っているものです。それが正しい支出であることもあります。それは既定ではなく判断であるべきです。当社のウェブサイト開発とソフトウェア開発のページで、両方の経路をどう見積もるかを説明しています。

保守費用が実際に消えていく先

構築費は交渉されます。保守費は発覚するもので、複数コードベースのプロジェクトが派手にではなく静かに失敗する場所です。

ネイティブのプラットフォームは毎年こちらに作業を強います。OSのメジャー更新がAPIを非推奨にし、署名とプロビジョニングが変わり、最低SDKレベルが上がり、ストアの方針がプライバシーマニフェストやデータセーフティの申告といった要件を足します。そのどれも機能を出荷しません。2つのプラットフォームでは、他人が決めた日程でそれを2回払います。

さらに乖離があります。同じ機能を実装した2つのコードベースは離れていき、その乖離は片方のプラットフォームでしか再現しないサポート依頼として表面化します。製品上の判断はすべて2回行って突き合わせなければならず、その調整費用はどの請求書にも現れません。

PWAはそのすべてをブラウザの進化に置き換えます。それは連続的で、後方互換で、動いているコードをほとんど壊しません。繰り返し発生する作業は自前の依存関係の更新、セキュリティ修正、ホスティングであり、それはどのカスタムウェブアプリケーションにも元から必要な保守と同じです。

意味のある比較は提案書の2つの数字ではありません。毎年、製品が生きているあいだずっと続く、1チームと3チームの比較です。

PWAの性能とCore Web Vitals

インストールされたアプリはネイティブと比べられるので、性能の基準はウェブサイトより低くはならず、高くなります。良い知らせは、指標が公開されていて、しきい値が固定されていることです。

Core Web Vitalsは現在3つの指標からなり、それぞれページ読み込みの75パーセンタイルで評価され、モバイルとデスクトップに分けられます。Largest Contentful Paintは2.5秒以下で良好、4.0秒超で不良です。2024年に安定版となってFirst Input Delayを置き換えたInteraction to Next Paintは、200ミリ秒以下で良好、500ミリ秒超で不良です。Cumulative Layout Shiftは0.1以下で良好、0.25超で不良です。

ここではPWAに構造的な利点が1つあります。サービスワーカーがシェルをキャッシュから返すと再訪がほぼ瞬時になり、それはまさにインストールされたアプリが生む挙動なので、インストール済みPWAの実利用データは、同じコードをブラウザで初めて訪れた場合より良く見えるのが普通です。

構造的なリスクも1つあります。シングルページのフレームワークは処理をクライアントに押しやり、INPはそれを罰する指標です。すでにこの数字と戦っているなら、Core Web Vitalsに合格するための当社のガイドが、本稿より詳しく診断を扱っています。

誰も値付けしないSEOという利点

これは商業的な場面のほとんどで私が最初に持ち出す論点であり、そしてほぼ必ず比較から抜け落ちています。

PWAはウェブサイトです。すべての画面がURLを持ち、すべてのURLがクロールされ、索引付けされ、リンクされ、共有され、そのすべてが順位を得られます。ネイティブアプリにはそのどれもありません。アプリストアの掲載は浅くしか索引付けされず、まったく別の指標で壁に囲まれた庭の中を順位付けされ、アプリの中身は検索から見えません。

その帰結は積み重なります。ネイティブアプリへのマーケティング支出はインストールを買い、支出をやめた日に止まります。同じ支出をPWAのコンテンツと技術的品質に充てると、順位を保ち続けるページを買えます。3年で見れば、その差はどちらの経路の構築費全体をも上回ることがしばしばです。

これはクロールできる実装であってこそ報われるもので、クライアント側でレンダリングするアプリが失敗するのはここです。すべてをJavaScriptで描画し、URLが1つでサーバーが生成したHTMLがない状態は、この利点を完全に手放します。索引付けさせたい経路をサーバーレンダリングするかプリレンダリングするのが対処で、公開前のテクニカルSEO監査は、半年後に何も索引付けされていないと気づくよりはるかに安く済みます。

失格になる要件

この判断は、利点の一覧としてよりも、拒否事由の一覧としてのほうが簡単です。拒否事由は客観的だからです。

以下のいずれかが願望ではなく本当の要件なら、ネイティブが必要です。アプリが閉じているあいだのバックグラウンド位置情報の追跡。ホーム画面のウィジェット、ウォッチアプリ、CarPlayやAndroid Autoとの統合。iPhoneでのBluetoothやNFC。HealthKit、アプリ内のApple Pay、あるいはAppleがウェブに開放していない深いOS統合。ストアの方針が求める場合の、デジタル商品のストア課金。リアルタイムの動画処理やネイティブ並みのフレームレートでの3D描画のような、持続的で重い計算。事業が本当に依存しているマーケティング要件としての、App Storeでの存在。

そのどれも当てはまらないなら、PWAが正しい答えである可能性が非常に高く、立証責任は3つのコードベースを望む側にあります。

さらに2つの考慮がそれを後押しします。利用者が主にデスクトップかAndroidにいるなら、iOSの欠落は聴衆の少数派にしか影響しません。そしてアプリが端末ではなく自社サーバーのフロントエンドなら、これは業務ソフトウェアの大半に当てはまりますが、端末の機能はほとんど問題になりません。

事例その1、施設管理業者のフィールドサービス

エンジニア200人、作業指示書、完了した仕事の写真、署名の取得、機械室や地下の不安定な電波。これは人がネイティブを必要とすると思い込む事例であり、PWAが最も明確に勝つ事例です。

要件はすべて満たせます。カメラはgetUserMediaで動きます。署名はcanvas要素です。作業データはIndexedDBにキャッシュされ、書き込みキューは再接続時に流れます。Background Syncがブラウザをまたいで信頼できないので、そこは手書きです。配車の通知はウェブプッシュで出ます。Androidで動き、iOSではアプリをホーム画面に追加したエンジニアで動きます。インストールは利用者獲得の問題ではなく、導入研修の5分の項目です。

利用者が従業員なので、ストアでの発見の要件はありません。課金がないので手数料は無関係です。端末はAndroidとiOSが混在しており、それはまさに2つのネイティブコードベースを最も強く罰する場合です。

2つのネイティブアプリを£120,000から£200,000で作る代わりに、PWAを1つおよそ£45,000から£70,000で作り、修正を審査ではなく同じ日の午後に配り、差額を、実際に成否を決める配車バックエンドに使ってください。

事例その2、予約とリマインダーを望むサロンチェーン

14店舗、消費者向け、予約の受付、リマインダー、ポイント制度、支払いはアプリ内ではなくレジで。競合が持っているからネイティブアプリを、というのが本能です。

要件の一覧は平凡です。予約フォーム、カレンダー、リマインダー、アカウント領域。興味深いのはリマインダーだけで、この市場ではプッシュよりSMSとメールのほうが向いています。年に2回予約する顧客は、何もインストールしていないからです。

決め手は発見であり、それは決定的にウェブに有利です。人はサロンを検索と地図で見つけるのであって、アプリストアを眺めて見つけるのではないので、サービスを説明し予約を受けるページが順位を得る必要があります。ネイティブアプリはそこにまったく見えません。ウェブサイト自体の費用が本当の予算項目で、アプリの層はインストール可能性として上に足されます。

予約サイトをきちんと作り、常連がホーム画面に置けるようインストール可能にし、同意する少数のためにウェブプッシュを足してください。ここでのネイティブ構築は、ウェブサイトがすでに届けているより少ない顧客に届くために£80,000以上を使います。

事例その3、定期購読型のフィットネス製品

ガイド付きワークアウト、動画コンテンツ、ウェアラブル連携、月額£12.99、消費者直販、有料獲得による成長。この事例は逆に振れるので、理由を示す価値があります。

ここではストアでの発見が効きます。フィットネスは眺めて探すカテゴリで、掲載は本物の獲得経路だからです。ウェアラブル連携はHealthKitを意味し、ウェブは届きません。ワークアウト中のバックグラウンド音声と画面の点灯の挙動はネイティブのほうが良いです。大規模なオフライン用の動画ダウンロードはウェブでも可能ですが、快適ではありません。

面白いのは課金です。月額£12.99へのストア手数料は、15%なら購読者1人あたり年間およそ£23、30%ならおよそ£47で、20,000人の購読者なら年間£460,000から£940,000になります。それは支払いをウェブで受け、アプリをクライアントとして扱う強い論拠で、いくつかの大手の定期購読製品が現にそうしています。

答えは、製品にはネイティブアプリを、登録、課金、コンテンツマーケティングにはPWAか通常のウェブアプリを、というものです。両方が存在し、その分割は偶然ではなく意図的です。

午後のうちに決める方法

この判断にディスカバリーフェーズは要りません。必要なのは、4つの答えを書き出すことです。

第一に、本当に必要な端末機能を挙げ、要約ではなくベンダー自身のドキュメントで1つずつ確認してください。ほとんどの一覧はこの段階で劇的に短くなります。第二に、利用者がどこから来るかを確かめてください。答えが検索ならウェブがすでに有利で、ストアの回遊なら有利ではありません。

第三に、3つの経路すべてを1年ではなく3年で値付けし、上記の保守費用を含め、売る予定のものにかかるストア手数料も入れてください。第四に、自分のチームについて正直になってください。3人のエンジニアが保守する1つのコードベースは、3人のエンジニアが保守する3つのコードベースより、毎回多くを出荷します。

それでも答えが曖昧なら、先にPWAを作ってください。取り消すのが安いほうです。あとからPWAからネイティブへ行くのは、すでに存在して実証されたAPIに対してネイティブのクライアントを書くことであり、逆はやり直しを意味します。この非対称は、上に挙げたどの機能比較よりも価値があります。

ここから先どうするか

プログレッシブウェブアプリ開発は、ネイティブを買えない人のための妥協ではなく、万能の答えでもありません。定義可能で大きな製品の分類にとって正しいアーキテクチャです。業務ソフトウェア、社内ツール、予約とアカウントの仕組み、コンテンツ製品、そして顧客が検索から来るものすべてです。

iOSの欠落は実在し、具体的で、致命的というより大半は回避できます。プッシュは利用者がインストールすれば動きます。ストレージは潤沢ですが削除され得ます。バックグラウンド実行は存在せず、もともとサーバーに属します。BluetoothとNFCはiPhoneで動かず、どれだけ技術を積んでもそれは変わりません。

Mecanikは両方の経路を作り、答えがネイティブであるときはそう申し上げます。一般的な一覧ではなく実際の要件に対して比較を走らせたいなら、ウェブサイト開発とソフトウェア開発のページに見積もりの進め方を書いており、2026年にウェブアプリを作るための当社のガイドが、その先のスタック選定を扱っています。

よくある質問

プログレッシブウェブアプリとは何ですか。 プログレッシブウェブアプリは、ウェブ技術で作られ、プラットフォーム固有のアプリのように振る舞うアプリです。技術的にはHTTPSで配信されるウェブアプリケーションで、名前、アイコン、起動時の挙動を記述したウェブアプリマニフェストと、キャッシュからリクエストに応答しプッシュメッセージを受け取れるサービスワーカーを備えます。MDNは、1つのコードベースから複数のプラットフォームで動きながら、インストール可能でオフラインでも動作するソフトウェアと定義しています。

PWAはiPhoneでプッシュ通知を送れますか。 条件が1つ付きますが、送れます。AppleはiOSとiPadOS 16.4でWeb Pushを追加しましたが、WebKitはウェブアプリが先にホーム画面に追加されていること、そして購読ボタンのタップのような直接的なユーザー操作に応じて許可を要求することを求めます。Safariのタブで動くサイトではプッシュは動きません。iOSとiPadOS 18.4で追加された宣言的Web Pushは実装を簡単にしますが、ホーム画面という同じ条件は残ります。

英国でのプログレッシブウェブアプリ開発の費用はいくらですか。 中程度の複雑さの業務アプリなら、単一のPWAコードベースの構築に£35,000から£75,000、保守に年間£8,000から£20,000を見込んでください。比較対象となる、iOSとAndroidのアプリを別々に作りマーケティングサイトを添えるネイティブの経路は、構築が£110,000から£250,000、以後が年間£35,000から£80,000です。これらは見積もりではなく英国の代理店の相場帯で、通常は構築費の差より繰り返し発生する差のほうが重要です。

PWAをApp StoreやGoogle Playに置けますか。 Google Playは可能で、App Storeは不可能です。AndroidではTrusted Web ActivityがPWAを薄いネイティブの殻で包み、Digital Asset Linksで検証するので、同じコードベースが数日のパッケージング作業でPlayの掲載を得ます。Appleに同等のものはなく、審査ガイドラインはウェブサイトを包んだだけのものを不十分と扱うため、App Storeでの存在は本当にネイティブなものを作ることを意味します。

PWAではなくネイティブアプリを選ぶべきなのはどんなときですか。 アプリが閉じているあいだのバックグラウンド位置情報、ホーム画面のウィジェット、ウォッチや車載との統合、iPhoneでのBluetoothやNFC、HealthKitやアプリ内のApple Pay、リアルタイムの動画処理のような持続的で重い計算、あるいは本物の獲得経路としてのApp Storeでの存在が必要なときは、ネイティブを選んでください。そのどれも当てはまらないなら、PWAが正しい可能性が非常に高く、立証責任は3つのコードベースを保守したい側にあります。