Opera Softwareが今週、自社の名を冠したウェブブラウザのiPhoneアプリ版をデモすると発表したことを受けて、このアプリが行き詰まっているという意見が数多く出ているほか、Appleがサードパーティ製ウェブブラウザを承認するかどうかについて、正当な憶測も飛び交っている。（同社はまだOpera MiniをAppleに承認申請していないが、Macworld UKの同僚たちが本日、Opera Miniを目にした。）
2008年後半には、OperaのiPhoneアプリが却下されたという噂がありましたが、Operaは実際にはApp Storeにブラウザを提出したことはありませんでした。そのため、iPhone向けOpera Miniの提出は、2つの点で意義深いものと思われます。まず、Opera MiniはSafariよりも劇的に高速で、同じWebページを表示するのに必要な帯域幅が大幅に少なく（下記参照）、お気に入りのサイトのサムネイルを表示して簡単にアクセスできる「スピードダイヤル」画面など、独自の機能を多数備えているため、このアプリの需要は確実にあるでしょう。次に、Opera Miniは、iPhoneのWebKitをベースとしていないWebブラウザとして、Appleに承認申請される最初のブラウザになるかもしれません。
しかし、状況はもう少し複雑です。開発者ガイドライン、過去の承認と却下、そしてiPhone版Opera Miniの実際の機能を考慮し、App Storeでの却下が推測される主な理由を以下に挙げます。
拒否の理由は?
Opera アプリが拒否される理由として最もよく挙げられるのは、アプリが既存の機能を重複していることと、Web ブラウザがアプリ内でコードをダウンロードして実行する必要があることです。
「既存の機能を重複している」 Appleは過去に、iPhoneの内蔵アプリケーションが既に提供している機能を重複していると判断した複数のアプリを却下してきました。Mobile Safariの存在だけでなく、AppleがSafariをiPhoneの主力アプリの一つとして重視していることを考えると、サードパーティ製のウェブブラウザは却下される運命にあると言えるでしょう。
しかし、Appleはこの点に関して少し緩和しました。2009年1月、AppleはApp Storeでサードパーティ製のWebブラウザの提供を開始しました。実際、App Storeで「Webブラウザ」を検索すると、現在141件の結果が表示され、そのうち4分の1程度は何らかのWebブラウザです。そのため、Opera MiniがMobile Safariを「複製」しているという理由だけでAppleが拒否するというのは、あまり説得力がありません。
「コードのダウンロードと実行は禁止」より大きな問題は、Webブラウザの基盤となるコードにあるようだ。現在App Storeで提供されているサードパーティ製ブラウザはすべて、iPhoneに内蔵されているWebKitエンジンを使用しているようだ。これはSafari自体のベースとなっているものと同じエンジンだ。つまり、iCabのような機能豊富なブラウザでさえ、iPhone独自のブラウザコードを使用している。Safariとは異なるインターフェースと機能セットを提供しているだけだ。
これは重要な点です。なぜなら、現代のブラウザはHTMLコードをレンダリングして静的で読みやすいWebページを表示するだけでなく、コードを実行できる必要があるからです。例えば、多くのサイトではJavaScriptが使用されているため、ブラウザにはこのコードを処理するJavaScriptエンジンが必要です。しかし、AppleのiPhone開発者ガイドラインでは、アプリがアプリケーション内でコードをダウンロードして実行することを禁止しています。そのため、この例では、サードパーティ製のWebブラウザは独自のJavaScriptエンジンを提供できません。（WebKitベースのブラウザでは、JavaScriptの例ではJavaScriptコードがサードパーティ製アプリ自体ではなくWebKitによって処理されるため、この制限を回避できます。）
したがって、当然の懸念は、AppleがWebKitベースではないブラウザを承認しないのではないかということです。しかし、Opera Miniはアプリの動作原理上、この制限は適用されないようです。Opera Softwareの最高開発責任者であるChristen Krogh氏に話を聞いたところ、Opera Miniは従来のWebブラウザではなく、同社のOperaサーバーソフトウェアのクライアントであると説明されました。
このクライアントサーバーシステムの仕組みは、Opera MiniでWebページをリクエストすると、アプリはURLを宛先のWebサーバーではなく、 Operaサーバーに送信するというものです。OperaサーバーはWebサーバーにリクエストを送信し、ページのコンテンツをダウンロードし、スクリプトやその他の動的コンテンツを処理し、結果のページをOperaバイナリマークアップ言語（OBML）に圧縮します。そしてOperaサーバーは、圧縮された「ページ」（元のWebページより最大90%サイズが小さくなります）を、スマートフォンのクライアントに送信します。
(このクライアント/サーバー方式と、頻繁にアクセスされる Web ページのキャッシュにより、Opera Mini は Safari より高速です。同社によれば、クライアントに転送するデータ量が非常に少ないため、Opera Mini を使用したブラウジングは Safari より最大 6 倍高速で、データ プランが限られているユーザーにも便利な方式です。)
つまり、Opera Miniアプリは本格的なウェブブラウザではなく、本質的にシンクライアントであり、コードのダウンロードや実行は一切行いません。このアプローチにより、アプリ内ダウンロードやコード実行が拒否されることはないように思われます。
制限事項
Opera Mini のクライアントサーバー型アプローチの欠点は、アプリが処理できるコンテンツの種類に大きな制限があることです。JavaScript、Ajax、その他の動的コンテンツを多く含む Web ページの場合、Krogh 氏はMacworldに対し、Opera サーバーはページを仮想スクリーン上にレイアウトし、ページ上で可能な限り多くのアクションを実行し、その後、ほぼ静的なページをクライアントに送信すると述べています。ページがユーザーインタラクションを必要とする場合は、OBML 版にトリガーが用意されており、Opera サーバーにデータを送信することで、新しいバージョンのページがクライアントに送信されます。これにより、例えば Opera Mini で JavaScript フォームに入力することが可能になります。
クロッグ氏によると、同社のテストでは、この技術はウェブ上で最も人気のあるサイトの大半で動作するとのことだ。しかし、あらゆるタイプのコンテンツに対応できるわけではない。クロッグ氏はリアルタイムアニメーションのあるサイト（リアルタイムで更新される時計を例に挙げた）は期待通りにレンダリングされず、Opera Miniはバックグラウンドスクリプトを実行できない。
(Opera Mini はiPhone がサポートするほとんどの種類のメディアを処理できます。Mobile Safari と同様に、Opera はそれらの種類のメディアを iPhone のネイティブ メディア プレーヤー (たとえば、Safari で .mp4 ビデオへのリンクをタップしたときに表示されるプレーヤー) に渡します。)
Opera Mini も、iPhone 向けの他のサードパーティ製ブラウザと同様の制限を受けます。例えば、Mac OS X とは異なり、iPhone ではデフォルトのブラウザ（他のアプリ内のリンクやボタンをタップした際に使用されるブラウザ）を変更する方法がありません。そのため、メール内のリンクをタップしても、その URL は Safari で開かれ、優先ブラウザでは開きません。同様に、Mac 版または Windows 版 Safari と Mobile Safari の間でブラウザのブックマークを同期することはできますが、Opera Mini や他のサードパーティ製 iPhone アプリブラウザでは同期できません。そしてもちろん、iPhone ブラウザは Flash コンテンツをサポートしていません。
見通しは良いですか?
Opera Softwareの公式見解は、ブログ記事で述べられているように、「Appleがユーザーのウェブブラウジング体験の選択肢を否定しないことを期待している」というものだ。しかし、Opera Softwareが、Appleのアプリガイドラインとアプリ承認プロセスへの懸念から、Opera独自のブラウザエンジンをベースにしたより高機能なOpera Mobileではなく、携帯電話向けブラウザであるOpera MiniをiPhoneに搭載することを選んだのは明らかだ。そのプロセスの内部事情は私たちには分からないが、私たちの立場から見ると、Opera Miniが承認される可能性は十分にあるように思える。
アプリが承認されなければ、テクノロジー系メディアはApp Storeの承認プロセスにおける問題の例として、このニュースに飛びつくことは間違いないでしょう。実際、Operaの知名度を考えると、iPhone版Opera Miniのデモを公開し、アプリの申請前にそのデモを発表するという同社の決断は、App Storeの承認プロセスに再び注目を集め、Appleにアプリの承認を促すための巧みなPR戦略だったと言えるでしょう。
