AppleがiOSサンドボックスを開放すべき理由

スマートフォン評論家の世界では、サンドボックス化（ソフトウェアが本当に必要なファイルや機能のみを扱うように制限する）という概念は、賛否両論の分かれるテーマになりがちです。一方では、パワーユーザーは、コンピューターやモバイルデバイスを思い通りに使う能力が制限されることに憤慨しています。一方では、Appleがこの理念で成功を収めてきたこと、特にモバイル市場において、安全かつ普及率の高いコンピューティングプラットフォームを構築してきたことに異論を唱えるのは難しいでしょう。

しかし、サンドボックス化も時代遅れになりつつあります。iOSデバイスの機能はデスクトップ版に急速に近づいている一方で、iOSアプリ間の通信機能は2007年当時のままです。そろそろ変革の時です。

砂の城とセキュリティ

サンドボックスは、セキュリティと制御を主な目的とする技術として広く宣伝されています。デバイスにインストールできるアプリとその機能について非常に厳格なルールを強制することで、Appleは（大部分において正しく）ユーザーに、データや個人情報の盗難を心配することなく、安全なコンピューティング環境を提供できると主張しています。

しかし、より深いレベルでは、サンドボックス化により、同社はデスクトップ コンピューターのパフォーマンスに匹敵する革新的なモバイル エクスペリエンスを実現するという約束を果たすことにも成功しました。

初期のiPhoneとiPadは、本質的に大きな画面と大きなバッテリーを搭載していました。そのため、パフォーマンスと消費電力の両方に深刻な制約があり、このまま放置すれば、Appleがユーザーに期待するインタラクションを著しく阻害する可能性がありました。ユーザーがバックグラウンドで数十ものアプリを起動し、それぞれがCPUサイクルと電力を寄生的に消費している状況では、スムーズなスクロールを安定して提供したり、一日中使えるバッテリー駆動時間を実現したりすることは困難です。

サンドボックスを導入することで、Apple は、経験や大胆さに関わらず、すべてのユーザーが常に同社が約束したパワーを享受できるようにするための一連の妥協策を確立し、実施することができました。

私たちみんなは愚か者だ

しかし時代は変わり、今日の平均的なモバイルデバイスは、先代に比べてハードウェアの制約がはるかに少なくなっています。通常は技術的な説明を避けてきたApple自身のマーケティング資料では、iPhoneとiPadは画面の下に「デスクトップクラス」のハードウェアを搭載していると謳っています。

残念ながら、サンドボックス化はこうした変化に対応できていません。確かに、初期の制限の一部は解除されました。例えば、サードパーティ製ソフトウェアは特定の状況下でバックグラウンドで実行できるようになり、アプリはユーザーの指示があれば直接、あるいはシステムクリップボード経由でファイルを交換できるようになりました。

しかし、アプリ同士が直接通信する機能は、依然としてカスタムURLという概念に限られています。このシステムでは、OSに特別に作成されたアドレス（ウェブサイトにアクセスする際に使用するアドレスに似ています）を「開く」よう要求することで、アプリが別のアプリにデータを送信できます。このアドレスは、別のアプリがインストール時に登録されます。こうしたカスタムURLスキームで多くのことが可能になりますが、まだ可能性のほんの一部に過ぎません。 

iOS の伝統とその市場の両方を考慮すると、アプリ間通信に対するこの制限は、さらに苛立たしいものになります。

大きなパイプ1本

UNIXのターミナルやコマンドラインの世界では、ユーザーは長らく「パイプ」の威力を享受してきました。これは、複数のコマンドを様々な方法で連結できる技術です。あるコマンドの出力を次のコマンドの入力にパイプすることで、熟練したユーザーは、一連の構成要素を組み合わせるだけで、驚くほど複雑なアプリケーションを構築できます。

この設定の必然的な帰結として、この世界における個々のアプリは特定のタスクに極めて集中する傾向があり、大規模でモノリシックなソフトウェアに組み込むのが難しい高度な専門性を備えています。当然のことながら、データの並べ替えだけに特化した優れたアプリを開発する方が、他の無数の機能も提供しなければならないソフトウェアパッケージの中で、データの並べ替えを単なる目玉として扱うよりも簡単です。

