iOS版Chrome リリースに見るiOSプラットフォームの制約
アプリとしての使い勝手どうこうというところよりも、JavaScript エンジン周りをどうしているのかに興味があったのだけど、TechCrunch の記事 (http://techcrunch.com/2012/06/28/hands-on-with-googles-chrome-for-ios-just-like-chrome-for-android-only-slower/) を見る限り v8エンジンは搭載されていないし、当然 UIWebView での JIT コンパイラも有効にはなっていないように見えました。つまり、JavaScript の実効速度に関して言えば、Mobile Safari のそれを上回ることはない。(厳密に言えば、純粋な JavaScrpit の実効速度以外のところの実装が良くてトータルとして速い、というようなこともあるかもしれないですね。そこはベンチマークを取ってみないと何とも言えない。)
一方で昨日、facebook が iOS版のアプリを現在の UIWebView を使った方式では速度面の問題が解消できないというので、再度 Objective-C の実装に改めるというような記事 (http://bits.blogs.nytimes.com/2012/06/27/facebook-plans-to-speedup-its-iphone-app/) を見かけました。facebook がアプリの実装をネイティブから UIWebView を使ったハイブリッドモデルに切り替えたのが昨年のことで、なんとなくネイティブアプリから HTML ウェブへの流れのようなものが見えていたところ、この切り戻しが本当に行われるのなら「そう簡単にはいかないよ」という昨今の両者を取り巻く状況の象徴的な出来事になりそうだと感じます。
iOS版 Chrome に v8 が載らない (載せられない) のはなぜか
v8 (http://code.google.com/p/v8/) が載らないのは、アップルの "iOS Developer Program License Agreement" にそれをするなと書かれています、つまりは独自の JavaScript コアのようなものを搭載すると審査が通らない。ここが主な原因ではないかと思います。載らないのではなく載せられない。
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
以上、https://developer.apple.com/programs/terms/ios/standard/ios_program_standard_agreement_20120611.pdf からの引用。以前は「アップルが書面で許可すれば」というような文面だったようですが、今は上記のとおりで、ブラウザのように第三者が書いた JavaScript が実効されるような類のものに独自のエンジンを搭載してそれを実現するというのは禁止するような形になってました。Flash が駄目なのも、ここに相当するはずです。
Titanium Mobile なども、内部的には JavaScript コアを持っているのですが、Titanium で作られたアプリケーションの多くは " Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded." に相当するので審査を通るというような形だと思います。
この部分の規約は過去に何度も改訂されていて、Titanium Mobile も一時期規約に引っかかっているというので Titanium で開発したアプリが AppStore にリリースできないのではというような騒ぎがあったりもしましたが、今はこの形に落ち着いている。ブラウザ開発の文脈で言えば、相変わらず v8 を載せたブラウザ作れない、実質 HTML のレンダリングはそのまま UIWebView を使うしかない、ということになります。
なぜこのような規約が存在するかは、推測はできても、はっきりとは分かりません。Flash を禁止したいという直接的且つ戦略的な目的からなのか、あるいは次に記載する JIT のセキュリティの問題のようなもう少し実際的な問題からなのか。
UIWebView の速度が Mobile Safari より遅いのは
その UIWebView も、JavaScript の実効速度に関して言えば Mobile Safari のそれよりも遅い。これは iOS 開発者の間では有名な話で、以前に提供された Mobile Safari の Nitro エンジンをそのまま使っていないあるいは使ってても JIT コンパイラが有効になっていないと、その辺が原因です。
なぜそうなっているかは、ここは iOS のセキュリティ確保とのトレードオフがあって、http://www.imore.com/2011/03/17/safari-nitro-web-clips-uiwebview/ が詳しい。JIT コンパイルを行うにはメモリページを executable にする必要があるけど、それをすると認証されてないアプリが実行できるようになってしまうので iOS 全体のセキュリティコントロールが水の泡になってしまう、ということです。(なので、Jail Break した端末は例外になる)
結局この2点があって、iOS の規約/制約にそのまま従う、例外的な道筋がなければ、速度面で Mobile Safari の性能を上回るブラウザを作るのは難しい･･･というのが現状です。そんな事情を少々知ったかぶっていたので、今回の Chrome はこの課題はどうしたのだろうかと思っていました。Chrome の良いところは速度だけではないので「だからどうした」というのももちろんありますけどね。
ネイティブアプリなのかHTMLウェブなのか
職業上ときおり「いまモバイルの世界はネイティブアプリが主流ですが、これからまたHTMLウェブの時代になっていくのでしょうか? それともネイティブのままでいくのでしょうか?」というようなことを質問されます。モバイルウェブは、アップルの考えから自由になって、これまでの PCウェブのそれと同じような状態になるのかどうか、ということですね。今回の Chrome や facebook アプリの件と関わりの深い話です。
申し訳ないですが、正直分かりません。いまここで断言すると将来恥を掻くのが目に見えている。
分かりませんが、過去のアナロジーでいくと、ネイティブは廃れてHTML5アプリケーションの時代が来る･･･というのがわかりやすい流れだし、そうなることを望んでいる開発者あるいは企業の方がその逆よりも多いんじゃないかなという印象は受けます。自分的にも、ネイティブアプリよりは慣れ親しんだウェブアプリケーション開発の方が楽ですし、勝手も分かっていますのでそちらを推したい方です。
けれども、マーケティングやユーザーの支持だけでなく、アップルの戦略やiOSプラットフォームのセキュリティなど技術的な課題、といったところも変数にありますし、今回のブラウザの文脈で言えば (iOSのURLスキームがAndroidのIntentに比べて自由でないというような技術的な点も含め) Internet Explorer のときにあったような独占禁止法の問題とかも絡んでくるだろうし、一概に過去の例に沿って「間違いなく HTML で決まり」というようなことはなかなか言えないです。現時点で、自分がアプリで作るかウェブで作るかといえば「アプリで作る」ですしね。
面白いテーマ & 自分の今後に関係のあることには変わりないので、引き続き見ていきたいなとは思います。
