iOS

iOSWeb開発者が直面する特有の不具合と仕様差異に関するまとめ(2025年版)

  1. 既知の不具合と対応策クイックリスト
  2. はじめに WebKitのエコシステムと「Safari 26」時代の到来
  3. 第1章 ビューポートとレイアウトエンジンの攻防
    1. 1.1 「100vh」の定義と動的ビューポート単位の活用
      1. 問題のメカニズム
      2. 解決策：dvh, svh, lvhの使い分け
    2. 1.2 ノッチとSafe Area Inset
      1. 解決策：環境変数 env() の適用
    3. 1.3 position: fixed と sticky のズレ問題
  4. 第2章 インタラクションとタッチイベントの物理学
    1. 2.1 300msのタップ遅延とその終焉
    2. 2.2 Sticky Hover（粘るホバー）問題
      1. 解決策：Interaction Media Features
    3. 2.3 ラバーバンドスクロール（Elastic Scrolling）の制御
      1. 解決策：overscroll-behavior-y
    4. 2.4 スクロールロックの完全実装
      1. 最強の解決策：position: fixed 戦略
  5. 第3章 フォームコントロールと入力レンダリングの深淵
    1. 3.1 16pxルールの攻防：アクセシビリティとUX
      1. 推奨対策：フォントサイズ 16px の遵守
      2. 代替案：スケーリングによる見た目の調整
    2. 3.2 頑固なデフォルトスタイルとインナーシャドウ
      1. 解決策：スタイルの完全リセット
    3. 3.3 電話番号自動リンクの制御
      1. 解決策：メタタグによる検出無効化
  6. 第4章 メディアと自動再生ポリシーの制約
    1. 4.1 動画の自動再生条件
  7. 第5章 JavaScriptエンジン (JSC) の特異点
    1. 5.1 Dateオブジェクトの厳格性
      1. 解決策：スラッシュ区切りへの置換
    2. 5.2 正規表現「後読み」のサポート状況
      1. リスク管理
  8. 第6章 最新CSS機能とSafari 18-26の進化
    1. 6.1 Flexbox gap プロパティの完全普及と歴史的負債
    2. 6.2 縦書きと新しいCSSプロパティ
  9. 第7章 Safari Web Extensionsの深刻な不具合 (2025)
    1. 7.1 window.open とナビゲーションの崩壊
    2. 7.2 無限リロードループ
  10. 第8章 デバッグとテスト戦略
  11. 結論

既知の不具合と対応策クイックリスト

本レポートは、2025年現在におけるiOS Safari（Webkitエンジン）特有の挙動、バグ、および仕様の差異を網羅的に分析し、その技術的背景と解決策を体系化したものである。特に、近年Appleが導入した新しいバージョニング規則（Safari 26など）に伴う変化や、Safari 18.x系で発生している深刻な拡張機能バグについても詳述する。

以下は、開発現場で頻発する主要な問題を「現象」と「対策」の対比で整理したクイックリファレンスである。詳細な技術解説とコード実装については、後続の各章を参照されたい。

