弱点と向いているサービス

はじめに

1回目では「ホーム画面に追加」したサイトが独立したアプリとして起動する仕組みと、iOSとAndroidでの条件の違いを、2回目ではプッシュ通知とアイコンバッジの実装を見てきました。

最終回の今回は、インストールされたWebアプリをユーザーが違和感なく操作できるように、サイト側で用意しておきたいことを紹介したうえで、「ホーム画面に追加」の弱点を整理し、どんなサービスに向いているのかを考えます。

インストールされたWebアプリで用意しておきたいこと

ホーム画面に追加すると、ブラウザのアドレスバーやツールバーが表示されなくなります。

見た目としてはネイティブアプリと変わらなくなる分、ユーザーもネイティブアプリと同じ操作方法・操作感を期待します。

アドレスバーにあった機能の多くは、アプリとして使う以上ユーザーも期待しません。戻る操作はスワイプで行えます（iOSは進む操作も可能）。ブックマークやタブ、URLの確認も、アプリでは不要です。

一方で、ネイティブアプリの操作感に近づけるために、筆者は「リロード」「シームレスな画面遷移」の2つについてはサイト側で用意したほうがよいと考えています。

リロード

ブラウザのUIが消えてまず困るのがリロードです。

表示が古いまま、あるいは通信エラーで止まったままのときは、読み込み直す必要があります。そうでなくても現在の状態が最新かわからず、任意のタイミングで更新したくなることもあります。

これに対して筆者は、「アプリを開き直せば最新になることを保証する」「ユーザーが任意でリロードできる方法を用意する」の2つで対策するのがよいと考えています。

アプリを開き直せば最新になることを保証する

インストールされたWebアプリは、ブラウザのタブと違い、アプリスイッチャーに残ったまま何日も開きっぱなしになります。

そのため、久しぶりに開いたときに、何日も前のデータが表示されたままということが起こります。

アプリが前面に戻ったタイミングで、データを取り直すような実装がおすすめです。

方法はいくつかありますが、たとえば、2回目でアイコンバッジを消すのにも使ったvisibilitychangeイベントを使う方法があります。ページが表示されたときと隠れたときに発生するので、document.visibilityStateを確かめて、表示されたときだけ取り直します。

そのほか、アプリ側からデータを取りに行くような構成ではなく、変更があればサーバーから送ってもらう作りにするというのもひとつの手です。

変更をサーバーから送ってもらうには、WebSocketなどでサーバーとの接続を保っておく方法があります。たとえばConvexはこの仕組みを組み込んでいて、取り直しを意識しなくても最新の状態を保てます。

よければ筆者が書いたシリーズをご覧ください。

• Convexを使ってみる | Convex入門

ユーザーが任意でリロードできる方法を用意する

自動で最新にする仕組みがあっても、ユーザーが自分の意思でリロードしたい場面もあります。

表示がおかしい、通信が途中で止まった、読み込みが終わらない。ブラウザならアドレスバーの更新ボタンを押せば済んでいた場面ですが、インストールされたWebアプリにはそのボタンがありません。

Android版Chromeでは、それでもブラウザ本体の「引っ張って更新（pull to refresh）」がそのまま動作します。

一方、iOSにはこの動作もありません。

画面上に更新ボタンを用意したり、ネイティブアプリでよく見られる「引っ張って更新」を実装したりするのがおすすめです。

なお、自前で「引っ張って更新」を実装した場合は、Android版Chromeのブラウザ本体の「引っ張って更新」と二重に動かないよう、CSSで止めておきます。

body {
  overscroll-behavior-y: contain;
}

overscroll-behavior-yは、ページの端を越えてスクロールしようとしたときの動作を指定するプロパティです。

containを指定すると、その動きがブラウザ側に伝わらなくなり、ブラウザ本体の「引っ張って更新」が働かなくなります。

シームレスな画面遷移

ネイティブアプリとの操作感の違いがいちばん大きく現れるのは、画面遷移のアニメーションでしょう。

Webアプリは遷移アニメーションに弱く、ネイティブアプリ並みのシームレスな体験はいまだに難しい部分がありますが、View Transition APIを使うと、前の画面と次の画面をつなぐアニメーションを比較的簡単に付けられます。

インストールされたWebアプリで特別に覚えておきたいのは、左右画面端からのスワイプでの履歴操作と、View Transition APIのアニメーションを競合させないことです。

先ほど見たとおり、インストールされたWebアプリでは、戻る操作はスワイプで行います。

このときブラウザは、指の動きに合わせて前の画面をスライドさせる、ブラウザ自身のアニメーションを済ませています。

その直後にサイト側でもView Transition APIのアニメーションを再生すると、「スライドで戻った画面が、もう一度クロスフェードで切り替わる」という二重のアニメーションになり、ユーザーを混乱させます。

これは、popstateイベントのhasUAVisualTransitionプロパティを用いることで避けられます。

ブラウザ（User Agent）がすでに遷移のアニメーションを行っていればtrueになるので、そのときはサイト側のアニメーションを省きます。

