PWA×iOSでできること完全まとめ【2026年版】できること・できないことを一発で理解

「PWAって、結局iPhoneでどこまで使えるの？」

iOSのPWAは、この数年でかなり変わりました。

以前は不安定だった機能が普通に使えるようになった一方で、現在でもAndroidとは挙動が異なる部分があります。

PWA LABで実際のiPhoneを使って検証を繰り返してきた結論はシンプルです。

2026年のiOSではPWAの主要機能はかなり実用的。ただし、Android Chromeと同じものとして設計してはいけません。

ホーム画面への追加、スタンドアロン表示、Web App Manifest、start_url、scope、アイコン、Service Worker、Web Push、各種Web APIなど、Webアプリを作るための基本機能はiPhoneでも利用できます。

一方で、インストール方法、displayの扱い、アイコンの優先順位、ストレージ、Manifestの一部の挙動などにはiOS独自の癖があります。

この記事では、2026年現在のiPhoneでPWAが「できること」と「できないこと」を、実機検証をもとに整理します。

早見表：2026年のiOS PWAでできること・できないこと

ホーム画面からワンタップで起動する軽量なWebアプリを作るのであれば、必要な機能はかなり揃っています。

問題になりやすいのは「iOSでPWAが使えるか」ではなく、Androidとまったく同じ動きをすると思って実装してしまうことです。

ホーム画面への追加とスタンドアロン表示は使える

まず、PWAの基本となるホーム画面からの起動はiPhoneでも利用できます。

Webサイトをホーム画面へ追加すると専用のアイコンから起動でき、Webアプリとして開いた場合は通常のSafariとは異なるアプリ風の画面で利用できます。

HTML、CSS、JavaScriptをはじめ、多くのモダンなWeb APIもこの環境でそのまま利用できます。

そのため、軽量なツールやダッシュボード、個人ページなどであれば、これだけでも十分に「アプリ」として使える体験を作れます。

ただし、Manifestのdisplayに書ける値が、すべてAndroidと同じように反映されるわけではありません。

特にfullscreenやminimal-uiについては、Android Chromeと同じ表示を期待しない方が安全です。

iPhone向けに安定したアプリ風表示を作るのであれば、基本はstandaloneを中心に考えるのが分かりやすいでしょう。

start_urlはiOSでも使える。ただし「どこを入口にするか」が重要

start_urlは、ユーザーがホーム画面のアイコンをタップしたときに、最初に開くURLを指定する項目です。

iOSでも利用できます。

{
  "start_url": "/dashboard/"
}

例えば、サイト内のどこからホーム画面へ追加されても、起動時には必ず/dashboard/を表示するといった設計ができます。

ただし、個別ページやユーザーごとのページを扱うWebサイトでは注意が必要です。

ユーザーは「今見ているこのページ」をホーム画面へ置いたつもりなのに、起動すると毎回サイトトップへ戻される。

これでは、ユーザーが保存したものと実際の起動位置が一致しません。

start_urlは単なる起動設定ではなく、そのホーム画面アイコンが「何への入口なのか」を決める設定でもあります。

ページ単位で入口を作る場合は、現在ページを基準にした設計や"."のような相対指定が適しているケースもあります。

scopeはiOSでも機能する

scopeは、そのWebアプリがどのURL範囲をアプリ内部として扱うかを決める設定です。

{
  "start_url": "/app/dashboard/",
  "scope": "/app/"
}

例えばscope: "/app/"なら、/app/以下をWebアプリの範囲として設計できます。

iOSでもscopeは実際の表示体験に影響します。

scope内ではアプリ風の表示を維持し、そこから外れたページへ移動するとブラウザ的なUIが現れるなど、「ここまでがアプリ」という境界を作るために使えます。

サイト全体を1つのアプリとして扱いたいならscope: "/"、特定のツールだけをアプリとして扱いたいならscope: "/tool/"のように、用途によって範囲を変えられます。