カテゴリ不具合・現象推奨される対策・解決策関連セクション
レイアウト100vhの表示崩れ
アドレスバーの伸縮により、100vhで設定した要素の下部が隠れる、または再計算でガタつく。		CSSの動的ビューポート単位（dvh, svh, lvh）を使用する。レガシー対応が必要な場合はJavaScriptでwindow.innerHeightを取得しCSS変数にセットする。第1章
レイアウトノッチ・ホームバーの干渉
iPhone X以降の端末で、コンテンツが物理的な切り欠きやホームインジケータに重なる。		CSS環境変数 env(safe-area-inset-*) を利用し、パディングやマージンで安全領域を確保する。第1章
スクロールラバーバンド現象
ページ端でのスクロール時に背景がゴムのように伸びる（オーバースクロール）。		overscroll-behavior-y: none を body またはスクロールコンテナに適用する。第2章
スクロールスクロールロックの不発
モーダル表示時に body { overflow: hidden } を指定しても背景がスクロールしてしまう。		position: fixed と top プロパティを組み合わせたJS制御、または touch-action: none の利用（状況による使い分け）。第2章
フォーム入力時の強制ズーム
フォントサイズが16px未満の入力欄にフォーカスすると画面が拡大される。		font-size: 16px 以上を設定する。デザイン上の制約がある場合は transform: scale() で視覚的に縮小する。第3章
フォームインナーシャドウと角丸
入力要素やボタンにApple独自のグラデーション、影、角丸が強制適用される。		appearance: none でOS標準スタイルを解除し、background-image: none、border-radius: 0 を明示する。第3章
システム電話番号の自動リンク
数字の羅列（IDや注文番号）が勝手にリンク化され、配色が変わる。		<meta name="format-detection" content="telephone=no"> を実装し、必要な箇所のみ <a> タグで記述する。第3章
JSDateオブジェクトのパースエラー
YYYY-MM-DD 形式の文字列を new Date() に渡すと Invalid Date になる。		ハイフンをスラッシュに置換する（replace(/-/g, "/")）か、ISO 8601形式（T区切り）を厳密に使用する。第5章
JS拡張機能APIの不具合
Safari 18系で window.open や location.href が機能しない、<title> タグによる無限リロード。		現状はOS側のバグ修正待ちの状態だが、回避策としてAPIコールのタイミング調整や代替APIの検討が必要。第7章
UI/UXSticky Hover（粘るホバー）
タップ後も :hover スタイルが解除されず、次のタップまで維持される。		メディアクエリ @media (hover: hover) を使用し、タッチデバイスを除外してホバーを適用する。第2章
メディア動画の自動再生不可
autoplay を指定しても動画が再生されない。		muted（消音）と playsinline（インライン再生）属性を必ず付与する。第4章

はじめに WebKitのエコシステムと「Safari 26」時代の到来

Web開発の世界において、iOS Safariは特異な位置を占めている。Google ChromeやMicrosoft Edge、Operaなどの主要ブラウザがChromium（Blinkエンジン）を採用して均質化が進む中、AppleのSafariは独自のレンダリングエンジン「WebKit」を採用し続けているからである。さらに、AppleはiOS上のすべてのブラウザ（ChromeやFirefoxを含む）に対してWebKitの利用を強制しているため、iOS向けWeb開発においては実質的に「Safari対応」こそが全てとなる。

2024年から2025年にかけて、Safariを取り巻く環境は劇的に変化している。特筆すべきはバージョニング規則の変更である。これまでの連番（Safari 17, 18...）から、リリース年を基準とした新しいスキームへの移行が進んでおり、2025年モデルは「Safari 26」として言及されるようになっている 。この飛躍的なバージョン番号の変更は、内部的なアーキテクチャの刷新や機能追加の加速を象徴しており、開発者は「Safari 18系」と「Safari 26系」の双方の挙動を理解する必要に迫られている。

本レポートでは、HTML/CSSのレンダリング差異から、JavaScriptエンジン（JavaScriptCore）の挙動、そして最新のWeb Extensions APIにおける深刻なバグに至るまで、開発者が直面する課題を深掘りし、その対処法を論理的かつ実践的に解説する。

第1章 ビューポートとレイアウトエンジンの攻防

iOS Safariにおけるレイアウト崩れの大部分は、ブラウザ独自のUIコンポーネント（アドレスバー、ツールバー）の動的な挙動と、ハードウェア固有の形状（ノッチ、ホームバー）に起因する。

1.1 「100vh」の定義と動的ビューポート単位の活用

長年、Web開発者を悩ませてきた最大の問題の一つが、100vh（Viewport Height）の挙動である。CSS仕様上、100vhはビューポートの高さの100%を意味するが、iOS Safariでは「アドレスバーが最小化された状態（画面が最も広く使える状態）」を基準に計算される仕様が採用されてきた 。

問題のメカニズム