意外かもしれませんが、UNIXのソフトウェア開発手法は、ソフトウェアを標準化すると同時に、ユーザーによるカスタマイズ性を高める傾向があります。特定のアプリケーションの動作が気に入らない場合、ワークフローにわずかな変更を加えるだけで、パイプ式でそのアプリケーションの代わりに使用できる別のアプリケーションが見つかる可能性があります。

小さいことは美しい

GUI やタッチ インターフェースの世界では、ターミナルやパイプは、本格的なコンピュータの専門家だけが興味を持つような難解なテクノロジのように思えるかもしれませんが、その基本概念は、ソフトウェア価格に下方圧力がかかり、特定のタスクに重点を置く小さなアプリが有利になる傾向がある今日の iOS 市場に非常によく当てはまります。

パイピングは従来、コマンドライン インターフェイスに結び付けられてきたという考えを一旦脇に置いておくと、1 つのアプリから別のアプリへのデータのチェーンを含むワークフローを作成するという考え方には、ユーザーと開発者の両方にとって多くの利点があります。

デバイスの高性能化と熾烈な市場競争により、顧客はソフトウェアに格安価格を支払いながらも、より生産性の高いものを期待するようになります。残念ながら、開発者は常にほぼ完全に自給自足できるプログラムを開発することを求められており、それはつまり、特定のアプリを独自性のあるものにするコードだけでなく、はるかに多くのコードを扱わなければならないことを意味します。

焦点を当てるべき場所

たとえば、カメラ アプリを考えてみましょう。このカテゴリは非常に競争が激しいため、開発者が苦労の成果に対して請求できる金額の上限は 1 ドル程度です。

問題は、たとえ特定のアプリが、多数の写真を高速で連続撮影したり、パノラマ写真を撮影したりするなど、独自の機能を備えているとしても、フィルタリング、切り取りと編集、赤目軽減など、ユーザーがその類のアプリに期待するその他の機能もすべて提供する必要があることです。

iOS 自体がこれらの機能の一部を提供している一方で、開発者には、構築したアプリの中心ではないコードに時間を費やすか、問題を完全に無視して、ユーザーが何らかの方法で、同じレベルの機能に近い独自の手動ワークフローを構築する方法を見つけ出すことを期待するしか選択肢がありません。

最終的な結果は誰の利益にもなりません。開発者は既に他者が実装している機能に時間を浪費し、ユーザーは結局、同じ機能を実装しながらもユーザーインターフェースに一貫性がなく品質もばらばらの、水準以下のアプリを使うことになります。また、同じドキュメントがアプリ間でやり取りされる際に、一貫性のない複数のコピーが作成されるワークフローも発生します。

一方、アプリが相互に通信できれば、この例の写真アプリは最高のパノラマ ステッチ エクスペリエンスを提供することに集中し、残りの機能を他のアプリに委任できます 。 他のアプリは独自のインターフェースを使用して元のファイルを操作し、それを元のアプリに返すことができるため、ユーザーは両方のメリットを享受できます。

AからB、そしてCへ

何らかのアプリ間通信メカニズムが存在すると、ユーザーは複数のアプリが提供するサービスを、ユーザーの介入なしに実行できるまとまりのある一連の手順にまとめることも可能になります。おそらく、OS X の Automator のように、技術的な知識がほとんどまたは全くなくても複雑なワークフローを簡単に作成できるアプリを介して実現されるでしょう。

AppleがAutomatorをiOSに導入すべきだと必ずしも言っているわけではありませんが、Launch Center Proのようなアプリが、iOSのサンドボックスモデルによって現在課せられている様々な制限があるにもかかわらず、どれほど便利であるかを考えれば、アプリ間のコミュニケーションが改善されれば、コンピューターの知識の有無に関わらず、誰にとってもどれほど大きなメリットになるかは容易に想像できます。ユーザーは、モバイルデバイスに期待されるシンプルなインターフェースを使って、メールの送信からリマインダーの設定まで、あらゆる複雑なワークフローを作成できるようになります。