iPhoneで動かない！— Safariとの3日間の闘い

スワイプUIのプロトタイプが完成して、意気揚々とiPhoneで開いた。カードをスワイプした。…動かない。

正確には、スワイプはできるけどアニメーションの後に画面がフリーズする。次のカードが出てこない。PCのChromeでは完璧に動いていたのに。

せっかくナイターの惨敗を乗り越えて新しいUIを作ったのに、今度はiPhoneで動かないのか…。

1日目 — 何が悪いのか全くわからない

iPhoneのSafariにはChromeのような開発者ツールがない。コンソールログも見えない。何が起きているのか、文字通り「見えない」状態。

手当たり次第にコードを修正しては、iPhoneで確認する。直らない。また修正する。また確認する。この繰り返しで1日が終わった。

夜、布団の中でスマホの画面をにらみながら「Webアプリなんてやめてネイティブアプリにすべきか」と真剣に考えた。

2日目 — 犯人はアニメーション完了の検知

2日目、ようやくMacのSafariからiPhoneをリモートデバッグする方法を見つけた。コンソールを見ると、あるイベントが発火していないことが判明。

カードが画面外に飛んでいくアニメーション。その「完了」をブラウザが教えてくれるはずのイベントを、iPhoneのSafariがときどきスキップしてしまう。要素が画面の外に出ると、ブラウザが「もう見えないから最適化しよう」と判断するらしい。

3日目 — 力技だけど確実な方法

解決策は力技だった。アニメーション完了イベントに頼るのをやめて、アニメーションの時間（0.3秒）が経ったら問答無用で次の処理を実行する。タイマーで時間を測るだけのシンプルな方法。

エレガントではない。でも確実に動く。iPhoneでもAndroidでもPCでも。

もうひとつの罠 — スクロールとの競合

アニメーション問題を直したら、今度は横にスワイプしようとするとページ全体が縦にスクロールしてしまう問題が発生。これもSafari固有の挙動だった。

最終的に「ユーザーの指が横方向に動いたら横スワイプ、縦方向なら通常スクロール」と判別するロジックを入れて解決した。

「まずiPhoneで試す」が鉄則になった

この3日間で学んだのは、「PCのブラウザで動くこと」と「スマホのブラウザで動くこと」はまったく別物だということ。

ナイターラウンドで「実際に使う環境で試せ」と学んだはずなのに、開発環境ではまたPCで確認していた。同じ過ちを繰り返していた。

3日間の苦しみは、結果的にいい経験になった。「まずiPhoneで試す」が今の開発の鉄則になっている。