ユーザーがページを読み込んだ直後、画面下部にはアドレスバーやツールバーが表示されている。しかし、100vhはこのバーが存在しないものとして計算されるため、画面下部に配置した重要なボタンやコンテンツがバーの裏側に隠れてしまう。スクロールしてバーが引っ込むとようやく表示されるが、これではファーストビュー（FV）のデザインとして成立しない。

解決策：dvh, svh, lvhの使い分け

2022年以降、CSS Values and Units Module Level 4で定義された新しいビューポート単位がSafariでもサポートされるようになり、この問題は根本的な解決が可能となった 。

  • svh (Small Viewport Height): アドレスバーが表示されている状態（最も狭いビューポート）の高さ。FVで確実に全要素を表示させたい場合に最適である。
  • lvh (Large Viewport Height): アドレスバーが格納された状態（最も広いビューポート）の高さ。従来の100vhに近い挙動。
  • dvh (Dynamic Viewport Height): ユーザーのスクロールに合わせて、svhとlvhの間を動的に遷移する。

実装コード例：

CSS

.hero-section {
  /* フォールバック：古いブラウザ用 */
  height: 100vh;
  
  /* モダンブラウザ用：動的に変化する高さに対応 */
  height: 100dvh;
}

/* ガタつき（レイアウトシフト）を嫌う場合の安定策 */
.stable-full-screen {
  height: 100svh;
}

iOS 26を含む最新環境においても、これらの単位は正常に動作するが、dvhを使用した場合、スクロール中にブラウザUIの伸縮に合わせてコンテンツの高さが再計算・再描画されるため、パフォーマンスコストがかかる点には留意が必要である。背景画像のリサイズ処理などが重なると、スクロールのカクつき（ジャンク）の原因となる可能性がある。その場合は svh で固定するのが安全な選択肢となる。

1.2 ノッチとSafe Area Inset

iPhone X以降導入されたノッチ（画面上部のセンサー領域）とホームインジケータ（画面下部の操作バー）は、矩形であることを前提としたWebデザインに「安全領域（Safe Area）」という概念を持ち込んだ。これらを無視して全画面レイアウトを行うと、コンテンツが物理的に欠損したり、操作不能になったりする 。

解決策：環境変数 env() の適用

CSSの env() 関数を使用することで、デバイス固有のセーフエリア量を取得できる。これらは padding や margin に適用することで、コンテンツを安全な領域内に押し留めることができる。

CSS

:root {
  --safe-top: env(safe-area-inset-top, 0px);
  --safe-bottom: env(safe-area-inset-bottom, 0px);
  --safe-left: env(safe-area-inset-left, 0px);
  --safe-right: env(safe-area-inset-right, 0px);
}

body {
  /* 全体的にセーフエリアを確保 */
  padding-top: var(--safe-top);
  padding-bottom: var(--safe-bottom);
  padding-left: var(--safe-left);
  padding-right: var(--safe-right);
}

/* 固定フッターの場合の応用 */
.fixed-bottom-bar {
  position: fixed;
  bottom: 0;
  width: 100%;
  
  /* デフォルトの余白20pxに加え、ホームバーの高さ分を追加確保 */
  /* max()関数を使うことで、セーフエリアが0の場合でも最低限の余白を維持できる */
  padding-bottom: max(20px, env(safe-area-inset-bottom));
}

注意点として、env() はかつて constant() という名称であった（iOS 11.0-11.2）。現在のWeb開発では env() のみで十分カバー可能だが、極めて古い端末をサポート対象とする場合はフォールバック記述が必要となる場合がある 。

1.3 position: fixed と sticky のズレ問題

iOS Safariにおいて、position: fixed や position: sticky で配置された要素は、スクロール操作やソフトウェアキーボードの出現に伴って表示位置が予期せずズレる、あるいはちらつくという不具合が長年報告されている 。

特にiOS 26のベータ版など新しいバージョン環境下でも、特定のCSSプロパティ（overflow, overscroll-behavior）の組み合わせによって、固定配置されたフッターが垂直方向にシフトしてしまう現象が確認されている。これに対する有効なハックとして、html { overflow: hidden; } と body { overflow: auto; } を組み合わせる手法があるが、これは副作用としてスクロール位置の取得を困難にする場合があるため、採用には慎重な検証が必要である。

