前回の予告通り、今回からは、Macintosh用アプリケーションの開発で用いるFrameworkをCarbonからCocoaへ乗り換える過程を探求して行きたいと思います。
ところで、単純にCocoa、Objetive-C、Xcode、Interface Builder等の使用方法を解説しているだけでは、それこそ「Cocoa入門」になってしましまいますので、本連載ではCarbonとCocoaでまったく同じアプリケーションを開発する過程を紹介することで、両Frameworkのプログラミングモデルの違いを比較したいと考えています。現在Cocoaを利用している開発者も、将来には異なる開発環境へ移らなければいけない可能性もあるわけで（笑）両者を比較することは、それぞれの利用者にメリットがあると思われます。
さて、皆さんは既にご存じだと思いますが、今年のWWDCの基調講演でLeopard（Mac OS X 10.5）における64Bit化アプリケーションのスライドが表示された時、そこには「64Bit Carbon」の記載がありませんでした。昨年のWWDCではあったので「何が起こったのだ？」と追跡してみると、どうもユーザインターフェース担当のCarbon API（HIViewやWindow Manager等）の64Bit化は行われないというのが事実だそうです。つまり、一度に4GByte以上の大容量メモリを使用するアプリケーションがユーザインターフェースを使う場合には（まあ普通は使いますよね）、CarbonでなくCocoaで開発しなさいと言うことです。
Carbon APIが使えないのは64Bit化アプリケーションに限った話であり、従来の32Bitアプリケーションについては何も問題ありません。しかし、筆者（Carbon使い）には、今すぐ64Bit化しなくてはいけないアプリケーションが幾つかあったので、この発表を見た時は結構ショックでした。とあるセッションでは「これはApple社からのメッセージです」という意味深な発言も飛び出しましたが、これを「Carbonは64Bit化が遅れるのか...」などと良心的に解釈した人は会場に一人もいなかったと思います（笑）。素直に解釈すれば、「Apple社は、そのうちMac OS XのFrameworkをCocoa一本にするぞ！」と言うことを、暗黙の了解としてWWDC参加者に提示したわけです。
しかし現実に目を向ければ、そんなに早急にCarbon APIが全部消えて無くなることはあり得ません。重要なのは「64Bit化されないのはユーザインターフェース担当のAPI」という限定が付いている点です。つまり、Carbonのうち、File Manager、CoreFoundationなど、ユーザインターフェースと直接関わらないAPI群は64Bit化されます。なぜなら、Cocoaの特定クラスにもCarbon APIを利用しているメソッドが多数存在しますし、FinderやiTunesをはじめ、Apple社のアプリケーションでもCarbon Framworkを利用して開発されている物が少なからず存在するからです。よって、たとえCarbonであっても、システム的に必要とされるAPIは64Bit化しておかなければ、Cocoaの完全64Bit化も不可能になるわけです。
Carbonに関しては、Tiger（Mac OS X 10.4）で数多くのCarbon APIが「DEPRECATED」（そのうち無くなる）指定されているという懸念もあります。例えば、QuickDrawのほとんどのAPIは、将来的にMac OS Xから完全抹殺されることが決定されています。しかし、現在のMacintosh用アプリケーションとの互換性を考えると、今まで存在していたAPIをすぐに無くしてしまうことは難しいと考えられます。現に、LeopardにおいてもQuickDraw APIは存在しており、問題なく使用することができます。将来的に開発環境からは外される（ヘッダーファイルが無くなる）ことはあっても、APIが完全に無くなるまでにはもう少し執行猶予が与えられるでしょう。
こう説明すると「当分はCarbonで大丈夫かな？」と思い込みそうですが、実はCarbonの将来には大きな問題点がひとつ存在しています。それは、Mac OS Xの最新機能を使うためのCarbon APIがまったく提供されなくなったことです（32bit版でも）。例えば、WebKit、QTKit、CoreImage、CoreAnimation、といったAPI群がそうです。現状では、CoreImage APIを用いているQuartz Composerや、CoreAnimation APIを使う新ユーザインターフェースのCover FlowやImage BrowserなどはCarbonアプリケーションから直接使うことができません。つまり、Carbonアプリケーションを現状維持で存続させることは容易なのですが、ユーザの目を引く機能を追加した新版を開発したいと考えた時に大きな壁にぶつかるわけです。
実のところ、こうした最新Cocoa API（メソッド）はCarbonからも呼び出すことも可能です。そのため、Apple社からは、CarbonからCocoaのメソッドを呼び出すサンプルソースコードがいくつか提供されています。しかし、CocoaのクラスやメソッドはCocoaプログラミングモデル上で効率的に働くように設計されているので、Carbonプログラミングモデルと混在させることは最善ではありません。また、後々のソースコードメンテナンスを考えても「チャンポン」は避けて通りたい手法です。つまり、将来を考えれば、CarbonからCocoaメソッドを呼び出してお茶を濁すことは避けるべきなのです。
そうは言っても、初めてのプログラミングをObjective-CとCocoaから始められる人は良いのですが、C/C++とCarbonや別のFrameworkで開発作業を行ってきた人にとっての「Cocoa移行」には多数のハードルが存在します。以下に、筆者が思いついたハードルをいくつか列挙してみました。次回からは以下の項目を一つずつ確認しながら、CarbonとCocoaの両アプリケーションを同時に開発して行きたいと思います。
（1）Objective-Cという言語の習得
（2）Cocoaのクラスとメソッドの習得
（3）Cocoaプログラミングモデルの習得
（4）Interface Builderに依存した開発工程の習得
（5）nibファイルのコンバート作業
（6）リソースファイルからの脱却
（7）ローカライズ手法の習得
（8）自作Frameworkの再構築作業
（9）クロスプラットフォームへの対応処理
ところで、Carbonにも同様に最新APIが用意されれば、既存のCarbon開発者（メーカ）がCocoaへ移行する確率は低くなります（私も移行しないと思う）。既存の開発者に対してCocoaへの移行を促したいApple社は「Mac OS Xの最新機能を使いたければ開発をCocoaとObjective-Cへ移行しなさい！」という姑息な手を使ってきたわけです（笑）。64Bit化の中止についても、そうした作戦のひとつでしょう。まあ、Apple社の気持ちは分からないでもありませんし、iPhoneがらみを考えればCocoaへの移行は必要かもしれません。Apple社は「移行する開発者側の労力」をどうも軽く見ている感じがします。実際には大仕事が沢山あるんですけどね（やれやれ）。
筆者は、WWDCでCocoaセッションも聞きたいので直前にその勉強をするのですが、仕事ではまったく使わないため、1年後にすっかり内容を忘れてしまいます。そしてまたWWDCの直前に勉強...そして忘却、そんな事を5年ぐらい繰り返してきました（笑）。Objective-CやCocoaプログラミングモデルの用語はある程度理解しており、簡単なサンプル（Xcodeの雛形程度）上でオブジェクト間のOutletやActionを線で結んだことはありますが、ちゃんとしたCocoaアプリケーションを開発したことは一度もありません。
今回の連載で開発しようと考えているアプリケーションは、MOSA Exchangeにも登録されている「しんぶんし v2.1」（対称写真ユーティリティ）の新バージョンです。はてさて、いったいどうなるでしょうか（笑）。