iPhone OS 4.0のベータ版と対応する開発ツールがiPhone開発者向けにリリースされたことを受け、新たな開発者ライセンス契約が締結されました。Daring FireballのJohn Gruber氏は、この契約のセクション3.3.1に大幅な変更が加えられていることに気づきました。当初、この条項ではプライベートフレームワーク（アプリケーションプログラミングインターフェース（API））の使用が禁止され、Appleが承認していない方法でドキュメント化されたパブリックAPIを使用することが推奨されていませんでした。しかし、変更後の条項は以下のとおりです。
3.3.1 — アプリケーションは、Appleが規定する方法でのみ文書化されたAPIを使用できます。プライベートAPIを使用または呼び出してはなりません。アプリケーションは、iPhone OS WebKitエンジンで実行されるObjective-C、C、C++、またはJavaScriptで記述されている必要があります。また、C、C++、およびObjective-Cで記述されたコードのみが、文書化されたAPIに対してコンパイルおよび直接リンクできます（例：中間翻訳、互換性レイヤー、またはツールを介して文書化されたAPIにリンクするアプリケーションは禁止されています）。 [新しいテキストを強調表示]
この変更により、Apple は契約を改正し、App Store で承認されるソフトウェアは、Apple が承認した厳選されたプログラミング言語のいずれかで作成する必要があり、そのすべてが Xcode 開発ツールでサポートされているようになりました。
これは、近々登場するAdobe Flash CS5に照準を合わせているようだ。Flash CS5のFlash Packager for iPhoneは、開発者がFlashでアプリケーションを作成し、iPhone OSで使用できるようにビルドできることを約束していた。
これはFlash CS5の単なる機能ではなく、まさに旗艦機能でした。Adobeにとって、幅広い顧客が極めて成功したプラットフォーム上でコンテンツを作成できるようにするための足掛かりとなるものでした。もしFlashが実際にXcodeのように軽快でレスポンシブなアプリを開発できると仮定すれば、iPhoneソフトウェアやその他のプラットフォーム向けのクロスプラットフォーム開発環境へとFlashを変革する上で大きな役割を果たしたはずです。
しかし、3.3.1の新しい規約は、広範囲にわたる複雑な問題を引き起こす可能性があります。低レベルのアセンブリ言語でしか実現できない極めて微細なパフォーマンス調整も、もはや不可能になりそうです。また、C#やSchemeといった他の言語も危機に瀕しており、Unityのようなクロスプラットフォーム環境の将来も不透明です。（Unity TechnologiesのCEO、David Helgason氏は声明の中で、同社はAppleと良好な関係を築いており、Appleの状況に変化の兆しは見られないと述べています。）
Appleの開発者契約では、開発者はAppleのソフトウェアと見た目も操作性も似た高品質なアプリケーションを開発することが義務付けられています。AppleはiPadが他のタブレットと同じような見た目になることや、iPhoneが他のスマートフォンと同じような見た目になることを望んでいません。そして、サードパーティ製のソフトウェアやツールのせいで自社製品のパフォーマンスが低下していると顧客に思わせることも決して望んでいません。
AppleがiPhone OSでFlashをサポートしていないにもかかわらず、AdobeがFlash Packagerの開発を進めるという決定をしていなければ、このような事態には至らなかっただろう。Appleはハードウェア、最も重要なソフトウェア、そしてストアを所有している。いずれにせよ、あらゆるソフトウェア企業はプラットフォームの気まぐれに従わざるを得ないのだ。
ここで疑問が湧きます。Adobe は、この結果が別の形で現れることを予想していたのでしょうか? メディア界の巨人 Condé Nast ですら、事態の重大さを予見していました。同社は iPad 向けに Wired の Flash Packager バージョンを開発していましたが、Apple と Adobe の間に明らかな摩擦があったため、Apple の手法も取り入れたバージョンを開発するという、リスク回避策を講じたのです。
Adobeはツール企業であるため、プラットフォームを尊重すべきです。ところが、Appleの利益に反する行動を取ったのです。良くも悪くも、AppleはiPhoneからFlashを完全に締め出したように見えます。その結果、開発者はXcodeやHTML5に代わる現実的な選択肢を、非常に長い間見出せないかもしれません。