第2章 インタラクションとタッチイベントの物理学

iOS Safariは「触れるインターフェース」として設計されているため、マウス操作を前提としたWeb標準とは異なる独自のタッチ物理挙動を持っている。

2.1 300msのタップ遅延とその終焉

かつてのモバイルWebにおける最大のストレス要因は、リンクやボタンをタップしてから反応するまでの「300msの遅延」であった。これは、ブラウザが「ユーザーはダブルタップをしてズームしようとしているのか？」を判定するために待機時間を設けていたことに起因する 。

現在、この問題は大部分が解消されている。viewportの設定において width=device-width を指定することで、ブラウザは「このサイトはモバイル最適化されている（ズームの必要がない）」と判断し、遅延を削除する。

HTML

<meta name="viewport" content="width=device-width, initial-scale=1">

ただし、完全にズーム不可能なサイトを作ろうとして user-scalable=no を指定することは、アクセシビリティの観点（視覚障害者が文字を拡大できない）から推奨されない。現代のiOS Safariは、標準的なviewport設定さえあれば、タップの即時反応とアクセシビリティの両立が可能である。

2.2 Sticky Hover（粘るホバー）問題

PC向けのWebサイトでは、マウスオーバー時（:hover）にボタンの色を変えるなどのフィードバックが一般的である。しかし、iOS Safariでこのスタイルが適用されると、一度タップしたボタンが、指を離した後も「ホバー状態」として色が変わりっぱなしになる現象が発生する 。

これは、タッチデバイスには「カーソルを要素の外に移動させる」という操作が存在しないため、別の要素をタップするまでフォーカスが外れない仕様によるものである。

解決策：Interaction Media Features

CSSのメディアクエリを用いて、「ホバー操作が可能なデバイス（主にマウス）」にのみホバーエフェクトを適用するよう制限することで解決できる。

CSS

/* ベースのスタイル（タッチデバイスでも適用） */
.button {
  background-color: #007bff;
  transition: background-color 0.3s;
}

/* ホバー機能を持つ入力デバイス（マウス等）の場合のみ適用 */
@media (hover: hover) {
 .button:hover {
    background-color: #0056b3;
  }
}

これにより、iPhoneなどのタッチデバイスではタップ時の不自然な色の変化を防ぎ、PCでは従来通りのインタラクションを提供できる。

2.3 ラバーバンドスクロール（Elastic Scrolling）の制御

iOSの象徴的なUI挙動である「ラバーバンド（スクロールの端で画面がボヨヨンと伸びる）」は、Webアプリのような没入感を損なう場合がある。特に全画面のCanvasゲームやダッシュボードUIでは、画面全体が揺れることは好ましくない 。

解決策：overscroll-behavior-y

従来の対策（touchmove イベントを preventDefault するなど）は実装が複雑で副作用も多かったが、現在はCSSプロパティ overscroll-behavior がiOS Safariでもサポートされつつある（バージョンによる差異はあるが、標準化が進んでいる）。

CSS

html, body {
  /* 縦方向のオーバースクロール効果（バウンス）を無効化 */
  overscroll-behavior-y: none;
}

これにより、ネイティブアプリのような「端でピタッと止まる」スクロール感を実現できる。ただし、これを適用すると「プル・トゥ・リフレッシュ（引っ張って更新）」のようなブラウザ標準機能も無効化される場合があるため、用途に応じた使い分けが必要である。

2.4 スクロールロックの完全実装

モーダルウィンドウを開いた際、背景（body）のスクロールを固定する実装は、iOS Safariにおいて最も難易度が高い実装の一つである。単に body { overflow: hidden; } を適用しただけでは、Safariはそれを無視して背景スクロールを許容してしまうことが多い 。

最強の解決策：position: fixed 戦略

現在、最も信頼性が高いのは「JavaScriptでスクロール位置を保持しつつ、bodyを強制的に固定配置にする」手法である。

JavaScript

// スクロール位置を保存する変数
let scrollPosition = 0;

