M1 Mac miniをメインマシンに変更してはや１か月ぐらい。普段のアプリケーションを利用する使い方では、ほとんどIntel Macと差がないというか、違いが分からない感じで使えています。

M1 Mac上でAppleScriptを動かすとIntel Macの10〜77倍遅いケースがままある（Cocoa Scripting時）ので、高性能マシンに乗り換えた感じはまったくしません。KeynoteとかMail.appとかSafariが速いだけの環境です。AppleScriptでバリバリにプログラムを書いているなら、iMac Proのほうが快適でしょう。Mac Proについては……三角関数の計算を間違える問題マシンとして認識しているので、まったく食指が動きません（価格的に無理ですが）。

ただ、M1 MacはCPUが熱くならないので放熱ファンで風を送らなくてよく、夏でも静かなのは助かります。

＃　macOS 12になって、Cocoa Scripting速度が大幅に改善されたので、（OSのバグや不具合はありますが）自分の使っている範囲では高速で快適です

Frameworkの移行

macOS 10.10以降、AppleScriptからオープンソース系のCocoa Frameworkが呼べるようになって、ほぼObjective-Cのコードを直接呼び出して実行できるようになって大変便利な状態になっています。Swiftで書かれたプログラムもBridging Headerを書けば呼べるらしいのですが、自分はいまひとつです。

Intel Mac環境でビルドして利用していたIntel BinaryのFrameworkを、そのまま呼び出すことはできていません。FrameworkについてはRosetta 2で翻訳されて実行できるという状況にはないので、Universal Binaryビルドを行う必要があるものと認識しています。

FrameworkのUniversalビルド

オープンソースのFrameworkのXcodeプロジェクトをそのまま手元に置いてあったので、Xcode 12でオープンしてビルドして、そのままAppleScriptから呼び出して実行できるものもありました。

「これなら問題なくいけるかも？」

……ある意味Yesともいえるし、Noともいえる状況です。

HTMLReader.frameworkあたりはほぼ何も考えずにUniversal Binaryビルドできました。これがないととても困るので助かります。

Intel MacとM1 Macではハードウェアの構成が違うので、そうしたIntel Macのハードウェアを前提としているものはもう、まるっきり動きません。オーディオ出力先のデバイスを変更するものは、まるっきりダメ。各種センサー類から情報を取得するもの（SMCkit）もダメでした。

macOS内蔵Frameworkでも互換性がないものも

Private Frameworkになりますが、ServerInformation.frameworkの中に入っている各種ハードウェアの名称テキストが、M1 Macについては入っていなかったりで。Intel Macとまるっきり同じ情報が入っているわけではないというのが意外でした。

macOSのバージョン間の違いによる「差」

これはFrameworkまわりの話ではありませんが、M1への移行は最新のmacOSへの移行でもあります。新しいという言葉から「改良されている」「よくなっている」と無条件に思ってしまいがちですが、「なくなっている機能がある」「削られた機能がある」という側面も無視できません。

macOSのバージョンが違えば、その構成ファイルも変わっています。とくに、Menu Extrasの構成が大きく変わっており、身近なところではScript MenuがmacOS 10.14でMenu Extrasから独立した小型アプリケーションに置き換わったりもしています。これがScript Menuだけでなく他のMenu Extrasでも同様の動きが起きており、どんどんその数が減少しています。

Menu Extrasの中の実行ファイルを呼び出しているようなScriptは、M1 MacつまりmacOS 11.x環境に持って行ったときに動かなくなります。ファイルそのものが存在していないので「当然」ではあります。

実行中のMacの製品名を求めるAppleScriptです。もともと、AppleScriptで作成して使用しているアイデアプロセッサ「Kamenoko」で行っている処理なのですが、

M1上で実行すると、製品名は間違えるわ、仕様は合っていないわで散々でした。あ、マシンのアイコンは取ってきていますね。その他のデータはマシン移行をしたときにそのまま前のマシンのデータが残っていたためでしょう。

調べてみると、M1 Macでは従来どおりの製品名データを持っていないようで、Intel Macでは取得できていた製品の名前をわかりやすく記述するデータがありません。各国語にローカライズされていて便利だったのですが。

そこで、M1 MacかどうかのCPUタイプ検出を行い、そのうえで処理を分けることにしました。動作原理上、購入してセットアップしたてのマシンでこのファイルが存在しているかどうか、検証が必要だと思います。

DTKを使うこともなく、M1 Mac登場を横目にずっとIntel Macを使ってきました。ひとつには、買えなかったからという理由ですが、もう１つがWWDCまで待っていた（新ハードが出たら型落ちになってしまう恐怖）からです。

2020年の10月ごろにチーム内でUni Detectorを「作ろう！」という話になって、いろいろ人に見せたりしていましたが、

日本の開発者コミュニティ：バっカじゃねーの？
日本のユーザー：何のために作ってんのかわかんねー

という散々な反応でした。「なんでそこまで言うのか？」という散々な状況。

リリース後は海外を中心に評価していただき、日本国内で石を投げられることもなくなりました。

Uni Detectorはこの移行期に必要なアプリケーションであり、移行が終わった後でもアプリケーション自体を分析/情報収集できるツールとして便利に使えると思っています。

