3月6日にAppleがiPhone/iPod touchのSDKについての戦略を発表するらしい。各種噂系サイトがそのように報じている。さらに、その時点でSDKがリリースされるが正式版ではなく、６月のWWDCで正式版がリリースされるとも言っている。
最初から完全なものが出てくるとは思えないので、たしかにそれはそうなのだろう。Exchangeのクライアント機能であるとか、ビジネス系に振った機能が提供されるといった話も出てきている。
だが、SDKを出すうえで「この要素を盛り込まなかったら意味がない」というポイントがある。
それは、iPhone/iPod touch用のアプリをMac向けにリメークしやすいようにしておく、というものだ。
iPhone/iPod touchのデベロッパーが、そのままMac向けのアプリケーションも最小限の手間でリリースできるようにしておくのだ。iPhone/iPod touchで新たなデベロッパーを引き入れて、それをMac向けアプリの市場に招き入れられればAppleおよびMacユーザーにとってメリットが大きい。
iPhone/iPod touch用アプリもXcode＋Interface Builderの組み合わせで開発するはずなので、たとえばiPhone/iPod touch用アプリ用とは別のNIBファイルを用意するとか、Xcode上で現行のIntel/PPCに加えARM（XScale）向けの３バイナリ版Universalビルドを行うとかでそのまま動くといったレベルが実現されていることが望ましい（ただし、Intel/PPCバイナリ部分はiPhone/iPod touch転送時に分離される）。
そして、この３バイナリビルドは、きたるべきIAベースのiPhone/iPod touchへの移行を容易にするという側面も持っている。iPhone/iPod用プロセッサをARMからIntelプロセッサに移行させるというのは、Appleのタイムテーブルに乗っている話だと見ている。
そうした戦略的な目標にそって考えると、PPCプロセッサまでサポートする必然性というのは無きに等しいことだろう。さらに、IntelおよびARM（Xscale）プロセッサはLittle Endianなので、アーキテクチャが違ってもコンパイルのし直しぐらいでプログラムが動くだろうが、Big EndianのPPC向けの動作検証まで行うというのは大変だ。
iPhone/iPod touch用SDKを用いてビルドする、Mac用も兼ねるUniversal Binaryにおいては、PPCをのぞいた２アーキテクチャ向けビルドということでもいいのかもしれない。
ただし、携帯デバイス向けのOS Xと完全なフルセットコンピュータ向けOSのMac OS Xでは作法に差がある。iPhone/iPod touchでは書類に明示的にファイル名をつけて保存しないとか、そういうあたりの作法の違いについても、なんらかの形で吸収できるようにする必要があるだろう。
iPhone/iPod touch用アプリはiTunes Store上で販売できるようにするのだろうが、Mac用アプリもこのiTunes Storeの流通システムを使えるようになるとよいのだが……そこんところ、やろうと思えばできるだろうし……やってみる価値はありそうなのだが、やらないものだろうか？