PWA（Progressive Web App）は、Webサイトをアプリのように使える技術として注目を集めています。開発コストを抑えながらクロスプラットフォーム対応ができる点が魅力ですが、iOSでの対応状況はAndroidと比べて大きく遅れているのが現状です。
「PWAでWebアプリを作りたいけれど、iPhoneユーザーにちゃんと使ってもらえるのだろうか？」
そんな疑問をお持ちの方も多いのではないでしょうか。本記事では、2026年時点でのiOSのPWA対応状況を詳しく調査し、何ができて何ができないのか、ビジネスへの影響はどうなのかを整理してお伝えします。
※PWAの基本的な仕組みやメリット・デメリットについては、別途以下の記事で解説しております。
あわせてご覧ください。
iOSとAndroidのPWA対応の歴史
PWAに対するAppleとGoogleのスタンスは、これまで大きく異なってきました。その歴史を振り返ることで、現在のiOS対応状況の背景が見えてきます。
Appleの慎重な姿勢
Appleは当初、Webアプリに対して前向きな姿勢を見せていました。2007年6月のWWDC 2007の際、Steve JobsはwebアプリをiOS「very sweet solution（非常に素晴らしい解決策）」と語り、開発者に対してWebアプリ開発を推奨していました。しかし、その後まもなくして方針を転換し、2008年にApp Storeを開設。以降、Appleの関心はネイティブアプリへと移っていきます。
PWAの中核技術であるService Worker（ブラウザとサーバーの間に入ってオフライン機能やプッシュ通知を実現する仕組み）への対応も、Androidに大きく遅れを取りました。Androidが早期からPWAを積極的にサポートしていた一方で、iOSが基本的なService Worker対応を開始したのは2018年のiOS 11.3。Androidの対応から数年の遅れがありました。
Appleがなぜこれほど消極的だったのかには、いくつかの理由があると考えられています。
可能性としてまず、App Store収益の保護のためとも言われています。PWAはApp Storeを経由せずに配布できるため、Appleにとっては15〜30%の手数料収入が得られません。年間数百億ドル規模と言われるApp Store収益を考えれば、PWAの普及を積極的に推進するインセンティブが働きにくいのは理解できます。
次に、セキュリティとプライバシーへの配慮です。Service Workerは、ユーザーがアクセスするWebページの内容を全て見ることができ、サーバーからの応答を書き換えることもできる強力な権限を持っています。悪意のあるサイトがこれを悪用すれば、個人情報の盗聴や改ざん、フィッシング詐欺なども可能になってしまいます。「iPhoneは安全」というブランドイメージを最優先するAppleとしては、こうした強力な権限を持つ技術の導入には慎重にならざるを得ないという事情があります。
さらに、WebKitの独占によるコントロール維持も要因の一つです。iOS上では全てのブラウザがAppleのWebKit（Safariのエンジン）を使うことが義務付けられており(例外としてEU向けに、iOS 17.4以降で代替ブラウザエンジンの利用枠組みを用意)、Appleが完全にコントロールできる状態になっています。PWAの機能をどこまで開放するかも、Appleが自由に決められるわけです。
転機となったiOS 16.4（2023年3月）
長らく停滞していたiOSのPWA対応に大きな転機が訪れたのが、2023年3月にリリースされたiOS 16.4です。このバージョンで、ついにプッシュ通知がサポートされました。
プッシュ通知は、ユーザーがアプリを開いていない状態でも情報を届けられる重要な機能です。ECサイトであれば「セール開始」の通知、ニュースアプリであれば「速報」の配信など、ユーザーとの継続的な接点を作るために欠かせません。Androidでは数年前から当然のように使えていた機能が、iOSでようやく実現したことで、PWAの実用性は大きく向上しました。
同時に、アイコン上に通知件数を表示できるバッジAPIもサポートされ、よりアプリらしい体験が可能になりました。
2024年のEU騒動
2024年2月、AppleはiOS 17.4のベータ版において、EU（欧州連合）圏内のユーザーに対してPWA機能を削除するという衝撃的な発表を行いました。これは、EUのデジタル市場法（DMA：Digital Markets Act）への対応として行われたものです。
デジタル市場法は、巨大IT企業による市場独占を防ぐための規制で、Appleに対してもiOS上で他のブラウザエンジン（WebKit以外）を認めるよう求めていました。Appleは「複数のブラウザエンジンでPWAをサポートするのはセキュリティリスクがある」として、EU圏内ではPWA機能そのものを削除する方針を示したのです。
この決定に対して、開発者コミュニティからは大きな反発が起こりました。「AppleはPWAを潰そうとしている」「App Storeの収益を守るための口実だ」といった批判が相次ぎ、わずか2週間後の2024年3月、Appleは方針を撤回。EU圏内でもPWA機能を復活させることを発表しました。
この騒動は、PWAをめぐるAppleとWeb推進派の利害対立が表面化した出来事と言えます。Appleとしては、可能であればPWAの普及を抑えたいという本音が透けて見える一方で、開発者や規制当局からの圧力により、完全に無視することもできないという板挟みの状態が続いています。
Androidの対応状況（比較として）
一方、GoogleはPWAを積極的に推進してきました。Android版のChromeでは、PWA対応サイトにアクセスすると自動的にインストールを促すポップアップが表示されます。ユーザーが「インストール」をタップすれば、ホーム画面にアイコンが追加され、まるでネイティブアプリのように使えるようになります。
さらに、Androidではバックグラウンドでのデータ同期や定期的な情報更新といった高度な機能もサポートされており、ネイティブアプリに近い体験が実現できます。
このように、AndroidとiOSの間には、PWA対応において大きな格差が存在しています。同じPWAを開発しても、Androidユーザーには快適に使ってもらえる一方で、iOSユーザーには制約の多い体験になってしまうという現実があります。
iOS 26でのPWA対応状況：何ができて何ができないか
それでは、2026年時点の最新版であるiOS 26では、具体的にどのような機能が使えるのでしょうか。対応している機能と、対応していない機能を整理してご紹介します。
対応している主要機能
まず、iOS上のPWAで使える機能から見ていきましょう。
ホーム画面への追加は可能です。
ただし、後述するように「手動での操作が必要」という大きな制約があります。一度ホーム画面に追加すれば、アイコンをタップするだけでアプリのように起動できます。
オフライン動作もサポートされています。
Service Workerという仕組みを使って、一度訪れたページの内容をキャッシュ（保存）しておけば、インターネット接続がない状態でも基本的な閲覧が可能です。ECサイトであれば商品カタログ、ニュースアプリであれば過去記事など、オフラインでも見られるようにできます。
プッシュ通知は、iOS 16.4以降で利用可能になりました。
これにより、ユーザーがアプリを閉じている状態でも、サーバーから通知を送ることができます。ただし、これには重要な条件があり、詳しくは次のセクションで解説します。
バッジ表示も可能です。
アプリアイコンの右上に、未読件数などを数字で表示できます。メッセージアプリやSNSなど、通知件数を分かりやすく伝えたい場合に有効です。
ダークモードにも対応しており、
iPhoneの設定に合わせて自動的に表示を切り替えることができます。
位置情報、カメラ、マイクといったデバイス機能へのアクセスも可能です。
ただし、利用時には必ずユーザーの許可が必要になります。
決済機能としては、Apple Payが利用できます。
PWA上でもApple Payを使った支払い処理が実装できるため、ECサイトなどには有用です。
対応していない・制限のある機能
一方で、iOSのPWAには多くの制約があります。
まず、自動インストールプロンプトが表示されません。
Androidでは、PWA対応サイトを訪れると「インストールしますか？」というポップアップが自動的に表示されますが、iOSにはこの仕組みがありません。ユーザーが自分でSafariのメニューから操作する必要があり、多くのiPhoneユーザーはこの機能自体を知らないのが現状です。
汎用的なバックグラウンド同期・定期更新・大容量DL系APIは未対応です。
アプリを閉じている間に、サーバーから最新情報を取得したり、送信に失敗したデータを自動的に再送信したりといった処理ができないのです。これは後のセクションで詳しく解説します。
ハードウェア連携にも大きな制限があります。
Bluetooth機器との接続、NFCを使ったかざし決済や認証、USB機器との連携など、ハードウェアを直接制御する機能はほとんど使えません。フィットネストラッカーやIoTデバイスとの連携が必要なサービスでは、PWAでは実現できない可能性が高いです。
ファイルシステムへの直接アクセスは部分対応だが制約が大きいのが現状です。
ユーザーのデバイス内のファイルを読み書きする機能は制限されており、Androidで使える高度なファイル操作はiOSでは利用できません。
一部のデバイスセンサーも使えません。
照度センサー（画面の明るさを周囲に合わせて調整する）や近接センサー（耳に近づけた時に画面を消す）などは、PWAからはアクセスできません。
このように、iOSのPWAは「基本的な機能は使えるものの、高度な機能には多くの制約がある」という状態です。サービスの企画段階で、これらの制約を理解しておくことが重要です。
プッシュ通知：iOSの制約を理解する
プッシュ通知は、ユーザーとの継続的な接点を作るための重要な機能です。iOS 16.4でようやく対応しましたが、Androidとは異なる独特の制約があります。
iOS 16.4で実現したこと
iOS 16.4（2023年3月リリース）以降、PWAでもWeb Push APIを使ったプッシュ通知が利用できるようになりました。これにより、以下のことが可能になっています。
- ユーザーがアプリを閉じている状態でも通知を届けられる
- 通知にアクションボタンを付けて、タップ時の挙動を制御できる
- 通知からアプリを直接起動できる
ここまではAndroidと同様の機能ですが、iOSには重要な制約があります。
制約条件
iOSでプッシュ通知を使うには、以下の条件を全て満たす必要があります。
-
iOS 16.4以降であること
iOS 16.4は2023年3月にリリースされたため、それ以前のバージョンを使っているユーザーには通知を送ることができません。2026年時点では多くのユーザーがアップデートしていると考えられますが、企業支給のiPhoneなど、古いバージョンを使い続けているケースもあります。 -
ホーム画面に追加されていること
これが最も重要な制約です。SafariでWebサイトを開いているだけでは、通知の許可を求めることすらできません。必ず「ホーム画面に追加」という操作を経てから、初めて通知許可のダイアログが表示できるようになります。つまり、「ホーム画面追加→通知許可」という順序が必須なのです。 -
Safariブラウザ上では通知が使えない
Androidでは、Chromeブラウザで開いたWebサイトでもプッシュ通知を受け取れますが、iOSのSafariではそれができません。あくまで「ホーム画面に追加したPWA」でのみ通知が機能します。 -
display設定がstandaloneである必要がある
PWAの設定ファイル（manifest.json）には、アプリをどのように表示するかを指定するdisplayという項目があります。ここでbrowser（ブラウザモードで開く）を指定していると、プッシュ通知が使えません。standalone（アプリ単体で開く）を指定する必要があります。
ホーム画面への追加：iOSの大きな壁
プッシュ通知を使うにも、アプリらしい体験を提供するにも、まずユーザーに「ホーム画面に追加」してもらう必要があります。ここでiOSには１つのハードルがあります。
Androidとの決定的な違い
AndroidのChromeでPWA対応サイトを訪れると、一定の条件を満たした時点で自動的に「このアプリをインストールしますか？」というポップアップが表示されます。ユーザーが「インストール」をタップすれば、すぐにホーム画面にアイコンが追加され、次回からはアプリのように起動できます。
この仕組みを実現しているのが「beforeinstallprompt」というイベントです。これは、ブラウザが「このサイトはPWAとしてインストール可能だ」と判断したときに発火するもので、開発者はこのイベントを使って、インストールを促すタイミングをコントロールできます。例えば「初回訪問ではなく、3回目の訪問時に表示する」「特定のページに到達したら表示する」といった細かな制御が可能です。
ところが、iOSではブラウザ側から自動的にインストールを促す仕組みがありません。
iOSでのインストール手順
iOSでPWAをホーム画面に追加するには、ユーザー自身が以下の手順を実行する必要があります。
- Safariで対象のWebサイトを開く
- 画面下部（またはアドレスバー）の「共有」ボタンをタップ
- 表示されたメニューを下にスクロール
- 「ホーム画面に追加」を選択
- アプリ名を確認して「追加」をタップ
この手順は、iPhoneに慣れたユーザーでも知らない人が多く、ましてやWebサイトを普段使っているだけのユーザーには「そもそもそんなことができる」という認識すらありません。
ストレージとキャッシュの制限
ストレージ上限の改善と残る制約
iOS初期のPWAでは約50MBという厳しいストレージ制限がありましたが、Safari 17（2023年リリース）以降、ストレージクォータが大幅に改善されました。
現在は、デバイスの総ディスク容量の最大60%まで（オリジン単位）利用できるようになっています。例えば、デバイスの総ストレージ容量が256GBであれば、最大約153GB（256×0.6）まで利用可能です。
改善されたこと
- 大容量コンテンツのキャッシュが可能に
- 画像や動画を多用するサービスでも実用的に
- ECサイトの商品カタログ、メディアアプリのコンテンツ保存が現実的に
ただし依然として残る制約
- Chromeと比べると依然として厳しい管理
- 「永続的なストレージ保証」はない
- デバイスの空き容量に依存するため、ユーザー環境により大きく変動
バックグラウンド機能の制限
ネイティブアプリでは当たり前のように使える「バックグラウンド処理」が、iOSのPWAでは一切できません。この制約は、特定のタイプのサービスにとって大きな障壁となります。
対応していないバックグラウンド機能
バックグラウンド機能とは、ユーザーがアプリを閉じている間も裏で動作する仕組みのことです。iOSでは、以下のような機能が全て使えません。
Background Sync（バックグラウンド同期）
これは、送信に失敗したデータを後で自動的に再送信する機能です。
例えば、メッセージアプリでメッセージを送信しようとした瞬間に電波が途切れたとします。Androidであれば、Background Sync APIによって「電波が回復したら自動的に再送信」という処理が可能です。ユーザーは特に何もしなくても、気づいたらメッセージが送信されています。
しかしiOSでは、ユーザーが再度アプリを開いて、手動で送信し直す必要があります。「送信失敗」の通知すら出せないため、ユーザーは送信できなかったことに気づかない可能性もあります。
影響を受けるサービス
- メッセージングアプリ、SNS
- フォーム送信が重要なサービス
- レビュー投稿機能
- データ保存が必要な業務アプリ
Periodic Background Sync（定期バックグラウンド同期）
これは、アプリを閉じていても定期的に最新データを取得する機能です。
例えば、ニュースアプリを朝開く前に、裏で最新記事をダウンロードしておく、といったことがAndroidでは可能です。ユーザーがアプリを開いた瞬間には、既に最新コンテンツが表示される状態になっています。
iOSでは、ユーザーがアプリを開いた瞬間から通信が始まるため、「アプリを開く→ローディング→コンテンツ表示」という流れになり、表示までに時間がかかります。
また、オフライン時にアプリを開くと、古いキャッシュ（もしくは何も表示されない）状態になってしまいます。
影響を受けるサービス
- ニュースアプリ、メディアアプリ
- SNSのフィード表示
- 天気予報、株価情報など、最新性が重要な情報
- コンテンツ配信サービス
Background Fetch（バックグラウンドフェッチ）
これは、大きなファイルをバックグラウンドでダウンロードする機能です。
音楽アプリで再生リストの曲を事前にダウンロードしておく、動画アプリでオフライン視聴用にコンテンツを保存しておく、といった使い方がAndroidでは可能です。ユーザーがアプリを使っている間だけでなく、閉じている間も裏でダウンロードが進みます。
iOSでは、アプリを開いたまま、ダウンロードが完了するまで待つ必要があります。アプリを閉じたり、他のアプリに切り替えたりすると、ダウンロードが中断されてしまう可能性があります。
影響を受けるサービス
- 音楽・ポッドキャスト配信アプリ
- 動画配信サービス
- 電子書籍アプリ
- 大容量ファイルを扱うサービス
standaloneモードによる注意点
PWAをアプリらしく見せるための「standaloneモード」ですが、これを使うことで新たな問題が発生します。
standaloneモードとは、SafariのアドレスバーやツールバーなどのブラウザUIを非表示にして、アプリ単体で動作しているように見せるモードです。プッシュ通知を使うためには、このモードが必須です。
しかし、ブラウザUIが消えることになるので、以下の項目は念の為注意点として把握しておきましょう。
スワイプジェスチャーが使えない
iPhoneのSafariでは、画面の左端から右にスワイプすると「戻る」、右端から左にスワイプすると「進む」という操作ができます。また、画面を下に引っ張ると「更新（Pull to refresh）」ができます。これらは、多くのiPhoneユーザーが日常的に使っている標準的な操作方法です。しかし、standaloneモードでは、これらのジェスチャーが全て機能しません。
標準的なナビゲーションボタンがない
Safariには「戻る」「進む」「更新」といったナビゲーションボタンが表示されていますが、standaloneモードではこれらも表示されません。
つまり、ページ内に実装されているリンクやボタンを使う以外に、ページ遷移をする手段がありません。
データの引き継ぎ問題
standaloneモードで起動したPWAと、Safariブラウザでは、データの保存領域が一部分離されています。
localStorageが共有されない
localStorageという、ブラウザ内にデータを保存する仕組みがあります。しかし、SafariとPWAでは、このlocalStorageが別々に管理されています。これが何を意味するかというと、例えば以下のような問題が起こります。
- ユーザーがSafariでサイトにアクセスし、ログインする
- ログイン状態がlocalStorageに保存される
- その後、ユーザーがPWAとしてホーム画面から起動する
- PWAではSafariのlocalStorageが読めないため、ログアウト状態になっている
- ユーザーは再度ログインする必要がある
Cookieは共有可能
一方で、Cookie（サーバーとのやり取りで使われる保存領域）は、ホーム画面追加時にコピーされます。そのため、認証情報などをCookieで管理すれば、SafariからPWAへのスムーズな引き継ぎが可能です。
ただし、これには技術的な対応が必要で、開発時に意識して設計する必要があります。
ハードウェア・デバイス機能へのアクセス制限
ネイティブアプリであれば自由にアクセスできるデバイスのハードウェア機能も、iOSのPWAではまだまだ制限されています。
対応していない主要機能
以下のハードウェア連携機能は、iOSのPWAでは利用できません。
Web Bluetooth
Bluetooth機器との通信を行うためのAPIです。Androidでは対応していますが、iOSでは全く使えません。具体的には、以下のようなデバイスとの連携ができません。
- フィットネストラッカー（心拍計、歩数計など）
- スマートウォッチ
- ワイヤレスイヤホンの詳細制御
- Bluetooth対応の医療機器
- IoT家電（スマート電球、温度計など）
例えば、ランニングアプリで心拍計と連携したい、健康管理アプリでフィットネストラッカーのデータを取得したい、といったニーズがあっても、PWAでは実現できません。
Web NFC
NFC（Near Field Communication：近距離無線通信）を使った通信を行うAPIです。具体的には、以下のような用途で使われます。
- かざして決済（非接触決済）
- 入退室管理（ICカードをかざして認証）
- 交通系ICカードの読み取り
- NFCタグの読み書き
日本では交通系ICカードやおサイフケータイなど、NFCが広く普及していますが、PWAではこれらと連携できません。
Web USB
USB接続された機器との通信を行うAPIです。具体的には、以下のようなデバイスとの連携ができません。
- USBメモリや外付けストレージへの直接アクセス
- USBカメラ（Webカメラ以外）
- プリンター
- 計測機器（オシロスコープ、温度センサーなど）
- 産業用機器
業務用アプリなどで、専用のUSB機器と連携したいというニーズがあっても、PWAでは対応できません。
Web Serial
シリアル通信を行うAPIです。これも主に業務用途や専門機器との連携で使われます。
- Arduinoなどのマイコンボード
- 古い産業用機器
- POSシステムの周辺機器
- 各種計測器
こうした機器と通信が必要なアプリでは、PWAは選択肢から外れます。
高度なセンサー
以下のようなセンサーへのアクセスも制限されています。
- 照度センサー（周囲の明るさを検知）
- 近接センサー（顔を近づけた時に画面を消す）
- 温度センサー
- 気圧センサー
これらは、環境に応じた細かなUI調整や、専門的な用途で使われるセンサーです。
制限付きで対応している機能
一方で、以下の機能は利用可能ですが、制約があります。
位置情報
GPSによる位置情報取得は可能です。ただし、以下の制約があります。
- 利用時には必ずユーザーの許可が必要
- バックグラウンドでの継続的な位置追跡はできない
- アプリを開いている間のみ取得可能
地図アプリや位置情報を使ったサービスは実現できますが、「移動を記録し続ける」「配達員の位置をリアルタイムで追跡する」といった、バックグラウンドでの連続的な位置取得が必要なサービスには向きません。
カメラ・マイク
カメラやマイクへのアクセスも可能です。ただし、
- 利用時には必ずユーザーの許可が必要
- セッションごとに許可を求められる場合がある
- 高度なカメラ制御（RAW撮影、手動フォーカスなど）は不可
ビデオ通話、写真投稿、音声録音といった基本的な用途には使えますが、プロ向けのカメラアプリのような高度な制御はできません。
モーションセンサー（加速度・ジャイロ）
端末の傾きや動きを検知するセンサーは利用可能です。ただし、
- iOS 13以降はユーザーの許可が必須
- 許可を得るまでデータにアクセスできない
ゲームやARアプリなど、端末の動きに応じた体験を提供する用途には使えますが、ユーザーが許可しなければ機能しません。
まとめ
iOSのPWA対応は、iOS 16.4でのプッシュ通知対応、Safari 17でのストレージ容量改善など、徐々に進化を続けています。基本的なPWA機能は実用レベルに達しており、コンテンツ閲覧型のサービスであれば十分に活用できる環境が整ってきました。
しかし、自動インストールプロンプトの欠如、バックグラウンド処理の制限、ハードウェア連携の制約など、Androidと比べて依然として大きな格差が残っているのも事実です。特にプッシュ通知を活用したい場合、ホーム画面への追加が必須となるため、ユーザーへの丁寧な案内設計が欠かせません。
PWAを検討する際は、対象ユーザーのiOS比率、必須機能のiOS対応状況、プッシュ通知の重要度などを総合的に判断することが重要です。iOS制約を理解した上で、段階的なアプローチも含めて最適な選択をしていくことをお勧めします。