const lockScroll = () => {
  // 現在のスクロール位置を取得
  scrollPosition = window.scrollY;
  
  const body = document.body;
  // bodyを固定し、現在のスクロール位置分だけ上にずらす
  body.style.position = 'fixed';
  body.style.top = `-${scrollPosition}px`;
  body.style.width = '100%';
  body.style.overflow = 'hidden'; // 安全策
};

const unlockScroll = () => {
  const body = document.body;
  
  // スタイルを解除
  body.style.removeProperty('position');
  body.style.removeProperty('top');
  body.style.removeProperty('width');
  body.style.removeProperty('overflow');
  
  // スクロール位置を復元
  window.scrollTo(0, scrollPosition);
};

この実装により、ユーザーがモーダルを開いた瞬間の画面位置を完全に維持したまま、背景のスクロールを物理的にロックすることができる。body-scroll-lock などのライブラリも内部的には同様のロジック（あるいは touch-action の制御）を行っていることが多い。

第3章 フォームコントロールと入力レンダリングの深淵

フォーム要素（Input, Textarea, Select）は、ブラウザとOSのネイティブUIが最も密接に関わる領域であり、iOS Safariの「お節介」機能が最も発揮される場所でもある。

3.1 16pxルールの攻防：アクセシビリティとUX

iOS Safariには「フォントサイズが16px未満の入力フィールドにフォーカスすると、自動的に画面をズームインする」という仕様がある 。これは小さな文字を読みやすくするためのアクセシビリティ機能だが、入力終了後にズームアウトしないため、画面レイアウトが崩れたままになることが多く、開発者からはバグ扱いされることが多い。

推奨対策：フォントサイズ 16px の遵守

最も安全かつ推奨される解決策は、入力フィールドのフォントサイズを16px以上に設定することである。

CSS

input[type="text"],
input[type="email"],
input[type="password"],
textarea,
select {
  font-size: 16px; /* これでズームは発動しない */
}

代替案：スケーリングによる見た目の調整

デザインガイドライン上、どうしても16pxより小さな文字で表示したい場合は、CSSの transform を利用して「実体は16pxだが、見た目は小さい」状態を作り出すテクニックがある。

CSS

.input-small {
  font-size: 16px;       /* ズーム回避のため16pxを確保 */
  transform: scale(0.8); /* 80%に縮小表示（実質12.8px） */
  transform-origin: left top; /* 縮小の基準点を左上に */
  width: 125%;           /* 縮小される分、幅を補正（100 / 0.8 = 125） */
}

なお、meta タグで user-scalable=no を設定してズーム自体を禁止する方法は、ユーザーの自由な拡大操作を奪うため、WCAG（Web Content Accessibility Guidelines）の基準に抵触する恐れがあり、現代のWeb開発では避けるべきである 。

3.2 頑固なデフォルトスタイルとインナーシャドウ

iOS Safariのフォーム要素には、Apple特有の「リッチな」スタイルが適用される。特に input 要素の上部内側には、薄い影（インナーシャドウ）が描画され、フラットデザインを目指す開発者を悩ませる 。

解決策：スタイルの完全リセット

以下のCSSスニペットを使用することで、OS固有の装飾を剥ぎ取り、CSSで完全に制御可能な状態にすることができる。

CSS

input, textarea, select {
  /* WebKit固有のUI装飾を無効化 */
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
  
  /* デフォルトの角丸を解除 */
  border-radius: 0;
  
  /* 謎のインナーシャドウを削除 */
  background-image: none;
  background-color: transparent;
  box-shadow: none;
}

特に background-image: none あるいは clip-path: inset(0) は、しつこいインナーシャドウを除去するために効果的である場合がある。

3.3 電話番号自動リンクの制御

Safariのヒューリスティック機能は、テキスト中の「数字の羅列」を電話番号と誤認し、勝手にリンク（<a>タグ）に変換してしまうことがある。例えば、注文番号「2025-0123」が電話リンクになり、青色に変色してしまう 。

解決策：メタタグによる検出無効化

