こんにちは〜！ モバイルチームの向井田です。
iOS の UIWebViewが deprecated になって数年、弊社の iOS アプリもようやく WKWebViewに移行できるようになりました。
そこで、今回は私たちが WKWebViewに乗り換えられるようになった理由を語っていきます。
TL;DR
iOS12 から WKWebViewでクライアント証明書を使ったSSL通信が正常に動作するようになりました。
kintone モバイルのリニューアル
kintone モバイルが大幅リニューアルし、UIを一新しました 🎉
https://kintone.cybozu.co.jp/update/main/2019-05.html
リニューアルを期に、コードを Objective-C から Swift ベースに書き直しています。
kintone モバイルは JavaScript カスタマイズをサポートするために、大部分が WebView で構成されています。
iOS8 以上は WKWebViewを使うように Apple からアナウンスされていますが、旧バージョンでは UIWebViewを使い続けていました。
今回のリニューアルで、iOS12 以上であれば WKWebViewを使用するようになりました。
なぜ UIWebView を使い続けていたのか
WKWebViewへの移行には、弊社のクラウドサービスが提供しているセキュアアクセスという機能が関係しています。
セキュアアクセスの説明
弊社のクラウドサービス基盤である cybozu.com が提供するセキュアアクセスは、サーバ側でユーザごとに発行されたクライアント証明書を用いて通信することで、IPアドレス制限がされた環境にも安全にアクセスする仕組みです。
https://www.cybozu.com/jp/service/option/
この機能を kintone モバイルでもサポートするために、WebView のリクエストにクライアント証明書を付与して認証する必要がありました。
旧バージョンでは、NSURLProtocolを継承した CustomHTTPProtocolを使い、UIWebViewの通信をハンドルして実現していました。
https://developer.apple.com/library/archive/samplecode/CustomHTTPProtocol/Introduction/Intro.html
WKWebView ではクライアント証明書の認証がサポートされていたはずだったが…
UIWebViewの後継である WKWebViewでは、公式に Authentication Challenge 時に呼ばれる Delegate が用意されました。
optional funcwebView(_ webView:WKWebView, didReceive challenge:URLAuthenticationChallenge, completionHandler:@escaping (URLSession.AuthChallengeDisposition, URLCredential?) ->Void)
https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455638-webview
WKWebViewが世に出たとき、私たちはもちろんこの Delegate に飛びつきましたが、この Delegate には重大なバグがあります。
iOS11 以下の場合、Delegate の中で PKSCS#12形式の証明書を渡しても、Authentication Challenge に失敗します😱😱😱
つまり、WKWebViewを使ったクライアント証明書認証による通信は実現できませんでした。
上記のバグは Apple のフォーラムでも報告されており、iOS12 でようやく改修されました。
そのため、私達も iOS12 以上の場合に限り、WKWebViewをプロダクトで使用できるようになりました。
WKWebView でクライアント証明書の認証を実装する
めでたく WKWebViewを使ったクライアント証明書による認証が正常動作するようになったので、実装を紹介します。
下のサンプルコードは WKNavigationDelegateの webView(_:didReceive:completionHandler:)を実装した例です。
challenge.previousFailureCountでリクエスト毎の認証チャレンジの失敗回数が取得できます。
失敗の上限を決めておかないと、クライアント証明書が無効のときに無限にリクエストを送り続けてしまうので注意です。
challenge.protectionSpace.authenticationMethodでチャレンジする認証の種類が取得できます。
クライアント証明書での認証時は、NSURLAuthenticationMethodClientCertificateで定義された文字列が challenge.protectionSpace.authenticationMethodに入っています。
クライアント証明書による認証が求められた場合は、クライアント証明書から URLCredentialを生成し、completionHandlerに渡します。
extensionViewController:WKNavigationDelegate { funcwebView(_ webView:WKWebView, didReceive challenge:URLAuthenticationChallenge, completionHandler:@escaping (URLSession.AuthChallengeDisposition, URLCredential?) ->Void) { // 一度でも認証に失敗したらやり直さないif challenge.previousFailureCount >0 { completionHandler(.performDefaultHandling, nil) } // クライアント証明書での認証が必要if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodClientCertificate { // クライアント証明書の取り出しifletidentity=self.loadCertificate(from:certFilename, password:certPassword) { letcredential= URLCredential(identity:identity, certificates:nil, persistence:URLCredential.Persistence.forSession) // クライアント証明書による認証にチャレンジする// iOS12 以上でないと正しく動作しない completionHandler(.useCredential, credential) return } } completionHandler(.performDefaultHandling, nil) }
PKSCS#12形式のクライアント証明書ファイル(.pfx ファイル)から URLCredentialを生成するには、ファイルをインポートしてSecIdentityオブジェクトにする必要があります。
SecIdentityは PKSCS#12ファイルに含まれるデジタル証明書と秘密鍵がセットになったオブジェクトです。
SecPKCS12Import(_:_:_:)を使って .pfx ファイルを SecIdentityに変換します。
以下のコードは、プロジェクトファイルに予め配置しておいた .pfx ファイルから SecIdentityを生成する例です。
privatefuncloadCertificate(from filename:String, password:String) ->SecIdentity? { guardletpath= Bundle.main.path(forResource:filename, ofType:"pfx"), letpfxData= try? Data(contentsOf:URL(fileURLWithPath:path)) else { returnnil } varresult:CFArray? letquery= [ kSecImportExportPassphrase as String:password, ] // result にインポートした結果が格納されるletstatus= SecPKCS12Import(pfxData as NSData, query as NSDictionary, &result) if (status != errSecSuccess) { returnnil } letresultDict= result as? [[String :Any]] letidentity= resultDict?.first?[kSecImportItemIdentity as String] as! SecIdentity return identity }
WKWebView のインスタンスに delegate をセットするのを忘れないでください。
classViewController:UIViewController { varwebView:WKWebView!overridefuncviewDidLoad() { super.viewDidLoad( self.webView = WKWebView(frame:self.view.frame) self.view.addSubview(self.webView // ViewController で Delegate を処理するself.webView.navigationDelegate =self } ...
ここが便利だぞ WKWebView！
今更ですが、WKWebViewを導入したことで得たメリットを紹介します。
タップ時の遅延が改善される
UIWebViewは、ダブルタップでズームできるようにするために、シングルタップしてから画面が反応するまでに350msほど遅延がありました。
このタップ遅延の問題は多くの開発者を悩ませていたようで、FastClickというサードパーティのライブラリまで登場しました。
UIWebViewで構成された旧バージョンの kintone モバイルでもタップ遅延が発生しており、ユーザの操作感が非常に悪いものになる要因でした。
WKWebViewではこの問題が解消されており、Safariと同様に反応が良いアプリを実現することができます。
https://webkit.org/blog/5610/more-responsive-tapping-on-ios/
HTTPステータスコードがハンドルできる
私たちのようにネイティブアプリ内で WebView を使った UI を提供している場合、WebView が受け取ったレスポンス内に含まれているHTTPステータスコードをハンドルしたいケースがあります。
しかし、UIWebViewは WebView 内のレスポンスが外部から参照できない形になっており、HTTPステータスコードを取得できない仕様でした。
WKWebViewであれば、以下のサンプルのようにして ロードしたいページの HTTP ステータスコードを取得できます。
navigationResponse.responseは WKWebViewがロードしようとしているページのレスポンスで、URLResponse型のオブジェクトです。
http通信のレスポンスであれば、navigationResponse.responseは URLResponseクラスのサブクラスであるHTTPURLResponseに置換できます。
この HTTPURLResponseが持っている statusCodeプロパティが HTTP ステータスコードです。
funcwebView(_ webView:WKWebView, decidePolicyFor navigationResponse:WKNavigationResponse, decisionHandler:@escaping (WKNavigationResponsePolicy) ->Void) { ifletresponse= navigationResponse.response as? HTTPURLResponse { if response.statusCode ==200 { print("success💯") } if response.statusCode >300 { print("failure...🤮") } } decisionHandler(.allow) }
まとめ
UIWebViewはパフォーマンスやセキュリティの観点で様々な問題があるので、より安全で高速な WKWebViewに乗り換えていきましょう！