前回はアップルのOSとCPUの変遷について紹介した。今回は、噂どおりにARMベースのCPUを採用したMacが登場したら、各方面にどのようなインパクトをもたらすのかを考えてみる。各方面というのは、アップル自身、サードパーティのデベロッパー、そして一般のユーザーのことだ。それぞれ、どのような影響を受け、どう対処することが可能なのか。それによって何がもたらされるのかといったことを考えてみよう。
アップルはXcodeをアップデートするだけ？
ここで考えるのは、主にソフトウェアに関してだ。つまり、実際にARM搭載のMacのハードウェアを設計して製造する部門のことは考えない。そういうMacが登場したときに、macOSや純正アプリの開発、サードパーティのデベロッパー向け開発ツールを担当しているチームには、どのような対応が必要となるのか。
言うまでもなくまず最初に必要なのは、macOS用としては新たなCPUとなるARM用のソフトウェア開発環境を用意することだ。これは、macOSそのもの、純正アプリ、サードパーティ製アプリといった、あらゆるソフトウェアの開発に不可欠な要素となる。逆に言えば、それさえ完璧に整えば、ほかのことは2次的な問題となる。そして、これはそれほど大きな労力を要する仕事ではないだろう。
現在の技術をもってすれば、ほとんど「設定の変更」程度の労力で済んでしまうはずと言ってしまっても、それほど誇張した表現ではないだろう。アップルが自社製の統合開発環境であるXcodeに採用しているClang/LLVMコンパイラーは、言語にもターゲットにも依存しないことがウリのユニバーサルなソフトウェアビルド環境を実現するもの。現に、インテル製CPUを採用するMac用も、ARMコアのCPUを採用するiOS、iPadOS、その他のデバイス用のソフトウェア開発も、1種類の開発ツールで賄えている。もちろん、対象OSによって利用可能なフレームワークやAPIには違いはあるものの、本質的な部分はもうだいぶ前から共通化されているのだ。
つまり、さまざまなOSに対して、さまざま言語を利用して、さまざまなCPUを採用したデバイス用のアプリを作成する環境はすでに整っている。あとは、それらの可能な組み合わせを調整するだけでいい。とはいえ、Macというプラットフォームの連続性を考えたとき、インテル製CPUからARMコアのCPUにスムーズに移行できるかどうかには、そうしたアプリ開発環境を準備することとは別の問題も絡んでくる。
ソフトウェア互換性維持のための2つの方策
スムーズな移行のために考慮すべきことは、大きく2つ考えられる。1１つは、これからリリースされるアプリを、すでに市場に出回っていて、まだ当分使用されるインテル環境と、新しいARM環境の両方で動作させること。もう1つは、すでにインテル環境用にリリース済のアプリを、ARM環境でも動作するようにすることだ。
まず、今後登場するアプリを両方のCPU環境で動作可能にするのは、実はそれほど難しくない。古くは、Mac OSが68K（68系）のCPUからPowerPCに移行する際に取った方法が利用できる。当時は、「ファットバイナリ」（Fat Binary）と呼ばれたものだが、1つのアプリのパッケージの中に、68KとPowerPC、2種類のオブジェクトコードを共存させる方法だ。画像や音声といったリソースは共通化して1種類で済ますことができるので、アプリは思ったほど大きくならない。
実は現在、macOSだけでなくiOS用のアプリも、そのような仕組みを最初から実現している。それはファットバイナリをもっと一般化した「マルチアーキテクチャバイナリ」と呼ばれる方式を実現したMach-Oと呼ばれるフォーマットによるもの。Mac OS Xの基になったNextSTEPに由来するフォーマットだ。NextSTEPは、さまざまなプラットフォームをサポートできることがウリの1つだったため、そのようなオブジェクトフォーマットを標準的に採用していた。
それを受け継いだmacOSも、そしてiOS、iPadOSも、最初からマルチアーキテクチャに対応している。Mac OS XがPowerPCからインテルに移行する際にも、32ビットから64ビットに移行する際にも、ユニバーサルバイナリという名前で利用された。もしARM搭載Macが登場すれば、今後のmacOS用のアプリには、同じようにしてインテル用とARM用のオブジェクトコードが混在することになるだろう。
もう1つの方策も、すでにアップルとしては実績がある。新しいCPUで旧CPU用にビルドされたオブジェクトコードをそのまま実行できるように、一種のエミュレーター環境を用意することだ。これは、旧Mac OS時代に68KからPowerPCに移行する際にも、Mac OS X時代になってからPowerPCからインテルに移行する際にも実際に利用された方策だ。後者が、古代エジプトのヒエログリフ解読を可能にしたRosetta Stone（ロゼッタストーン）にちなんで、Rosettaと呼ばれていたのは、まだ記憶に新しい。
もちろん、現在の技術によれば、オブジェクトコードに含まれる命令を、逐一エミュレーターによって変換しながら実行するようなものではなく、アプリのロード時に一種のトランスコーダーのようなものを動作させ、まとめて変換することも可能だろう。そのタイミングなら、変換自体がネックになることもないし、あとはネイティブのコードとそれほど大差ない速度で実行できるようになる。
折しも、米アップルが「Apple Rosetta」という商標を日本の特許庁に出願したというニュースも流れてきた。これは、インテル用のコードで書かれたアプリをARM上で実行できるようにする仕組みに関わるものである可能性が高いように思われる。「Rosetta」だけでは、商標として成立しないので、以前は登録なしで愛称として使っていたものを、今回はApple Rosettaとして正式に商標登録しようというのではないだろうか。
さらにもう1歩進んで、Mac上でiOSや、少なくともiPadOS用のアプリを実行可能にする機能も含むものではないかという期待も膨らんでくる。例えば、現在のmacOS Catalinaでは廃止されたDashboardのような環境を復活させ、そこでiPadOS用のアプリを動かすことはもはやCPUの相違があったとしても、それほど難しいことではないような気さえしてくるのだ。
デベロッパーやユーザーは特に何もすることがない？
サードパーティのデベロッパーとしては、今後macOS用のアプリを開発する場合、特にCPUが何であるかは意識する必要がないだろう。現在も、特にインテルCPUを意識して開発しているのではないのと同じことだ。もし、将来すべてのMacが完全にARMに移行するとしたら、その移行期間だけは両方のCPUに対応したマルチアーキテクチャバイナリのアプリをリリースし、何年か後に移行が完了したら、ARM専用のアプリに切り替えればいい。それらは、ほとんどXcode上でアプリをビルドする際のスイッチの設定だけで選択可能となるだろう。もし将来のMac環境でも複数のCPUが混在するなら、ずっとマルチアーキテクチャを使い続けるだけだ。
すでにARMに移行するかどうかという話が出る前から、macOS用のアプリ開発では、Mac Catalystが利用できるようになっている。これは、iPad用アプリを、かなり簡単にmacOS用に移植することを可能にする環境だ。現在は、異なるOS用の、それぞれ独立したアプリとしてリリースすることになるが、もしMacがARM化すれば、1種類のアプリが、そのまま両方のOS上で利用できるようになるかもしれない。さらに、Apple Rosettaが上で述べたような期待通りのものであれば、iPadOSアプリが、インテルCPUを搭載したMacで当たり前のように動作することも夢ではないだろう。
こうして、一般的なアプリのデベロッパーは、特にCPUの変更を意識することなく、アプリの開発とリリースが可能になるものと思われる。ただし、例えばWindows用のアプリやWindowsそのものをMac上で動作可能にする仮想環境を提供しているデベロッパーにとっては話はそう簡単ではない。ここでは詳しく考察しないが、そうしたデベロッパーもおそらく何らかの方法で対応策を打ち出してくれるだろう。それほど遠くないうちに、ARM搭載Mac上でも、どういう形かは別として、Windowsが利用できるようになることに期待したい。
これまでに述べたことが期待どおりに進めば、一般のユーザーは、自分のMacにどんなCPUが搭載されているかに関わらず、Mac用のあらゆるソフトウェア、周辺機器が利用できるようになるはずだ。もしそうならなければ、インテルからARMへの移行は、ユーザーに何らかの不便や妥協を強いることになる。それでは、ARMへの移行は完全な成功とは言えないのではないだろうか。
関連記事：CPUの変遷から見るアップルOSの歴史