実機がない状況で作ったので（Intel Mac上にmacOS 11Beta環境は用意していましたが）、「仕様から推測するとこんな感じだろう」「もれ伝わっている情報をもとに作るとこんな感じだろう」と予測して作っていたわけです。

Uni DetectorをM1 Macで起動すると……

起動します。これは、Roesetta 2の機能によるものです。起動自体に時間はかかりません。

すべてのアプリケーションをチェックすべく「All」をクリックすると、「最初の違和感」がやってきます。Intel Mac上で動かすのと挙動がぜんぜん違います。最初のSpotlight経由でアプリケーション情報を集めるのにやたらと時間がかかります。「クラッシュしたか？」と思いながら様子を見ると、あっという間にバーが最後まで伸びて、処理が終わっていました。

Spotlight関連で性能が出ないのか、他の方法で情報収集したほうがいいのか……頭が痛いところです。

失敗した！　という点がひとつ。マシンのCPUアーキテクチャの取得です。

これは、Rosetta上で動くIntelバイナリならおそらく「Intel」と判定されてしまうのでしょう。予想し切れるところではありませんが、違和感しかないので修正すべき点でしょう。

→ 予想どおり、Universal（Apple Silicon/Intel 64）ビルドを行ったら、マシンがApple Silicon Macだと認識されました。

事前に予測できなかった点がもうひとつ。OSバージョンの割り振り方です。macOS 10.15の次のmacOS 11シリーズのバージョン番号の振り方が事前にわかりませんでした。最初のバージョンが「11.0」と割り振られたので、その次が「11.1」のパターンと「11.0.1」のパターンの２通りが考えられたわけです。実際には前者でしたが、後者と予想していたので、当てが外れて「現在実行中のOSバージョン」をもとにマークを出す処理に失敗しています。

if aVerStr = "1013" then imgOS13's setHidden:false
if aVerStr = "1014" then imgOS14's setHidden:false
if aVerStr = "1015" then imgOS15's setHidden:false
if (aVerStr = "11") or (aVerStr = "1016") then imgOS16's setHidden:false
if (aVerStr = "12") or (aVerStr = "1017") then imgOS17's setHidden:false
if (aVerStr = "13") or (aVerStr = "1018") then imgOS18's setHidden:false

このあたり、macOS 11以上であればメジャーバージョンのみ返すようにライブラリを書き換え、かつ、Appleがバグを作ってOSバージョンを「10.16」などと返してきても大丈夫なように備えておきました（すごくありがち）。

これで、実行中のマシンのバージョンインジケータについては大丈夫です。

これは「よかった」点ですが、macOS上でiPhone用のアプリが動くことが告知されていたので、どのプラットフォーム向けに作られたアプリかを表示するようにしてあり、これは先見の明がありました（自画自賛）。

とってもやられた、という点もあります。

CPUアーキテクチャ別の円グラフを表示する機能があり、Intel MacでmacOS 10.14/10.15で動かす分には問題なく表示されるのですが、macOS 11のRelease版だとアプリケーションごとクラッシュします。macOS 11の問題（Apple側の問題）だと思いますが、Appleはそういうことをやる会社であり、Appleのせいでこういうトラブルが起こることは日常茶飯事です。たぶん、ソート周りでクラッシュを起こしているんだと思います（ていねいに、グラフ表示する前にソートルーチンで数字の大きい順にデータを並べ替えているので）。

→ クラッシュの原因がわかりました。NSStringのstringWithFormat:メソッドがIntel MacでもApple Silicon MacでもAppleScriptから呼ぶと100%クラッシュします。こんな基礎的なところでバグ作ってどーするんだか、、、（ーー；；

到着してとりあえずのセットアップを行ったM1 Mac mini。とりあえず、ごあいさつの「system info」コマンドの実行。

--> {AppleScript version:"2.7", AppleScript Studio version:"1.5.3", system version:"11.3.1", short user name:"testuser", long user name:"Takaaki Naganoya", user ID:501, user locale:"ja_JP", home directory:alias "Macintosh HD:Users:test1:", boot volume:"Macintosh HD:", computer name:"M1 mini", host name:"m1mini.local", IPv4 address:"192.168.x.xx", primary Ethernet address:"xx:xx:xx:xx:xx:xx", CPU type:"ARM64E", CPU speed:missing value, physical memory:16384}

「ARM64E」と返ってきました。へーー、CPU Typeはそんなかんじなんだ、へー。

CPU Speed、クロックのことですが……missing valueが返ってくるというのは、従来のAPIでは値を取れなくなったのでそのままです、ということなんでしょうか。

これまで、macOS 10.16.0というバージョン番号を返してきたmacOS Big Surが、Beta 4でAppleScript系、shell系、Cocoa系のさまざまなOSバージョン確認方法に対して「11.0」というバージョン番号を返してくるように変更になりました。

ここから先は、正式に11.0として扱うことにします。

ただし、いつものApple仕事なので、いつどのランタイム環境でOSバージョン取得を間違えるかわかったものではありません。OSバージョン取得まわりは今後も継続的に疑いの目で厳しく確認しておく必要のある箇所であると考えます。どうせAppleなので。