iPhoneでWebページを見ていて、「このページをすぐ開けるようにしたい」とホーム画面に追加した。
ところが、ホーム画面にできたアイコンをタップすると、追加したはずのページとは違うページが開く。
追加方法を間違えたのかと思って、もう一度同じページから追加しても結果は同じ。
実はこれ、Safariの不具合とは限りません。サイトがPWAとして設定されている場合、Web App Manifestのstart_urlによって、ホーム画面からの起動先が別のURLに指定されていることがあります。
今回はまずユーザー側から見た「なぜ違うページが開くのか？」を整理し、そのあとWebサイトを作る側から、なぜこの挙動になるのか、どう設計すればいいのかを考えてみます。
例えばWeb版Xのプロフィールをホーム画面に追加した場合
この問題は、Web版Xを例にするとかなりわかりやすいです。
SafariでWeb版Xを開き、あるユーザーのプロフィールを見ていたとします。
「このプロフィールをよく見るから、ホーム画面からすぐ開けるようにしよう」
そう思って、そのプロフィールページを表示した状態でSafariの共有メニューを開き、「ホーム画面に追加」を選びます。
ユーザーの感覚としては、当然 「今見ているプロフィールをホーム画面に追加した」 つもりです。
ところが、追加されたXのアイコンをホーム画面から起動すると、そのプロフィールではなくXのおすすめフィードなど、X側で設定されたアプリの入口が開くことがあります。
「あれ？ このプロフィールを追加したはずなのに？」
初めてこの挙動に遭遇したら、そう思っても不思議ではありません。
XのPWAとしては間違った動作ではない
ここで大事なのは、これを単純に「Xがおかしい」「PWAがおかしい」と考えないことです。
Xを1つのアプリとして考えるなら、ホーム画面のXアイコンからXの決められた入口を起動する設計は自然です。
ネイティブアプリのXを起動したときも、「以前見ていた誰かのプロフィールを必ず開いてほしい」とは通常考えません。
つまり、サービス全体を1つのAppとして考えるなら、この設計には筋が通っています。
ただし、Webにはもう一つの感覚があります。
ユーザーは「Xをインストールした」のではなく、「今見ているURLでホーム画面に追加を押した」と考える可能性がある。
ここに、PWAのアプリとしての設計と、Webページを保存するユーザー感覚のズレがあります。
ユーザー側で起動先を変更できる？
サイト側のPWA設定によって起動先が決められている場合、基本的にユーザー側からそのstart_urlを書き換えることはできません。
同じプロフィールページからもう一度ホーム画面に追加しても、サイト側が同じPWAとして扱う設計になっていれば、期待したページを起動できるとは限りません。
そのため、「特定のページをあとで開きたい」というのが目的なら、無理にホーム画面へ追加する必要はありません。
そのページ自体を残したいならブックマークを使う
Safariのブックマークなら、基本的には保存したURLそのものを後から開けます。
例えばXの特定プロフィールを残したいのであれば、そのプロフィールURLをブックマークに保存しておけば、「アプリの起動先」に置き換えられることなく、そのURLへアクセスできます。
ホーム画面に置きたいのか、特定URLを保存したいのか。
目的によって使い分けるのが一番わかりやすいです。
なぜ違うページが開くの？原因の一つがstart_url
ここからはWebサイトを作る側の話です。
PWAでは、Web App Manifestのstart_urlを使って、ホーム画面からアプリを起動したときの入口を指定できます。
例えば次のようなManifestです。
{
"name": "Example App",
"start_url": "/",
"display": "standalone"
}この場合、start_urlは/です。
そのため、ユーザーがサイト内の別ページを見ているときにホーム画面へ追加しても、PWAとして起動したときにはルートURLが入口になることがあります。
ユーザーが見ていたページと、PWAとして設定された起動ページが一致しているとは限らないわけです。
PWA設定がなければ、見ているページをホーム画面に残せることもある
ここがiPhoneでは特に面白いところです。
通常のWebページをSafariからホーム画面へ追加した場合、PWA側で別の起動先が指定されていなければ、追加したページのURLがそのままホーム画面から開く入口になります。
例えば、
https://example.com/profile/user-aを見ながらホーム画面に追加すれば、そのURLを入口として使えるケースです。
ところがサイトがPWAとして構成され、Manifestで、
"start_url": "/"と指定されていると、ホーム画面から起動したときの入口はサイト側のPWA設計に影響されます。
つまり、PWA化することでアプリらしい起動方法を作れる一方、「今見ているページをそのままホーム画面に残す」というWebらしい使い方と衝突することもあるわけです。
start_url:"/"は間違いなのか？
これは間違いではありません。
サイト全体を1つのアプリとして扱うのであれば、
"start_url": "/"という設計は非常にわかりやすいです。
Xのように「サービス全体で1つのApp」と考えるなら、特定プロフィールではなく、サービスとして決めた入口から起動する方が自然な場合もあります。
問題は/が正しいか間違っているかではありません。
そのWebサイトを「1つのApp」として使ってほしいのか、それともユーザーが見ている各ページをそれぞれ入口として残せるようにしたいのか。
設計したい体験によって答えが変わります。
追加したページをそのまま起動させたい場合は？
自分のサイトで「ユーザーが追加したページを、そのままホーム画面から開いてほしい」と考えるなら、Manifestの作り方を変える必要があります。
そのときに使える方法の一つが、相対URLを利用したstart_urlです。
{
"start_url": ".",
"display": "standalone"
}start_url:"."は、ManifestのURLを基準に相対的に解決されます。
そのため、ページごとに適切なManifestを生成する仕組みと組み合わせれば、ユーザーが追加したページをそのままAppの入口にする設計が可能になります。
ただし、単純にすべてのサイトで"/"を"."へ変更すれば解決する、という話ではありません。
ManifestをどのURLから配信するか、アプリをどの単位で扱うかまで含めて設計する必要があります。
この違和感から1P1Aを考えるようになった
自分がPWA LABで実機検証を続ける中で気になったのも、まさにこの部分でした。
PWAでは「サイト全体を1つのAppとして扱う」という設計がよく使われます。
でもWebを使っている人は、必ずしもサイト全体を保存したいわけではありません。
記事を残したい人もいる。
商品ページを残したい人もいる。
プロフィールを残したい人もいる。
Webツールの特定ページをホーム画面から直接起動したい人もいます。
それなら、ユーザーが「ホーム画面に追加」を押したそのページを、そのままAppの入口として扱えないか。
そこから検証してきたのが、1P1A（One Page. One App.）という考え方です。
サイト全体を1つのAppとして扱う1S1A（One Site. One App.）に対して、1P1Aではページ単位でホーム画面の入口を考えます。
どちらが正しいという話ではありません。
サイト全体を使うサービスなら1つのAppが自然ですし、ページそのものに価値があるWebサイトなら、ページ単位の入口が自然な場合もあります。
制作者側は「ユーザーが何を追加したと思うか」を考えてみる
PWAを作るときは、Manifestが正しく書けているか、インストールできるか、standaloneで起動するか、といった技術的な確認に目が向きがちです。
でもホーム画面UXとして考えるなら、もう一つ確認しておきたいことがあります。
ユーザーは何をホーム画面に追加したと思っているのか。
サービスそのものを追加したと思っているなら、共通のstart_urlで問題ないでしょう。
一方、今見ている記事やプロフィール、商品、ツールを追加したと思っているなら、別のページへ飛ばされることに違和感を持つかもしれません。
start_urlは単なるManifestの設定項目ではなく、ホーム画面からどこへユーザーを戻すのかを決めるUXの設定でもあります。
まとめ
ホーム画面に追加したページとは違うページが開く場合、サイト側のPWA設定、特にWeb App Manifestのstart_urlが関係していることがあります。
サイト側で起動先が指定されている場合、ユーザーが自由に変更することは基本的にできません。
特定のページを保存しておくことが目的なら、Safariのブックマークを使う方が確実です。
一方、Webサイトを作る側は、サイト全体を1つのAppとして起動させたいのか、それともユーザーが追加したページをそのまま入口にしたいのかを考える必要があります。
「ホーム画面に追加したページ」と「ホーム画面から起動するページ」は、必ずしも同じではありません。
この違いを知っておくだけでも、PWAのstart_urlをどう設計するかはかなり考えやすくなると思います。