HTMLヘッダーに以下のメタタグを追加することで、この自動変換機能をページ全体で停止できる。

HTML

<meta name="format-detection" content="telephone=no">

これにより意図しないリンク化を防ぎつつ、本当に電話リンクが必要な箇所には明示的に tel: スキームを使用することで、UXを損なわずに実装できる。

HTML

<a href="tel:03-1234-5678">お問い合わせ: 03-1234-5678</a>

第4章 メディアと自動再生ポリシーの制約

モバイルデータ通信の保護とバッテリー節約の観点から、iOS Safariは動画や音声の自動再生（Autoplay）に対して極めて厳しい制限を設けている。

4.1 動画の自動再生条件

Webサイトの背景動画などで <video autoplay> を使用したい場合、単に属性を記述しただけでは再生されない。iOS Safariでインライン（全画面にならずにページ内）で自動再生させるには、以下の条件を全て満たす必要がある 。

  1. muted: 音声が出ない設定であること（必須）。
  2. playsinline: 全画面再生を強制しない属性が付与されていること。
  3. autoplay: 自動再生属性。

推奨コード：

HTML

<video 
  src="background.mp4" 
  autoplay 
  muted 
  playsinline 
  loop 
  poster="fallback-image.jpg">
  お使いの環境では動画を再生できません。
</video>

重要な注意点：

  • iPhoneが「低電力モード」に設定されている場合、上記の条件を満たしていても自動再生は強制的に無効化される。そのため、poster 属性で代替画像を設定しておくことは必須のマナーである。
  • JavaScriptから video.play() を呼び出す場合も、事前にユーザーインタラクション（タップなど）がない限り、音声付きの再生はPromiseのリジェクト（エラー）となる。

第5章 JavaScriptエンジン (JSC) の特異点

SafariのJavaScriptエンジンであるJavaScriptCore (JSC) は、ChromeのV8エンジンとは異なる実装を持っており、標準仕様への準拠度や解釈に微妙な差異が存在する。

5.1 Dateオブジェクトの厳格性

JavaScriptの Date オブジェクトは、ブラウザによってパース能力に差がある。特に YYYY-MM-DD 形式（ハイフン区切り）の文字列を new Date() に渡した場合、Chromeでは正常に解釈されるが、Safariでは Invalid Date（無効な日付）となるケースが頻発する 。

これは、SafariがISO 8601形式の解釈において厳格であり、日付と時間の区切り文字やタイムゾーン情報の不足に対して寛容でないためである。

解決策：スラッシュ区切りへの置換

最も堅実な回避策は、ハイフンをスラッシュに置換することである。JSCは YYYY/MM/DD 形式に対しては安定して動作する。

JavaScript

const rawDate = "2025-02-01 12:00:00"; // APIから返ってきた文字列など

// Safariでパースエラーになる可能性があるため、ハイフンをスラッシュに変換
const safeDate = new Date(rawDate.replace(/-/g, "/"));

console.log(safeDate); // Safariでも正常なDateオブジェクトが生成される

あるいは、date-fns や dayjs といったライブラリを使用し、パース処理の差異をライブラリ側で吸収させることも有効である。

5.2 正規表現「後読み」のサポート状況

正規表現における「後読み（Lookbehind）」（例: (?<=text)）は、長らくSafariでは非サポートであった。iOS 16.4（2023年リリース）以降でようやくサポートされたが、それ以前のバージョンを使用しているユーザーに対しては、スクリプト全体が構文エラー（Syntax Error）となり、画面が真っ白になる（White Screen of Death）原因となる 。

リスク管理

2025年現在、iOS 16.4未満のシェアは低下しているものの、完全にゼロではない。エンタープライズ向けのシステムなど、古い端末のサポートが必要な場合は、正規表現の後読みを使用せず、キャプチャグループなどを利用した代替ロジックを組む必要がある。Babel等のトランスパイラでも、正規表現の構文エラーはポリフィルできない場合が多いため注意が必要である。

第6章 最新CSS機能とSafari 18-26の進化