window.addEventListener('popstate', async (event) => {
  const nextContent = await fetchContent(location.href);

  // ブラウザがすでにアニメーションしている（スワイプで戻った）か、
  // View Transition APIが使えないときは、そのまま差し替える
  if (event.hasUAVisualTransition || !document.startViewTransition) {
    renderContent(nextContent);
    return;
  }

  document.startViewTransition(() => {
    renderContent(nextContent);
  });
});

Navigation APIを使っている場合は、navigateイベントにも同じhasUAVisualTransitionがあります。

hasUAVisualTransitionは、2026年に入って主要ブラウザがそろって対応した比較的新しいプロパティですが、iOSのSafariとAndroid版Chromeを含め、執筆時点の主要なブラウザではすでにサポートされています。対応状況の詳細は次のページを参照してください。

• PopStateEvent API: hasUAVisualTransition | Can I use
• PopStateEvent: hasUAVisualTransition property | MDN

「ホーム画面に追加」の弱点

ここまで、ホーム画面に追加したサイトがアプリとして起動すること、プッシュ通知やアイコンバッジが使えること、サイト側で用意しておきたいことを見てきました。

よいところばかりを紹介してきましたが、もちろん弱点もあります。

ネイティブアプリと比べたときに特に大きいのは、次の2つです。

• そもそも「追加」してもらうまでの道のりが遠い
• 端末の機能にアクセスするAPIが、まだそろっていない

順に見ていきます。

「追加」までの道のりが遠い

ネイティブアプリなら、ストアのページから簡単にインストールできます。一方、「ホーム画面に追加」は、ブラウザのメニューの奥にあります。

iOSのSafariでは、アドレスバーの左端にある、横線が3本並んだ「ページメニュー」ボタンから「共有」をタップします。次に表示される共有シートをスクロールして「ホーム画面に追加」を探し、さらに確認のシートで「追加」をタップする、という手順です。

基本的に共有ボタンは「人に送る」ための機能だと思われているので、そこに「追加」があることを知らないユーザーも少なくありません。

大きな画像

また、iOSではサイト側からこの操作を促す手段がありません。

Chromium系のブラウザにはbeforeinstallpromptというイベントがあり、これを使えば自前のボタンからインストールを始められます。

しかしSafariは対応しておらず、「ホーム画面に追加してください」と画面に書き、操作手順を図で示すことしかできません。

アクセスできないAPIも多い

もう1つの弱点は、端末の機能にアクセスするAPIの範囲です。

カメラ、位置情報、プッシュ通知のように、Webから使える機能は着実に増えてきました。

それでも、ネイティブアプリなら当たり前に使える機能のうち、Webからは触れないものがまだ多くあります。たとえば次のようなものです。

• アプリを閉じている間のバックグラウンド処理（バックグラウンドでの位置情報の取得など）
• ヘルスデータへのアクセス
• ホーム画面のウィジェット
• Siriやショートカットアプリのような、OS側の自動化機能との連携

ブラウザによって使えたり使えなかったりする機能もあります。

たとえば、Bluetooth機器やNFCタグとの通信、ほかのアプリの共有先として写真やファイルを受け取ることは、Chromium系のブラウザには実装があるものの、Safariにはありません。

Androidでは動くのにiOSでは動かない、ということが起こります。

しかも、Web標準として仕様が提案されていても、Appleが実装の意思を示していないものもあります。

「いずれ使えるようになる」と期待して待つのは難しい、と考えておいたほうがよいでしょう。

執筆時点で何が使えるかは、What PWA Can Do Todayで、今使っている端末のブラウザで実際に試せます。

検討中のサービスに必要な機能が、iOSとAndroidの両方で使えるかどうかを、ここで確認しておくと安心です。

どんなサービスなら使うべきか

最後に、ここまでの内容を踏まえて、「ホーム画面に追加」を前提にした設計が向いているのはどんなサービスかを考えてみます。

筆者が考える相性のよいサービスは価値の源泉がサーバー上のデータにあるサービスです。

弱点の節で見たように、端末のハードウェアやほかのアプリとの連携は、Webからはまだ届かない部分が多くあります。

裏を返せば、サービスの中身がサーバー上のデータの表示と更新で成り立っていて、端末側の機能を必要としないなら、連携が限られていることは弱点になりません。

ニュースやブログの閲覧、SNS、チャット、予約や申し込みのフォーム、社内の業務ツールなどがこれにあたります。

この種のサービスは、ネイティブアプリとして作っても、中身がWebViewで表示されるだけになることが珍しくありません。

それならば、最初からWebとして作り、ホーム画面に追加してもらうほうが、開発もリリースもずっと軽く済みます。

逆に、Bluetooth機器との通信やバックグラウンドでの処理が中心になるサービス、あるいは「追加」の手間をユーザーに越えてもらう動機づけが難しいサービスには、向いていないと考えます。

まとめ

このシリーズでは、「ホーム画面に追加」がただのブックマークではなくなったこと、追加したサイトで使える機能、そしてアプリらしく振る舞わせるための工夫と、残っている弱点を見てきました。

すべてのサービスに向く仕組みではありませんが、条件が合うサービスにとっては、ネイティブアプリを作らずにその体験の多くを提供できる、現実的な選択肢になっています。

次にスマートフォン向けのサービスを設計するとき、選択肢の1つとして検討してみてください。