Windows Phone「Mango」7.5では、Microsoftのスマートフォン プラットフォームに新しい機能が導入されているが、開発者は、AppleのiOS アプリ開発者が過去4バージョンのAppleモバイルOSで利用してきたのと同じモデルの新機能を利用するために、アプリを単純にアップデートするだけでは不十分だ。
代わりに、マイクロソフトは開発者に対し、アプリの2つの異なるバージョンを配布するよう求めています。既存のスマートフォン向けには既存の7.0バージョン、そしてモバイル通信事業者からアップデートが提供され次第インストールできる新しいスマートフォンやデバイス向けには7.5バージョンです。開発者の皆様には、10月末までに7.5バージョンをアップロードすることが推奨されています。
Windows Phone 開発者ブログには、「平均するとユーザーは 3 ～ 4 か月ごとにアプリを更新していることを考えると、この 10 月の期間によって、現在 7.5 アプリを提出しても、次の更新が必要になるずっと前に 7.0 アプリにアクセスできるようになることが保証されます」と記載されています。
7.5バージョンのアプリがApp Hubマーケットに公開されると、開発者は既存の7.0バージョンにバグ修正や機能追加を行うことができなくなります。また、Windows Phoneの各メジャービルドは対応するアプリバージョンに紐付けられているため、既存のスマートフォンユーザーも新しい7.5バージョンを実行できなくなります。WP7マーケットには、ユーザーが選択できるアプリの種類のリストが表示されます。7.5 Mangoにアップグレードするユーザーには、各アプリの新しいバージョンが利用可能になり次第、ダウンロードするように通知するアップデートが送信されます。
iOS では、Apple は開発者に対し、最新バージョンの iOS がリリースされたらすぐに新機能に対応するよう奨励していますが、それらのアプリの最新バージョンは、最新の iOS にまだアップデートしていない既存の電話機でも引き続き実行できます。iOS 開発者は、アプリを構築するときに複数の OS リリースをターゲットにするだけで、結果として得られるパッケージは、複数のバージョンの iOS だけでなく、iPhone から iPad の大画面に至るまで、さまざまなデバイスで実行できます。
Apple の iOS ユーザーの多くは、iOS App Store の設計のおかげで、「3 ～ 4 か月ごと」よりもはるかに頻繁にアプリをアップデートしています。iOS App Store では、開発者とエンド ユーザーの両方にとってアプリの導入とインストールが簡単になるので、頻繁なアプリ アップデートが奨励されています。
Appleのユニバーサルバイナリ
Appleは長年にわたり、開発者がユニバーサルバイナリで異なる種類のコードをパッケージ化することを許可し、アプリの配布とユーザーにとってのインストール作業を大幅に簡素化してきました。Mac OS Xでは、Appleはユニバーサルバイナリを使用して、開発者がPowerPCとIntelの両方のコードを同じ「アプリ」で提供できるようにしました。これにより、ユーザーは自分のハードウェアの種類に応じてどちらのアプリをインストールする必要があるかを判断する必要がなくなりました。
ユニバーサルバイナリのおかげで、32ビット版から64ビット版Intelアプリへの移行も同様にスムーズに進みました。しかし、Windowsユーザーはそうはいきませんでした。64ビットPCを最大限に活用するには、別途64ビット版Windowsをインストールし、64ビットアプリをインストールする必要があります。
Macでは、ハードドライブの1つのパーティションから32ビットシステムまたは64ビットシステムを起動でき、ユニバーサルバイナリアプリはハードウェアに64ビット機能が搭載されている場合は自動的にその機能を活用します。同様に、iOSアプリはiOS 3、iOS 4、またはiOS 5で実行でき、開発者がiPad向けに最適化されたバイナリをパッケージに追加すれば、iPhoneでの実行にも対応したり、iPadの機能を最大限に活用したりすることも可能です。
この設計により、開発者はApp Store経由でコピーしたデバイス上で「そのまま動作する」アプリを迅速に配布できるようになりました。iOSとMac OS Xのユニバーサルバイナリの基盤は、NeXTのプラットフォーム非依存設計と、Appleが90年代初頭にMacintoshのオリジナル68KプロセッサからPowerPCへのスムーズな移行を可能にするために考案したファットバイナリ技術の組み合わせに由来しており、ユーザーに快適な下位互換性を提供しました。
WP7デバイスを理解する
Microsoft は、ユーザーが自分のデバイスに適したアプリ バージョンを選択することを期待しており、近い将来に開発者向けに改善しようとしている唯一の角度は、最終的には WP7 ストア内で 7.0 と 7.5 エディションの両方のアプリを並行して更新できるようにすることだと述べています。
WP7がユニバーサルバイナリをサポートしていないのは当然のことです。デスクトップ版Windowsも、ユーザー向けに異なる種類の実行ファイルを自動で管理したことがなかったからです。Microsoftが90年代後半にWindows NTで複数のCPUタイプをサポートしていたときでさえ、ユーザーはハードウェアに適したバイナリタイプを入手する必要がありました。
多くの場合、この余分な複雑さと労力により、開発者はさまざまな CPU タイプでアプリケーションを利用できなくなり、Microsoft でさえ、自社の Office または Exchange Server ソフトウェアで代替の Windows NT CPU エディションをサポートしないことを選択しました。
Windowsに「アプリパッケージ」アーキテクチャが存在しないことは、MicrosoftがMacユーザーに馴染みのあるシンプルなインストール機能を提供していないことを意味します。代わりに、Windows 3.0のプログラムマネージャー機能を継承した、手順的にインストールされるアプリのスタートメニューを構築することを選択しました。Windows 8は、合理化されたオプションとMetroタッチ中心のルック＆フィールを備えた再設計されたスタートメニューを継承しています。ただし、アプリのインストールとアンインストールは引き続き必要です。
Appleは、開発者に対し、アプリパッケージをアプリケーションフォルダにコピーするだけのシンプルなドラッグ＆ドロップインストール、または購入したアプリが自動的にコピーされ、iOSのホームページに似たMac OS X Lionの新しいLaunch Pad画面に表示される新しいMac App Storeモデルの利用を推奨しています。iOSデバイスへのアプリのインストールも同様に、特別な操作は必要ありません。ユーザーは必要なアプリを選択するだけで、App Storeがアプリをインストールします。デバイスの種類やOSのバージョンを一致させる必要はありません。
Windows 8でも同様のアプリの断片化
Windows 8 は、レジストリを含むインストール プロセスを通じてデスクトップ アプリをインストールする既存の Windows 7 モデルを継承しており、各アプリは CPU とハードウェアの 32/64 ビット アーキテクチャとペアリングされる必要があります。
しかし、新しいMetroランタイムは、複数のアーキテクチャで実行可能なアプリをパッケージ化しています。ブラウザでレンダリングされるWebページのように、必ずしもCPUネイティブ機能を提供する必要がないためです。そのため、開発者はMetroを活用するためにアプリを一から作り直す必要があり、Microsoft自身も自社のOfficeスイートでこれを実行するかどうかはまだ不透明です。
一方、Photoshop、Word、iTunes、Firefox など、ユーザーが Windows で実行することを想定しているデスクトップ アプリは、現在の 32 ビットまたは 64 ビットの Intel アプリから、タブレットやその他のモバイル性の高いデバイスでのみ実行される可能性のある新しい ARM デスクトップ アプリまで、一連の特定の実行可能ファイル形式で提供される必要があります。
これらの新しいARMアプリは、まだ市場に出回っていないWindows 8ハードウェアでのみ動作するため、開発者は、ARMデスクトップアプリとしてであれ、完全なMetroスタイルアプリとしてであれ、アプリの移植作業を開始する前に様子見の姿勢を取る可能性が高いでしょう。これは、Windows 8タブレットの新規購入者にとって、ジレンマを生み出すことになります。
WP7 スマートフォン ユーザーとアプリ開発者にも同様の待機問題が存在し、同じ問題が Zune ゲームの開発にもつきまといました。Microsoft の Xbox 360 の存在と共通の XNA 開発ツールを考えると、そのような市場の可能性があったにもかかわらず、Zune ゲームも同様に実現しませんでした。
