・Flash問題が勃発！

iPhoneで話題になっているFlash問題は2つの異なる局面で発生しています。ひとつはSafariで「Flash Player Plugin」がサポートされないため、ウェブ上のFlashコンテンツが表示（再生）できないことです。もう一つは、Apple社からiPhone SDK以外で開発されたiPhoneアプリを認可しない規約が提示されたため、Adobe社が用意したクロスプラットフォーム向けFlash環境でiPhoneアプリを開発しても、それをApp Storeへ登録申請できないことです。

これらの問題、どうしてもJobs個人や政治的な話題が前面に出てしまい、現場からの技術的考察が少ないような気がします。何やらJobs一人ですべてを決めているように歪曲し脚色されがちですが（笑）当然、Apple社の屈強なソフトウェアチームが技術的な裏付けを取り上部へレポートを上げることで企業としての最終意思決定となっているはずです（多分）。Flashを使うとバッテリー消費が大きくバグも多いと言及されている点は、そうした調査レポートからの引用だと思われます。

また両方の問題を混同している人も多数見かけますが、もともとこの2つは異なる状況下で発生しています。ただし、両者の根幹にはまったく同じ原因が横たわっている可能性もあるようで、その中のひとつは、iPhoneやiPadの「ユーザ体験（User Experience）の劣化」に対する大きな懸念です。加えて、Apple社側には「Adobe社の長きに渡る技術的怠慢」という認識（恨み？）もありそうです...。実際、少なからずあるでしょう（笑）。

・ 良好なユーザ体験が最優先

この問題を議論する場合に、iPhoneやiPadを今までのPC（パーソナルコンピュータ）と同列に並べて話を進める人がいますが、おそらくそれは間違いです。Apple社の最終ゴールは、PCでの劣悪なユーザ体験を撤廃し、現在の環境（物理的制約はある）において最善なユーザ体験を提供することだと思われます。つまり「脱PC」です。よって、この問題を議論するのに旧態依然としたPCの状況を持ち出しても、妥当な結論は導かれない気がします。

iPhoneやiPadを旧PCから脱却させて別カテゴリーの製品にするには、PCでの反省点を生かす必要があります。例えば、PCでの劣悪なユーザ体験の中でも最も改善すべきは「セキュリティ問題」でしょう。Apple社の行動には、セキュリティを保つためならユーザに対して幾らかの不便を与えても、それを保全する仕組みを優先するという判断が見受けられます。例えば、iPhoen OSでの機能限定や、App Storeでの審査などがそれです。

現在のPC体験を思い浮かべてみましょう。ウェブ閲覧とメールだけを使うユーザが、パソコン購入後に高価なウィルスチェックやセキュリティソフトを購入、何故か処理が遅くなったのでパフォーマンスアプリを購入、するとシステムが不安定になりクラッシュを繰り返すのでバックアップを取る仕組みの構築に奔走...。こうした異常なユーザ体験はもう二度と繰り返したくない。今度こそ絶対に避けるべきだという決意があるのでしょう（そうは思いませんか？）。

・ 臨機応変に対処できないのか？

iPhone OSでは、セキュリティ対策としてJavaScript以外の言語処理系の実装は禁止されています。セキュリティの穴を防ぐためにシステム全体に影響を及ぼす言語処理を禁止するのは良策です。そう言う意味ではFlashだけが特別な訳ではなく、iPhone OSにはJavaなども実装されていません。この制限は徹底されており、Safari（ウェブ環境）だけでなく、一般アプリで言語処理を扱うこと（例えば簡易スクリプトなど）も禁止です。よって、これに反するアプリはApp Storeへ申請しても間違いなくリジェクトされます。

デバイスがiPhoneならばそうした制限もOKだと思いますが、教育機関へも大量に導入されるだろうiPadを考えると、この処置を回避する道も残しておいて頂きたい。そうでないと、子供や学生にiPadを用いたプログラミングを体験させる手段が無くなります。例えば、Smalltalk環境のひとつSqueak（スクイーク）を利用した「Squeak EToys」などは、教育機関でも高い評価を得ています。絵画や音楽、デザインと同等にプログラミングの楽しさを広めるためには、何らかの言語の習得は避けて通れません。

プログラミング教育のために、Sandbox内でインタープリタ系の言語を使う程度は許してもらいたいところです。 これ以外の制限や検問に関しても、Apple社の「臨機応変」の対応が望まれますが、今までの流れから「あれが良いのにコレがダメなのは何故？」という議論が巻き起こるのは必至であり、Apple社の対応にも難しい側面が有ることも理解できます。とにかく言語は何でも構いません、それを使えるHyperCardのような教育用プログラミング環境がApp Storeで認可されることを切望したいと思います。

・ 伝言ゲームをやってみる

話を元に戻して、もうひとつのFlashの問題について考えてみます。ちなみに、こちらの問題もFlash環境だけの話ではありません。別の開発環境についても言えることです。ここでは、アプリ動作の仕組みを伝言ゲームに例えてみます。何人かのメンバーが一列に並んで左側の人から右側の人へと順に伝言を伝えます。一番左側の人がプログラマが書いたソースコードの役割だとすると、一番右側の人がある機能を実行するために最終的にデバイスへ命令を伝えるわけです。

例えばFlashでiPhoneアプリを開発すると言うことは、この伝言システムの列の中にさらに何人ものメンバーを追加することを意味します。実は、どの位置に何人加えるかも大きな問題なのですが、とにかく物理的に見れば（加えた人が優秀かどうかは別として）処理が完結するまでの人数が増えます（アプリ容量の増加）。伝言が伝わるスピードも遅くなります（処理速度の低下）。そして今までより伝言のミスが起こる確率が高くなります（バグの増加）。

