この記事の要約
本記事は、2026年時点のiOSにおけるPWA（Progressive Web App：Webサイトをスマホアプリのように使える技術）の対応状況を、Androidとの比較を交えながら整理した内容です。
結論から言うと、iOSのPWAは以前よりかなり実用的になった一方で、なお制約が多く、「万能なアプリ代替」と見るのは危険です。iOSでは、ホーム画面への追加、オフライン利用、カメラ・マイク・位置情報の利用、Apple Pay、ダークモード対応に加え、iOS 16.4以降はプッシュ通知とバッジ表示にも対応しました。これにより、情報配信系や会員向けサービス、簡易な業務アプリでは十分に採用候補になります。一方で、Androidにある自動インストール促進機能がiOSにはなく、ユーザー自身がSafariの共有メニューから手動で「ホーム画面に追加」しなければなりません。また、バックグラウンド同期（アプリを閉じていても裏側でデータ送受信する仕組み）、定期更新、大容量ファイル処理、Bluetooth・NFC・USBなどのハードウェア連携、ファイルシステムへの直接アクセスは未対応または大きく制限されています。
さらに、PWAとして起動した画面ではSafari標準の戻るスワイプが効かない、SafariとPWAでlocalStorage（ブラウザ内の簡易保存領域）が共有されない場合があるなど、使い勝手にも注意点があります。要するに、iOSのPWAは「低コストで広く展開したい」用途には強いですが、ネイティブアプリ並みの高度な操作性や端末機能連携を前提にすると厳しい、というのが実態です。ビジネス判断としては、機能要件とiPhoneユーザー比率を見たうえで、PWAで足りるのか、最初からネイティブアプリを選ぶべきかを冷静に切り分ける必要があります。
はじめに
PWA（Progressive Web App）は、Webサイトをアプリのように使える技術として注目を集めています。開発コストを抑えながらクロスプラットフォーム対応ができる点が魅力ですが、iOSではAndroidと異なる仕様や制約が残っています。しかし一方では、Web Pushやストレージ機能などの対応は進んでおり、iOS 26ではホーム画面に追加したWebサイトの扱いにも変更が加えられています。
現状日本では約50%がiphoneユーザーと言われている中で、“Androidと同様に充分にサービスを提供できるか”が皆様の関心どころかと思います。
本記事では、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がPWAへの制限をApp Store収益保護を目的として行っていると公式に説明しているわけではありません。
その他の要因としては、セキュリティとプライバシーへの配慮です。Service Workerは、ユーザーがアクセスするWebページの内容を全て見ることができ、サーバーからの応答を書き換えることもできる強力な権限を持っています。悪意のあるサイトがこれを悪用すれば、個人情報の盗聴や改ざん、フィッシング詐欺なども可能になってしまいます。「iPhoneは安全」というブランドイメージを最優先する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機能を復活させることを発表しました。
この一連の変更は、DMA対応に伴う代替ブラウザエンジンへの対応と、Home Screen Web Appsのセキュリティ・プライバシー上の設計をめぐる問題を浮き彫りにしました。Appleはその後、既存のWebKitベースのHome Screen Web AppsについてEUでも提供を継続する方針に変更しました。
Androidの対応状況（比較として）
一方、GoogleはPWAを積極的に推進してきました。Android版のChromeでは、PWA対応サイトにアクセスすると自動的にインストールを促すポップアップが表示されます。ユーザーが「インストール」をタップすれば、ホーム画面にアイコンが追加され、まるでネイティブアプリのように使えるようになります。
さらに、Androidではバックグラウンドでのデータ同期や定期的な情報更新といった高度な機能もサポートされており、ネイティブアプリに近い体験が実現できます。
このように、AndroidとiOSの間には、PWA対応において差があります。同じPWAを開発しても、Androidユーザーには快適に使ってもらえる一方で、iOSユーザーには制約の多い体験になってしまうという現実があります。
iOS 26でのPWA対応状況：何ができて何ができないか
それでは、2026年時点の最新版であるiOS 26では、具体的にどのような機能が使えるのでしょうか。対応している機能と、対応していない機能を整理してご紹介します。
対応している主要機能
まず、iOS上のPWAで使える機能から見ていきましょう。
ホーム画面への追加は可能です。
ただし、”ホーム画面に追加するにはSafariなどのブラウザアプリ自体のメニューから操作する必要がある”という大きな制約があります。一度ホーム画面に追加すれば、アイコンをタップするだけでアプリのように起動できます。
また、ホーム画面に追加したサイトは、iOS 26以降は既定でWebアプリとして開くようになりました。
これまでは、Web App Manifest（Webアプリの設定情報を記述するJSONファイル）などで「アプリとして表示してよい」と宣言したサイトだけがアプリ風に開き、それ以外は通常のブラウザで開いていました。iOS 26以降は、どのサイトでもホーム画面に追加すれば既定でWebアプリとして開くようになり、ユーザーは追加時に「Webアプリとして開く」をオフにすれば、ブックマークとして開くこともできます。
フルスクリーン表示や専用アイコン、オフライン動作といった本格的なPWA機能を利用するには、これまでどおりマニフェストとService Workerの実装が必要です。ただし、プッシュ通知に関しては、Declarative Web Pushの登場によって、Service Workerなしでも実装可能になりました。Service Workerは、受信したプッシュメッセージをローカルデータと組み合わせてカスタマイズしたい場合にオプションとして活用できます。あくまで「アプリ風に開く」という入り口のハードルが下がった変更であり、Appleが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」でのみ通知が機能します。 -
【補足】2026年の変更点：display設定がstandaloneである必要がなくなった
PWAの設定ファイル（manifest.json）には、アプリをどのように表示するかを指定するdisplayという項目があります。従来のiOSでは、Web App Manifestのdisplayをstandaloneまたはfullscreenに設定することで、ホーム画面からWebアプリとして起動する仕組みが利用されていました。
しかしiOS 26では仕様が変更され、ホーム画面に追加したWebサイトは、ユーザーが「Webアプリとして開く」を選択することでWebアプリとして起動できます。manifestのdisplay設定にかかわらず、ユーザー側でWebアプリとして開くかどうかを選択できる点が大きな変更です。
standalone は、PWAを普通のWebページではなく、アプリのように表示する設定です。
具体的には、ブラウザのURLバーやタブが目立たず、独立したアプリ画面のように開くイメージです。
つまり、「Webサイトをアプリっぽく見せる表示モード」のことをいいます。
ホーム画面への追加：iOSの大きな壁
プッシュ通知を使うにも、アプリらしい体験を提供するにも、まずユーザーに「ホーム画面に追加」してもらう必要があります。ここでiOSには１つのハードルがあります。
ブラウザの設定から手動でインストールする必要があることを理解してもらわなければいけない
AndroidのChromeでPWA対応サイトを訪れると、一定の条件を満たした時点で自動的に「このアプリをインストールしますか？」というポップアップが表示されます。ユーザーが「インストール」をタップすれば、すぐにホーム画面にアイコンが追加され、次回からはアプリのように起動できます。
この仕組みを実現しているのが「beforeinstallprompt」というイベントです。これは、ブラウザが「このサイトはPWAとしてインストール可能だ」と判断したときに発火するもので、開発者はこのイベントを使って、インストールを促すタイミングをコントロールできます。例えば「初回訪問ではなく、3回目の訪問時に表示する」「特定のページに到達したら表示する」といった細かな制御が可能です。
ところが、iOSではブラウザ側から自動的にインストールを促す仕組みがありません。
iOSでのインストール手順
iOSでPWAをホーム画面に追加するには、ユーザー自身が以下の手順を実行する必要があります。
- Safariで対象のWebサイトを開く
- 画面下部（またはアドレスバー）の「共有」ボタンをタップ
- 表示されたメニューを下にスクロール
- 「ホーム画面に追加」を選択
- アプリ名を確認して「追加」をタップ
この手順は、iPhoneに慣れたユーザーでも知らない人が多く、ましてやWebサイトを普段使っているだけのユーザーには「そもそもそんなことができる」という認識すらありません。
ストレージとキャッシュの制限
ストレージ上限の改善と残る制約
iOS初期のPWAでは約50MBという厳しいストレージ制限がありましたが、Safari 17（2023年リリース）以降、ストレージクォータが大幅に改善されました。
ストレージクォータ：アプリやWebサイトが端末やブラウザ内に保存できるデータ容量の上限のこと
Safari 17 / iOS 17以降、WebKitではオリジン単位のストレージクォータがデバイスの総ディスク容量を基準に計算されるようになり、ブラウザアプリでは最大60%という大きな上限が設定されています。
ただし、これは実際にその容量を確保できることを意味するものではなく、利用可能容量は端末の空き容量や利用状況などによって変動します。また、WebKitにはストレージを自動削除する仕組みもあります。
改善されたこと
- 大容量コンテンツのキャッシュが可能に
- 画像や動画を多用するサービスでも実用的に
- ECサイトの商品カタログ、メディアアプリのコンテンツ保存が現実的に
ただし依然として残る制約
- Chromeと比べると依然として厳しい管理
- 「永続的なストレージ保証」はない
- デバイスの空き容量に依存するため、ユーザー環境により大きく変動
バックグラウンド機能の制限
iOSのPWAでは、ネイティブアプリのように任意の処理をバックグラウンドで継続実行できるわけではありません。
Web Pushなど、特定の用途ではバックグラウンド処理が可能ですが、Background SyncやPeriodic Background Syncなど、Web標準として提供されている汎用的なバックグラウンド処理には制約があります。
対応していないバックグラウンド機能
バックグラウンド機能とは、ユーザーがアプリを閉じている間も裏で動作する仕組みのことです。iOSでは、以下のような機能が全て使えません。
Background Sync（バックグラウンド同期）
これは、送信に失敗したデータを後で自動的に再送信する機能です。
例えば、メッセージアプリでメッセージを送信しようとした瞬間に電波が途切れたとします。Androidであれば、Background Sync APIによって「電波が回復したら自動的に再送信」という処理が可能です。ユーザーは特に何もしなくても、気づいたらメッセージが送信されています。
しかしiOSでは、ユーザーが再度アプリを開いて、手動で送信し直す必要があります。「送信失敗」の通知すら出せないため、ユーザーは送信できなかったことに気づかない可能性もあります。
影響を受けるサービス
- メッセージングアプリ、SNS
- フォーム送信が重要なサービス
- レビュー投稿機能
- データ保存が必要な業務アプリ
Periodic Background Sync（定期バックグラウンド同期）
これは、アプリを閉じていても定期的に最新データを取得する機能です。
例えば、ニュースアプリを朝開く前に、裏で最新記事をダウンロードしておく、といったことがAndroidでは可能です。ユーザーがアプリを開いた瞬間には、既に最新コンテンツが表示される状態になっています。
iOSでは、ユーザーがアプリを開いた瞬間から通信が始まるため、「アプリを開く→ローディング→コンテンツ表示」という流れになり、表示までに時間がかかります。
また、オフライン時にアプリを開くと、古いキャッシュ（もしくは何も表示されない）状態になってしまいます。
影響を受けるサービス
- ニュースアプリ、メディアアプリ
- SNSのフィード表示
- 天気予報、株価情報など、最新性が重要な情報
- コンテンツ配信サービス
Background Fetch（バックグラウンドフェッチ）
これは、大きなファイルをバックグラウンドでダウンロードする機能です。
iOSではWebアプリ向けに、ネイティブアプリのようなバックグラウンドダウンロードAPIが利用できません。
アプリを開いたまま、ダウンロードが完了するまで待つ必要があります。アプリを閉じたり、他のアプリに切り替えたりすると、ダウンロードが中断されてしまう可能性があります。
影響を受けるサービス
- 音楽・ポッドキャスト配信アプリ
- 動画配信サービス
- 電子書籍アプリ
- 大容量ファイルを扱うサービス
standaloneモードによる注意点
PWAをアプリらしく見せるための「standaloneモード」ですが、これを使うことで新たな問題が発生します。
standaloneモードとは、SafariのアドレスバーやツールバーなどのブラウザUIを非表示にして、アプリ単体で動作しているように見せるモードです。プッシュ通知を使うためには、このモードが必須です。
しかし、ブラウザUIが消えることになるので、以下の項目は念の為注意点として把握しておきましょう。
ブラウザ固有のナビゲーションUIやジェスチャーを前提にした設計は避ける必要がある
iPhoneのSafariでは、画面の左端から右にスワイプすると「戻る」、右端から左にスワイプすると「進む」という操作ができます。また、画面を下に引っ張ると「更新（Pull to refresh）」ができます。これらは、多くのiPhoneユーザーが日常的に使っている標準的な操作方法です。しかし、standalone / Web AppモードではSafariのアドレスバーやツールバーなどのブラウザUIが表示されません。そのため、Safariで利用できるブラウザ固有のナビゲーションUIやジェスチャーを前提にした設計は避け、アプリ内に「戻る」「閉じる」「更新」などの操作を適切に用意する必要があります。
標準的なナビゲーションボタンがない
Safariには「戻る」「進む」「更新」といったナビゲーションボタンが表示されていますが、standaloneモードではこれらも表示されません。
つまり、ページ内に実装されているリンクやボタンを使う以外に、ページ遷移をする手段がありません。
データの引き継ぎ問題
standaloneモードで起動したPWAと、Safariブラウザでは、データの保存領域が一部分離されています。
localStorageが共有されない
localStorageという、ブラウザ内にデータを保存する仕組みがあります。しかし、SafariとPWAでは、このlocalStorageが別々に管理されています。これが何を意味するかというと、例えば以下のような問題が起こります。
- ユーザーがSafariでサイトにアクセスし、ログインする
- ログイン状態がlocalStorageに保存される
- その後、ユーザーがPWAとしてホーム画面から起動する
- PWAではSafariのlocalStorageが読めないため、ログアウト状態になっている
- ユーザーは再度ログインする必要がある
Cookieは共有可能
一方、Cookieについては、Home Screen Web Appを作成する際にSafariからCookieがコピーされる仕組みがあります。そのため、認証状態をCookieで管理している場合は、SafariからWeb Appへのログイン状態を引き継げるケースがあります。ただし、Cookieの種類や認証方式によって挙動が異なるため、実機での確認が必要です。
ハードウェア・デバイス機能へのアクセス制限
ネイティブアプリであれば自由にアクセスできるデバイスのハードウェア機能も、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による位置情報取得は可能です。ただし、以下の制約があります。
- 利用時には必ずユーザーの許可が必要
- Webアプリからネイティブアプリと同様の継続的バックグラウンド位置追跡を行うことはできない
地図アプリや位置情報を使ったサービスは実現できますが、「移動を記録し続ける」「配達員の位置をリアルタイムで追跡する」といった、バックグラウンドでの連続的な位置取得が必要なサービスには向きません。
カメラ・マイク
カメラやマイクはWeb APIから利用できますが、ユーザーによる権限許可が必要です。また、ネイティブアプリで利用できるすべてのカメラ・マイク制御機能がWeb APIから利用できるわけではありません。
モーションセンサー（加速度・ジャイロ）
端末の傾きや動きを検知するセンサーは利用可能です。ただし、
- iOS 13以降はユーザーの許可が必須
- 許可を得るまでデータにアクセスできない
ゲームやARアプリなど、端末の動きに応じた体験を提供する用途には使えますが、ユーザーが許可しなければ機能しません。
実際にPWAを開発するための費用について
以上がiOSにおいてのPWAの対応状況です。実際にPWA開発を検討されている方に以下記事では開発費用について解説しております。併せてご覧ください。
まとめ
iOSのPWA対応は、iOS 16.4でのプッシュ通知対応、Safari 17でのストレージ容量改善など、徐々に進化を続けています。基本的なPWA機能は実用レベルに達しており、コンテンツ閲覧型のサービスであれば十分に活用できる環境が整ってきました。
しかし、自動インストールプロンプトの欠如、バックグラウンド処理の制限、ハードウェア連携の制約など、Androidと比べて依然として差が残っているのも事実です。特にプッシュ通知を活用したい場合、ホーム画面への追加が必須となるため、ユーザーへの丁寧な案内設計が欠かせません。
PWAを検討する際は、対象ユーザーのiOS比率、必須機能のiOS対応状況、プッシュ通知の重要度などを総合的に判断することが重要です。iOS制約を理解した上で、段階的なアプローチも含めて最適な選択をしていくことをお勧めします。