ただし、同じドメインから複数のホーム画面Webアプリを作る場合など、AndroidとiOSでは実際の扱いが異なるケースがあります。

このあたりはManifestだけを見て判断せず、両OSで実際にホーム画面へ追加して確認するのが確実です。

ホーム画面の名前とアイコンも変更できる

Web App Manifestでは、ホーム画面に表示する名前やアイコンを設定できます。

{
  "name": "OJapp PWA LAB",
  "short_name": "PWA LAB",
  "icons": [
    {
      "src": "/icon.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

short_nameは、ホーム画面の限られたスペースに収まる短い名前を設定したい場合に便利です。

長いサイトタイトルが途中で「...」と省略されるより、ホーム画面用の短い名前を用意した方が自然に見えます。

少し複雑なのがアイコンです。

iOSではWeb App Manifestのiconsを利用できますが、Safariには以前からapple-touch-iconという仕組みがあります。

<link rel="apple-touch-icon" href="/assets/apple-icon.png">

HTML側に固定のapple-touch-iconが存在すると、ホーム画面で使用されるアイコンに影響する場合があります。

特に、ページごと・ユーザーごとに異なるアイコンを動的に設定したい場合は要注意です。

Manifestでは個別のアイコンを指定しているのに、HTMLに残っている共通のapple-touch-iconが使われてしまう、といったことがあります。

Androidにはmaskableアイコン特有の挙動もあるため、同じアイコン設定がiPhoneとAndroidでまったく同じ結果になるとは限りません。

Service Workerとオフライン対応も利用できる

iOSでもService Workerを利用できます。

実用的なのは、例えば次のような使い方です。

• HTML・CSS・JavaScriptなどのキャッシュ
• 2回目以降の起動を高速化する
• 一時的に通信が切れた場合のフォールバック
• 軽量なツールの一部をオフラインでも利用可能にする

一方で、「一度保存した大量のデータが永久に端末へ残り続ける」という前提で設計するのはおすすめできません。

iOS側にもストレージ管理があるため、Webアプリ側だけで保存状態を完全に保証することはできません。

そのためiOSでは、Service Workerを「巨大な完全オフラインアプリを作るための保存領域」と考えるより、通信状態に強く、起動の速いWebアプリを作るための仕組みとして使う方が現実的です。

Web Push通知もiOSで利用できる

iPhoneのホーム画面WebアプリではWeb Pushも利用できます。

ただし、通知許可にはユーザー自身の操作が必要です。

ページを開いた瞬間に無理やり許可を求めるのではなく、「通知を有効にする」といったボタンをユーザー自身が操作した流れの中で許可を求める設計が基本になります。

そのため、通知が重要なサービスでは、単にPushを実装するだけではなく、なぜ通知が必要なのかを説明してから許可を求めるUXまで含めて設計する必要があります。

Screen Wake Lockで画面のスリープも防止できる

タイマーやレシピ、QRコード表示などでは、操作していない間に画面が暗くなると困ることがあります。

このような用途では、Screen Wake Lock APIを利用して画面がスリープするのを防ぐことができます。

• タイマー
• レシピ
• QRコード表示
• ダッシュボード
• チェックリスト

ちなみにScreen Wake LockはPWA専用機能ではありません。

通常のJavaScriptから利用するWeb APIです。

ただ、ホーム画面からスタンドアロンで起動したWebアプリと組み合わせることで、「専用アプリを起動して、その間は画面が消えない」という自然な体験になります。

PWAはそれ自体がすべての機能を提供するというより、Web APIとホーム画面からのアプリ風起動を組み合わせることで、アプリらしい体験を作れるのが面白いところです。

iOSのPWAで期待しすぎない方がいいこと

ここまで見るとかなり多くのことができますが、iOSとAndroidが完全に同じになったわけではありません。

特に次のような機能は、Androidと同じ挙動を前提にしない方が安全です。

• Android Chromeのようなブラウザ主導のインストール誘導
• Androidと同じdisplay: fullscreenの挙動
• 画面向きを強制する細かな制御
• Androidと同じmaskableアイコン処理
• 大量データの永続的なオフライン保存
• ネイティブアプリ並みのバックグラウンド処理

そして実際の運用で特に大きいのが「ホーム画面へ追加してもらうまでの導線」です。

AndroidとiPhoneでは追加方法やブラウザ側の案内が異なるため、Webサイト側からユーザーへ操作方法を案内することが重要になります。

どれだけManifestを綺麗に作っても、ユーザーがホーム画面へ追加する方法を知らなければ、ホーム画面Webアプリとして使ってもらえません。

iOS向けPWAでは、技術だけでなく**「どうやってホーム画面へ置いてもらうか」というUX**も重要です。

iOSとAndroidのPWAは分けて考えた方がいい

PWA LABで実機検証を続けていて、特に強く感じるのがこれです。

同じWeb App Manifestでも、iOSとAndroidで実際の挙動が異なることがあります。

例えば、こんな違いに遭遇します。

• iPhoneだけ別のアイコンが使われる
• fullscreenの見え方が違う
• scope外へ移動したときのUIが違う
• 同一ドメインから複数のホーム画面アプリを作ったときの扱いが違う

こうした違いは、必ずしもManifestの書き方を間違えているから起きるわけではありません。

それぞれのOSが、ホーム画面Webアプリを異なる方法で扱っていることが原因の場合もあります。

そのため「PWAだからクロスプラットフォームで全部同じ」と考えるより、共通のWeb技術を使いながら、ホーム画面UXはiOSとAndroidで別々に確認するという考え方の方が実践的です。

2026年のiOS PWAはどう設計するべき？

すべてのネイティブアプリ機能をPWAで再現する必要はありません。

むしろ、Webが得意な部分を活かした方がPWAの良さが出ます。

1. 普通のURLとしてすぐアクセスできるようにする
2. ホーム画面から便利に起動できる入口を作る
3. start_urlを「ユーザーがどこを保存したいか」で考える
4. scopeを実際のアプリ範囲に合わせる
5. ホーム画面で分かりやすい名前とアイコンを用意する
6. Service Workerは必要なところだけに使う
7. Wake LockなどのWeb APIを用途に応じて組み合わせる
8. iOSとAndroidを別々に実機確認する

タイマー、ダッシュボード、プロフィールページ、チェックリスト、小規模な業務ツールなどは、必ずしもApp Storeから大きなアプリをインストールしてもらう必要はありません。

普通のWebページとしてアクセスでき、必要な人だけがホーム画面へ置いてワンタップで使える。

この「Webとアプリの間」にある使い方は、2026年でもPWAがかなり得意な領域です。

関連記事

PWAそのものの基本的な構造やメリットを確認したい場合は、PWAとは？スマホのWebサイトを“アプリ化”する仕組みをわかりやすく解説でまとめています。

Web App ManifestやService Workerの具体的な実装については、PWAの作り方｜manifest.json・Service Worker・ホーム画面対応を丁寧に解説で紹介しています。

iPhoneに昔からあるWebClipとの違いについては、PWAとWebClipの違いとは？iPhoneではどっちを使うべきかも参考にしてください。

まとめ：iOSでもPWAは十分実用的

2026年現在、iPhoneでもPWAの主要な機能は利用できます。

• ホーム画面への追加
• スタンドアロン表示
• Web App Manifest
• start_urlとscope
• ホーム画面アイコン
• Service Worker
• オフライン対応
• Web Push
• Screen Wake LockなどのWeb API

現在のiOS PWAで難しいのは、「機能が何も使えないこと」ではありません。

iOSとAndroidでホーム画面Webアプリの扱いが異なることを理解して設計することです。

両OSがまったく同じように動くことを期待せず、それぞれの挙動に合わせて設計すれば、PWAは2026年現在でもiPhoneで十分に実用的です。

Webの軽さを残したまま、必要なページをユーザーのホーム画面からすぐ開ける。

そこが、今のPWAの一番わかりやすい強みです。