つまりアプリの処理スピード低下、 容量増大 、バグ増加、といったユーザ体験を劣化させる要因が確実に増えるわけです（確率的に）。実際の例を挙げてみますと、ネイティブ環境で開発すれば数十Kバイトの容量で収まるアプリも、Flash環境で開発すると7〜８Mバイトの容量になります。これは、Flashから変換されたすべてのiPhoneアプリに「Flash Player Plugin」に準ずるソフトモジュールが付加されている結果です。今風に言えば「エコでない」ということになります（笑）。

・ 更なる大きな問題点

更に大きな問題点があります。システムが一新されて最初のメンバーが入れ替わったとします。しかし、後で外部から投入されたメンバーはそのままです。この状況下、最悪の場合には最初のメンバーと後のメンバーで「言葉が通じない」問題が生じます。つまりクラッシュです（笑）。仕方がないので、後からのメンバーを再教育し（もしくは交代）新規メンバーのレベルに合わせる必要がありますが、その作業にあまり時間がかかると、システムとしての競争力を保てなくなります。

ネイティブ開発環境であれば、最初のメンバー（OSやFramework）が一新された時点ですべての最新機能が利用できるようになります。例えば、iPhone OS 4.0で導入されたアプリの高速スイッチ機能であれば、実際のところ3分もあれば対応可能です（Xcodeでビルドし直すだけ）。しかし、もしこれがFlashコンテンツから変換されたアプリだとすると、Flash自体の変換処理が4.0のランタイム環境をサポートしないかぎりは、この機能に対応できないことになります。

この仕組みには、アプリ開発可能なデベロッパー数を増やすメリットもあります（伝搬距離が長くなるので）。昔のMac市場のように、デベロッパーが少なくてMacオリジナルアプリの開発が困難な場合、こうしたクロスプラットフォーム開発環境を活用しWindows用アプリを移植して需要を満たしていました。しかし、iPhone OSの場合には既に多くのネイティブデベロッパーがいて、20万以上ものアプリが提供されています。 今さらそうした仕組みが必要かと問われれば「必要ない」と判断されても仕方がないでしょう。

・ パソコンの悪夢が蘇る

ところで、FlashアプリはiPhone OSで使うAPIやメソッドを使っていない可能性があります（追加メンバーの並び位置の問題）。この場合、iPhone OSが最新にアップデートされた時に特定の機能が使えなくなったり、アプリ自体が起動できなくなる可能性が高まります（Photoshop Elementsみたいに）。加えて、APIやクラス＆メソッドを追跡することで「アプリが何をしているのか？」を解析することも困難となり、Apple社が「セキュリティ面の大きな脅威」と見なすのも仕方がないことです。

新しいOSにしたらアプリが起動しなくなった。特定の機能が使えなくなった。なのに新OSへの対応はまったく進まない。これもパソコンで繰り返されてきた劣悪なユーザ体験のひとつです。逆にルールを守りネイティブなAPIのみを正しく利用したアプリの寿命は長く、多くのユーザから信頼を勝ち得ます。例えば、筆者が1986年にMacのToolBox APIのみを使い開発した「QuickScan」（当時はDesk Accessary）は、現在でもMac OS Xのクラシック環境でちゃんと動きます。

Adobe社がFlashコンテンツをiPhoneアプリに変換する仕組みを何としても世に広めたいのならば、FlashのコードをiPhone OSのAPIやメソッドに変換し、それをXcodeのソースコード（C、C++、Objective-C）として吐き出す仕組みを提供することです。その後デベロッパーがXcodeでiPhoneアプリをビルドすれば、Apple社も文句の付けようがありません。「Flashはクロスプラットフォーム対応だ」と叫ぶのであれば、Adobe社にはそのくらいの技術と根性を見せて欲しいところです（笑）。

・競争力あるアプリの開発

Jobsが「iPadにはiPhoneで使い方をマスターした何千万人の潜在ユーザがいる」と話していました。共通で快適なユーザ体験だけでなく、ハイブリッドアプリを購入すれば両デバイスで使える「お得感」も大きな購入動機になるはずです。これからは、iPadを購入したユーザが逆にiPhoneを選ぶケースも増えるかもしれません。また、将来的にはMac上でiPadのアプリが起動できる可能性もあります（既にシミュレータ上ではx86コードで動いている）。間違いなくターゲット市場は拡大しています。

現在では、OpenGLやCoreGraphicsを用いた優秀な2D＆3Dや物理エンジンも多数あります。それらを活用すればFlashコンテンツのiPhoneへの移植も割と簡単でしょう。既に多くのFlashゲームがiPhoneアプリとして登場している実績もあります。また、iPhoneのネイティブ開発環境をマスターすれば、その経験と知識はそのままiPadアプリ開発に生かせます。加えて、いくらかの追加学習でMacアプリの開発も可能になるわけです。今、CocoaやObjective-Cにチャレンジして損をすることはないと確信します。

誰もが自分の使い慣れた環境でアプリを開発したいものです。そういう意味では、今回の制限は、FlashによるiPhoneアプリ開発を考慮していた人にとって不幸な出来事でした。しかしデベロッパーの視点からすると、競争力のあるアプリを世に出したければ、ネイティブアプリを開発する以外に選択の余地はありません。素晴らしいアイデアを実現したFlashコンテンツがあり「これなら絶対にiPhone界を征服できる」という確信があれば、今すぐネイティブアプリへ移植し、速攻でApp Storeへ登録申請されることをご推奨いたします。