背景
- iOS（iPhoneOS/iPadOS）では，AppleWebKit つまり Safari に基づいたブラウザしか認められていない．
- これは iOS 14 でデフォルトのブラウザが変更可能になっても変わらず．
- そしてこれらの端末を使用している個体は地球上に大変多い．
- 従って，Safari に対応していない Web アプリは iPhone の Chrome/Firefox 等でも動かないことになり，使いものにならない．
Safari の何が駄目なの？
Safari は例えば，以下の技術に対応していません：
- SharedWorker → Safari 16 で対応
- WebComponent Custom Element の継承
BroadcastChannel- iOS/iPadOS に於ける通知
- iOS/iPadOS 上の非Safariブラウザ (WkWebView) に於ける ServiceWorker
然も，これらの不備への開発チームの対応をみるに，あるいは Google が WebKit から離脱した経緯も考えるに，これからも彼らの技術的限界ないし問題からサポートが限定を受ける技術は多かろうと予想します．あゝ大変．
我〻は如何にすべきか
CustomElements の継承
これはあきらめて，統べて既存要素から継承しない独自の要素で構成するしかありません．
BroadcastChannel
Safari 15.4 から対応しました。
これは，Web Worker 内から使用しないのであれば，LocalStorage 及び StorageEvent で簡単にそれっぽいものを作ることができます．
SharedWorker
Safari 16 から対応しました。
WebSocket 接続を維持したり，共有の重い計算をするのにはとても重宝する機能ですが，限定的にエミュレートするしかありません：
- 最初に開いたタブなりで Dedicated Worker を走らせる．
- 上記の偽 BroadcastChannel でタブ間通信を行い，Worker が走るタブが消えたら別の誰かが開き直す．
iOS/iPadOS に於ける通知
Push API にも Web Notifications API にも対応していません。App Store にて管理される非Webアプリを優先したいと云う思惑が感ぜられます。
iOS/iPadOS 上の非Safariブラウザ (WkWebView) に於ける ServiceWorker
ServiceWorker が動作しない環境は，他にも Firefox のプライベートウィンドウなどがあるので，なるべく ServiceWorker が動作することがクリティカルな要件にならない様アプリケーションを設計するべきでしょう。どうしても必要な場合，iOS では Safari を使うように案内するなどが考えられます。
最後に
他にも Safari で困ることがあったり，解決法を見つけたりした方は，Twitter @chaankhoong まで仰ってください．