2024年から2025年にかけてリリースされたSafari 18.xおよび次期バージョン（Safari 26系）では、CSSの表現力が大幅に向上しているが、同時に新たなバグも混入している。

6.1 Flexbox gap プロパティの完全普及と歴史的負債

flex-gap（Flexboxアイテム間の余白）は、かつてSafariでのサポートが遅れていた機能の代表格であった 。現在はサポートされているが、古いiOS（iOS 14.0以下）をサポートする必要がある場合、gap プロパティは無視され、レイアウトが崩れる。

レガシー対応が必要な場合は、ネガティブマージンを用いた古典的な手法（Lobotomized Owl Selectorなど）をフォールバックとして用意する必要がある。

6.2 縦書きと新しいCSSプロパティ

Safari 18.4以降では、writing-mode: sideways-rl などの縦書き関連プロパティや、::details-content 擬似要素など、高度なタイポグラフィ機能が強化されている 。しかし、これらの新機能は他のブラウザでの実装状況と足並みが揃っていない場合があり、プログレッシブエンハンスメント（対応ブラウザでのみリッチにする）の考え方で実装することが望ましい。

第7章 Safari Web Extensionsの深刻な不具合 (2025)

2025年のWeb開発において見過ごせないのが、Safariの拡張機能（Web Extensions）環境における不安定さである。特にSafari 18.x系のアップデート以降、開発者から多数のバグ報告が上がっている 。

7.1 window.open とナビゲーションの崩壊

拡張機能のポップアップやスタートページから window.open() を呼び出しても反応しない、あるいは about:blank が開いてしまうという不具合が報告されている。また、window.location.href を書き換えてのリダイレクトも不安定であり、決済ページへの遷移などが阻害されるケースがある。

これらはブラウザ自体のバグである可能性が高く、OSのアップデートを待つしかない状況だが、開発者としては「ユーザーアクション（クリックイベント）の直後に同期的にAPIを呼び出す」など、ブラウザのセキュリティ制限に引っかからない実装を徹底することで、発生頻度を下げられる可能性がある。

7.2 無限リロードループ

拡張機能のカスタムスタートページにおいて、<title> タグを含めると無限リロードが発生し、ブラウザがクラッシュするという致命的なバグも確認されている 。これに対する暫定的な回避策は、<title> タグを動的にJavaScriptで挿入するか、問題が修正されるまでタイトル設定を控えることである。

第8章 デバッグとテスト戦略

Macを持たない開発者にとって、iOS Safariのデバッグは困難を極める。しかし、以下の手法を用いることで、実機に近い検証が可能となる。

  1. Xcode Simulator: Macユーザーであれば、Xcodeに含まれるiOS Simulatorを使用するのが最も確実である。実機とほぼ同じレンダリングエンジンで検証でき、Web Inspector（開発者ツール）もフル機能が使える。
  2. リモートデバッグ: iPhone実機をMacにUSB接続し、MacのSafariの「開発」メニューからiPhoneを選択することで、PC上で実機のDOMやコンソールを確認できる。
  3. クロスブラウザテストツール: BrowserStackやLambdaTestなどのクラウドサービスを利用すれば、Windows環境からでも実機のSafariの挙動を確認できる。
  4. プロキシデバッグ: Macがない場合、Charles ProxyやFiddlerなどのプロキシツールを介して通信をキャプチャし、リクエスト/レスポンスの内容を検証することで、特定の問題を切り分けられる場合がある。

結論

iOS Safariは、その独自の哲学と実装により、Web開発者に多くの課題を突きつける。しかし、100vh に対する dvh の採用、overscroll-behavior によるスクロール制御、そして厳格な入力フォーム対策など、適切な知識とコードを用意すれば、ネイティブアプリに匹敵する高品質なWeb体験を提供することは十分可能である。

2025年、Safariの進化は加速している。バージョニングの刷新や新機能の追加は歓迎すべきことだが、同時に新たなバグも生まれている。開発者は常に最新の情報をキャッチアップし、検証を繰り返す姿勢が求められる。

タイトルとURLをコピーしました