「Webアプリはもう動いているので、それをアプリストアにも出したいだけです」。
見積りを依頼する側にとって、この要望はとても小さく聞こえます。中身は同じなのだから、外側をアプリの形にして包めば終わりだろう、と。実際、開発を始めた直後まではその見立てで進みます。PCのブラウザで問題なく動いていたものが、シミュレータでもだいたい動く。
壊れるのは実機に乗せた瞬間です。レイアウトが画面下の帯に食い込む。オフライン対応が黙って無効になっている。入力欄をタップすると画面全体が跳ねる。しかもそのどれもが「バグ」ではなく仕様で、Web標準のドキュメントを読んでも書いていない。この体験を正面から書いたのがWeb を iOS に乗せると仕様書に載っていない WebKit にボコボコにされる（Zenn）で、少数精鋭の開発会社が実案件で踏んだ内容が具体的に並んでいます。
「Safariで動いた」は「WKWebViewで動く」ではない
いちばん誤解されるのがここです。iOSのアプリ内でWebを表示する部品（WKWebView）は Safari と同じ WebKit を使っていますが、同じエンジンだからといって同じ機能が有効とは限りません。
代表例が Service Worker です。オフライン対応やキャッシュ制御の土台になる仕組みですが、WKWebView ではアプリ埋め込みのWebコンテンツに対して既定で動きません。有効にするには App-Bound Domains という仕組みを使い、Info.plist に対象ドメインを列挙したうえで、WebView 側で limitsNavigationsToAppBoundDomains を有効にする必要があります。
そしてこの App-Bound Domains には、列挙できるドメインが最大10件という上限があります。外部の決済画面、認証プロバイダ、CDN、計測タグと数えていくと、この10件は思ったより早く埋まります。しかも上限を引き上げる公式な手段は用意されていません。
つまり「オフラインでも使えるようにしてほしい」という要件は、Webとして実装するときとWKWebViewに載せるときで、難易度が段違いになるということです。ブラウザで完結する前提のオフライン設計についてはローカルファーストのWebアーキテクチャで扱っています。
見た目が崩れるのは、たいてい「画面の端」から
実機で最初に気づくのは、だいたいレイアウトです。ノッチや Dynamic Island のある端末で、コンテンツが上下の安全でない領域に潜り込む。あるいは逆に、画面の上下に黒い帯が残る。
原因は単純で、viewport-fit=cover を指定していない状態では env(safe-area-inset-*) がすべて 0 を返すからです。CSS側でセーフエリアを避ける実装をしていても、値が 0 なら何も避けません。指定すると WKWebView 側の挙動も切り替わるため、「meta タグを1行足したら今度はスクロール位置がおかしくなった」という二次被害も起きます。
ここで効いてくるのが、この種の調整は「デザインの修正」ではなく「端末実機での検証工数」だという点です。iPhone のどの世代まで見るのか、横向きを許すのか、キーボードが出た状態のレイアウトをどこまで作り込むのか。項目としては地味ですが、実機の台数と検証の往復が工数の大半を占めます。
「Webサイトを包んだだけ」は審査で止まる
技術的に動いたとしても、最後にもう1つ関門があります。Apple の App Review Guidelines には最低限の機能に関する項目があり、既存のWebサイトを再パッケージしただけのアプリは、単体で十分な価値や有用性がないと判断されると承認されません。
これは制作側の腕の問題ではなく、方針として決まっている話です。したがって企画の段階で「アプリにしかない体験を何にするか」を決めておく必要があります。プッシュ通知、カメラ連携、オフライン閲覧、生体認証。何か1つは、Webのままではできないことを持たせる。
この判断は発注側にしかできません。制作会社が勝手に機能を足せば見積りが膨らみ、足さなければ審査で返ってくる。着手前に握っておく価値がいちばん高い項目です。
見積り前に決めておくと揉めない4項目
要件定義の段階で次の4つを埋めておくと、後からの追加費用と手戻りがかなり減ります。
| 決めること | 決めないまま進むとどうなるか |
|---|---|
| 対応する iOS のバージョンと端末世代 | 実機検証の範囲が無限に広がり、リリース直前に発覚する |
| オフラインで何ができる必要があるか | Service Worker 前提の設計が WKWebView で成立せず作り直しになる |
| アプリ内で開く外部ドメインの一覧 | App-Bound Domains の10件上限に後から当たる |
| アプリ版にしかない機能を何にするか | 審査で差し戻され、追加開発の費用と期間が発生する |
3つめは特に忘れられがちです。決済や外部認証をあとから足すと、動いていたオフライン機能が急に無効になるという形で跳ね返ります。
なお、そもそもストアに出す必要があるのか、という手前の検討も一度は通す価値があります。ホーム画面に置けてプッシュ通知も送れる形であれば足りるケースは実際にあり、その判断軸は中小企業のためのPWA入門にまとめています。既存のWebアプリのドメインやオリジンを変える場合の注意点はPWAのオリジン移行を参照してください。
着手するなら
「Webアプリをそのまま包む」という前提で見積りを取ると、ほぼ確実にずれます。ずれの正体は実装量ではなく、実機検証・審査対応・オフライン設計のやり直しという3種類の見えにくい工数です。
まず決めるべきは、アプリにする目的を1つに絞ることです。通知を送りたいのか、オフラインで使いたいのか、ストアに並んでいること自体に意味があるのか。ここが決まると、上の4項目はほぼ自動的に埋まります。
既存のWebアプリをどこまでアプリ化すべきか、そもそもその形が最適かといった相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
