iOS版Google Chromeがver48.0でUIWebViewからWKWebViewに移行しました (2016/01/28)。このアップデートにより、それまでのクラッシュ率を70%削減し、JavaScript実行速度も大幅に上がりましたと書いています。2015年末にリリースされたiOS版FirefoxもWKWebViewを使用しています。
主要アプリがWKWebViewを採用していく流れのようです。ご自身のアプリにUIWebViewを使用している場合はWKWebViewへの移行も視野に入れてはいかがでしょうか。私自身WKWebViewを採用したブラウザアプリをリリースし15ヶ月以上運用していますのでその中で気付いたことも書いていきます。
理由1 クラッシュ率
UIWebViewには開発者レベルではどうにもならないクラッシュ問題が潜んでいます。特に複数のUIWebViewを使用するアプリでは顕著です。たとえGoogleの開発者であっても回避のしようがありません。
一方のWKWebViewではそのような理不尽なクラッシュ問題とは無縁です。Chromeはクラッシュ率70%削減としていますが、残りの30%もWKWebView自体にはほぼ非はなく実装方法や他の部分のものでしょう。
UIWebView/WKWebViewは共にメモリを大量に消費するのは変わりませんが、使用するメモリの領域に違いがあります。UIWebViewは各アプリのメモリ領域に存在するのに対し、WKWebViewはアプリ外の領域に存在しています。XcodeでWKWebViewのメモリ量を測定できないのはそのためです。
ちなみに、WebViewを多く使うアプリは最新の2GB以上のメモリを搭載したiPhone/iPad上では快適に動作します。
理由2 セキュリティ
UIWebViewが既にあるにも関わらず、AppleがWKWebViewを公開した一番の理由はこの点にあると考えています。
UIWebViewの接続先は他の通信関連APIで操作することが可能です。そのため、開発者に悪意があれば通信先をすり替えたり完全に遮断することが可能になります。
WKWebViewは通信関連APIでは操作することができません。これがChromeのデータ通信量削減機能が廃止になった理由です。
iOS 9から新たにApp Transport Securityという制限が加わりました。非推奨ですが不特定多数のWebサイトを表示する必要があるブラウザ等のアプリでは例外的にこの機能をOffにします(info.plist: NSAppTransportSecurity > NSAllowsArbitraryLoadsの値をtrue)。
理由3 将来性
UIWebViewは初期のiOSから存在しています。現時点ではDeprecated(廃止予定)とはなっていないものの、WKWebViewやSFSafariViewControllerがある今、Appleが今後もサポートし続けるのでしょうか？
ブラウザまでとは行かなくても少しWebサイトを表示したいという場合にはiOS 9で登場したSFSafariViewControllerで間に合っています。
WKWebViewもiOS 8では機能不足でしたが、iOS 9で機能が盛り込まれています。
iOS 9 WKWebView 主な変更点をざっくり
今後のiOSバージョンで更なる進化が期待できそうです。
WKWebView関連のリンク
WKWebViewで躓いた10つのまとめ
iOSアプリがWKWebViewかUIWebViewのどちらを使用しているかの判定方法
GitHub ShingoFukuyama/WKWebViewTips
アプリ単体とOS全体のメモリ領域を確認できるツール
PR
Ohajiki Web Browser
WKWebViewの高速なJavaScript実行環境を活かした機能を盛り込んだブラウザです。無料版もあるのでぜひお試しください。すべてのWebページの背景を黒くする・特定のコンテンツをブロックするなどJavaScriptの実行速度が遅いUIWebViewでは難しかったことも実用的になっています。