macOS 12 beta9が出てきています。もう、リリース間近というより大した問題がなければbeta 8でリリースしていたのでしょう。

AppleScript系では、Cocoa Scriptingの処理速度の低下は観測されていません。Beta 5以降はほぼ誤差の範囲内の変化しかありません。これはいいことです。

あいかわらず、日本語環境でNSDataDetectorで自然言語テキストからの電話番号の抽出に失敗します。これは、少し不幸なことですが、修正されることを期待したいところです。

ここ最近のmacOSのβ版の出来・不出来

macOS 12 beta 7が出てきました。macOSのリリースはiOS/iPadOSの後にリリースされるのが通例（というか、技術的にそうしないと無理）で、β番号から見て割とβ版の末期にあるものと推測されます。

例年だと、８月の終わりのmacOSの出来でRelease時の品質が推し図れています（農作物みたいだ）。

macOS 10.13：Beta中はとても好感触　→ Release版で大事故（前代未聞の大惨事。macOS Vistaと呼ばれる）
macOS 10.14：Beta中、バグが多くて使う気になれず　→ 最終版（macOS 10.14.6）まで様子見
macOS 10.15：Beta中、８月末に大事故。開発者がそろって「こいつは新たなmacOS 10.13だ」として見放す。８月中にmacOS Vista 2のあだ名が確定
macOS 11：Beta中の印象は好感触（Intel Mac）。だが、Release後にM1 Macハードウェアがらみの未知の問題点が多数報告される

というのが、ここ最近のmacOSのリリースの流れです。

macOS 10.13、10.15と「奇数番号は地雷」という状態で、この命名法則でいえば「10.17」にあたるmacOS 12は、不吉な予感を抱かせるものでした。

Cocoa ScriptingなどAppleScript系の処理速度の回復と向上

自分はmacOS 10.15を全力で見送り、macOS 10.14.6をメイン環境にすえました。通例、新たなmacOSがリリースされるとScript環境まわりの評価記事を書きますが、10.15ははじめて評価記事をボイコットしたほどひどいものでした。

「10.15がひどい」という中には、「①本当にバグや不具合のもの」「②勝手に仕様変更して周知しなかったもの」「③OS全体のセキュリティ強化にともない、結果として機能不全になったもの」など多々あります。

その後、M1 Mac mini導入にともないmacOS 11に環境を移しました。M1 Mac mini＋macOS 11は、世間の評判もよく、安住の地となるはずでした。

ところが！　M1 Mac miniを開封して１時間もたたずに血の気がひきます。Cocoa Scriptingを多用している現代のAppleScriptを走らせると、2012年のMacBook Pro Retina 2012よりも10倍ぐらい遅かったからです。

調べてみると、macOS 10.15の時代からCocoa呼び出しで大幅なスピード低下が発生しており、その延長線にあるmacOS 11も同様の現象が発生。

さらに、M1に搭載されたCPUコアのうち、高性能コアではなく省エネコア（Ice Storm）を使用してAppleScriptが実行されているようで、2011年のMacBook Airよりも数倍M1 Mac miniが遅い処理が出てくる状況でした。

そこで、Shane Stanleyと相談してAppleに詳細なレポートを提出し、「おまえんとこの最新鋭機種は10年前のへっぽこマシンよりはるかに遅いぞ、どうしてくれる？」という報告をしたわけです。もちろん、M1 Mac mini購入後のアンケートでは「10年前のIntel Macの10倍も遅い。不満」と答えています。

運よく、レポートが功を奏してM1がらみの速度低下問題はmacOS 12beta 5で解決。同時にmacOS 10.15から発生していたCocoa呼び出しの速度低下問題も解決（たぶん）。このことで、Intel Macでも、速度低下発生前のmacOS 10.14より高速な処理が行えるようになったほどでした（もちろん、macOS 10.15や11よりも高速です）。

この問題の検証のため、手元のアップデート可能なMacは２台ともmacOS 12に上げてしまい、先日リリースされたmacOS 11.6においてパフォーマンス低下問題がフィードバックされたのかどうかは検証できません。

高速だが小バグが直っていないmacOS 12beta7

さて、macOS 12beta7ですが、ベンチマークを実施したところBeta 5、6と同様にCocoa Scriptingの速度は維持されています。Beta5よりも速くなった処理がある一方で、若干速度低下した項目も見られますが、誤差の範囲内でしょう。

▲同一ハードウェアでOSのアップデートにともない、速度低下が解消され、高速化

▲約700箇所の位置情報と8,000箇所の駅の位置情報との間での最短距離計算。macOS 11＋M1 Macでは１時間かかって気を失いかけたが、いまではiMac Proより2.5倍高速の異次元の速さを実現。これなら、ScripterにもApple Silicon Macをおすすめできます

一方で、日本語環境でのみ発生しているNSStringからのData Detectorによる電話番号ピックアップができないバグは直っていません。GUI部品のお守りよりもデータ処理を行うことが多いAppleScript界隈としては「無視できない問題」です。

Release版では直ってほしいですよね＞誰となく

また、macOS 11で確認された特定ハードウェア（Mac Pro 2019）で関数計算を間違えるバグについては、当該機種を所有していないため、自分には追跡調査は行えていません。

macOS 12 beta6が出てきました。beta 5でM1 Mac上でのAppleScript実行速度低下が大幅に改善され、そのアップデート版であるbeta 6で「先祖返り」していないかを確認。beta 5と同程度か、少し高速になっている処理もあるようです（気持ち速いぐらい）。

でも油断はできません。macOS史上最悪最低のmacOS 10.13のときには、Release前には何も問題がなく順調にバグがつぶされてきたのに、Release版はBeta以下という出来でした。

あのmacOS 10.13の開発プロジェクトを思えば、Release版を見るまで結論は出せません。

追記１：
Beta 6に、NSDataDetector経由で電話番号を取得できないというバグを見つけました（レポート済み）。プログラミング言語ではなく、ユーザー環境の設定言語に依存して発生するようです。いまのところ、日本語環境で問題が発生し、英語環境では発生していません。

以前から本Blogでは、M1 Mac＋macOS 11上でAppleScriptの実行、とくにCocoaの機能呼び出しが10〜77倍遅くなるという件についてレポートしてきました。

–> macOS 11, AppleScriptをFirestormではなくIcestormで実行か？！

CPUの乗り換え直後ということもあり、淡々とAppleにバグレポートしつつ、周囲には「まだM1に手を出すべきではない」と話していたものが、最新のmacOS 12 beta 5においてどの程度変わったのでしょうか？

２つのスピード低下問題

AppleScriptのコミュニティ的には「macOS 10.15をインストールするとCocoa Scriptingが遅くなる問題」（Intel Mac）があり、そのうえに「M1でAppleScriptの実行＋Cocoa Scriptingが遅くなる問題」の２つの問題を抱えていました。

macOS 10.15以降の速度低下問題は、自分がmacOS 10.15を「ダメ環境」としてパスし、M1 Macの導入にともないOSバージョンを１つ飛ばしてmacOS 11に移行したときにはじめて認識しました。

Mac App Storeに出している、AppleScriptで組んだアプリケーションの数々が、さぞやM1 Mac上で処理速度が向上して、より快適に使えるに違いない……と、ルンルンで箱を開けてテストをしだして、「遅い！！ MacBook Pro Retina 2012より遅いとはどういうこと？！」と、落胆の表情に変わるまで１日も必要ありませんでした。

とくに期待していた時間のかかる大規模データ処理が、MacBook Pro Retina 2012の10倍以上遅いという結果に言葉を失い、Appleにこれを「バグレポート」としてレポートすることになったのです。

メール.appの起動やSafariの操作など、日常的な操作の範囲では噂どおりの処理性能を発揮していたのに、AppleScriptの処理だけ遅いというのは、これはもう明らかに「異常事態」です。

ベンチマーク比較対象

身の回りにあるMacをかき集めて調べてみました。現用機でこのベンチマークに参加していないのは奥方様のMacBook Air 2015ぐらいです。

今回、青い色で指し示しているmacOS 12 beta 5環境が注目点です。M1 Mac miniおよびIntel Mac mini 2014にmacOS 12 beta 5をインストールし、速度の変化を検証しました。

結論から言うと、macOS 12 beta 5ではM1 MacでmacOS 11.xの30倍、Intel Macで10倍ぐらいCocoa Scriptingの実行が高速になっています。

これは、冒頭で説明した（１）macOS 10.15で発生した何らかの内部的なミス　（２）M1 Mac上でAppleScriptの処理系が明らかにIcestorm（電力効率のよいローパワーCPUコア）で処理されてしまっていたこと　の２つの問題が解消されたため、と推測しています。

これらの組み合わせによって、Intel MacでもM1 Macでも処理速度が大幅に向上した、という「現象」のみが確認できているだけです。

ベンチマーク１：Permutation

DNAの塩基配列「T」「C」「G」「A」のすべての順列組み合わせパターンを計算する計算（Permutation）です。桁数が多くなるとデータ量と計算量が膨大に増えるのと、Cocoa Scripting導入の有用性を示す演算内容（Vanilla AppleScriptより桁違いに高速）でもあるため、４〜８桁のPermutationを採用しました。以下、グラフ内の横軸の単位はすべて「秒」です。

Machine 4が前の開発環境（MacBook Pro Retina 2012）で、これを基準に「速い」「遅い」という比較を行っています。

アップデート前のM1 Mac mini＋macOS 11の環境はMachine 4よりもはるかに遅くて「使っていられない」状態でしたが、アップデート後の環境（Machine 1’）ではMachine 4の２倍強、アップデート前からは平均で27倍の速度向上を実現。

Intel MacでもmacOS 11から12への移行で11〜21倍程度、高速化しています。

ベンチマーク２：乱数配列の生成とソーティング

M1＋macOS 11の環境では「要素数の多い配列の操作」と「乱数の生成」（AppleScriptのrandom number）がとくに遅いという傾向が出ていたので、10万要素、20万要素、30万要素の配列でベンチマークを行いました。ただし、本ベンチマークでは乱数の生成を最速の方法で計算しているため、M1 Macで1.3倍速、Intel Macでも同程度の速度向上になっています。とくに、要素数が少ないほど速度向上の割合が増えており、これは歓迎できる傾向です。

ベンチマーク３：AppleScriptのrandom number関数を用いた乱数配列の生成とソーティング

AppleScriptのrandom number関数を用いて1〜99999999の範囲の乱数を1万回生成して配列に追加するベンチマークです。初回実施時にはこれでM1 Mac mini＋macOS 11の環境が、MacBook Air 2011＋macOS 10.13の５倍の処理時間がかかるという衝撃の数値が出た内容です。

macOS 11から12 beta 5へのアップデートに伴い、M1 Macで30倍、Intel Macでも12倍速度が向上していることを確認しています。

macOS 11の正式版がmacOS 12？

どこまでも「次世代Apple Silicon Mac用OSのβ版」という印象が強かったmacOS 11から、AppleScript＋Cocoa呼び出しについては機能の改善が行われ、macOS 10.15で失った処理速度をIntel Macでも回復できているように見えます。

自分が大規模データ処理＋演算速度の目安に用いている、「約700箇所の日本全国のゲームセンターについて、全国の鉄道駅（約8,000箇所）との距離を求め最短のものを最寄駅とし、それぞれ最寄駅までの距離が短い順にソートする」計算の結果を見てみると、

MacBook Pro Retina 2012：７分13秒
iMac Pro：４分17秒
M1 Mac mini：１分42秒

と、iMac Proを大きく上回る結果を叩き出しています。あまりに速いので、計算内容が間違っているのではないか？　とか、計算結果が出力されないのではないか？？　などと疑問に思って何度も調べてみましたが、きちんと計算されています。間違いなく、これまでに遭遇したMacの中で最も高速にAppleScriptを実行する環境といえます。この速さは、異次元のレベルです（力説）。

正直なところ、Cocoa Scripting Course本掲載のサンプルAppleScriptをM1 Mac mini＋macOS 11で動かしたときには「イヤな汗」が出まくりました。高速なCocoa Scriptingだぜキャッホー（奇声）！　などとノリノリで書いていたものが、

「残念なお知らせです。いま、Vanilla ScriptingのソートルーチンにCocoa Scriptingのソートルーチンが抜かされました」

などと書けるでしょうか？　いや、書けるわけがない（反語）。本件は、Cocoa Scripting本の続刊を書く手が止まってしまうぐらいの（よくない方向への）インパクトがありました。

かくして、そこから詳細な調査や問題傾向の炙り出しなど、表沙汰にできない調査と資料作成がはじまったわけで、一応こういう形で（いい方向に）問題が解決されて本当によかったデス。これで解決されなかったら、海外のYouTuberにチクリまくってセンセーショナルな方向で炎上させるしかない、と割と本気で思っていたほどでした。だいたい、自分にしかレポートできないのに、時間と何かを失って何も得られない膨大な作業。Appleが自分でチェックする能力がない一方で、この無償奉仕労働を強いられるのが納得できません。

macOS 12については期待が持てる内容ですが、これがいまだ現用環境であるmacOS 10.15やmacOS 11へのフィードバックが可能な内容なのか、あるいはmacOS 12の登場を待たなくてはならないのかは現時点ではわかりません。

ただ、ここ数年というもの（2020年は珍しい例外）、このぐらいの時期（８月後半）になると「またAppleの現場が無茶な仕様追加を行って開発プロジェクトが崩壊した」「Release版のひどさがいまから感じられるので、アップデート禁止」といった話題しか出ていませんでした。それが、「macOS 12には期待できる」という話ができるのは、喜ばしいことでしょう。

＃　Beta版では素晴らしかったのに、Release版で別物が壊滅的な出来でリリースされた「macOS 10.13」という悪しき前例があるので、Betaがよくても安心できない今日このごろです。「どうして10.13がああなったのか」という説明は一切ないままなので、いまひとつ信頼できません

Mac App Storeに出している各種アプリケーション（すべてAppleScriptで記述）の動作が、macOS 12 beta5上であればひじょうに高速です。

UNI detector+macOS 12 beta5 DEMO

Watch kamenoko_M1+macOS 11 DEMO

Watch Kamenoko_M1_macOS 12 beta5 DEMO

FileMaker Proに組み込んで大規模なCocoaの機能を呼び出しているAppleScriptの動作も快適になっています。

Watch M1+macOS11 MkMapView Demo

Watch M1+macOS12 beta5 MkMapView Demo

CotEditorと組み合わせて動かしている「CotEditor PowerPack v3」のAppleScriptも、macOS 12beta 5上できわめて高速に動く様子がわかります。

Watch CotEditor_M1＋macOS11 DEMO

Watch CotEditor_M1＋macOS12 beta5 DEMO

Numbers.appで選択中の範囲のセルをシャッフルするAppleScriptをmacOS 12beta5で動かしたもので、左がIntel Mac mini 2014、右がM1 Mac mini 2020です。
numbers_selection_shuffle_intel_M1_12beta5

これはAppleScriptに関する処理だけにとどまるものではないようです。Terminal.app上で動作させる各種CLI系のプログラムの動作時のCPU Coreの割り当ても変化しており、よりパフォーマンスを発揮する方向に「味付け」が変化しているように見えます。

ただ、CLIベースのプログラムについてまとまったベンチマークを行なっているわけではないため、実際に動作させている数少ない膨大な処理時間のかかるプログラム（PDF内の画像サイズ圧縮のために併用しているGhostScript）を見ている範囲で、アクティビティモニタ上のCPU各コアの動きが変わっているように見える、ということです。

ついにmacOS 11.0, Big Surが正式リリースされました。これほどリリースが待ち遠しく、リリースを恐れていたOSバージョンもありません。機能的にはいいのに、見た目がアレな、ある意味「次世代のmacOSのPublic Beta」みたいな位置付けです。バージョン0.xから始まるのも初めてですし。1.0未満だと受け取っておきましょう。

→ その後、マイナーアップデート版が「11.1」であることが判明し、今後は「12.x」「13.x」とiOSライクなナンバリングが施されることがうかがわれます。

ハードウェア面では「M1搭載のファンレスのMacBook AirがCore i9のCPUを蹂躙する図」が展開されているなど絶好調ですが、ソフトウェア面ではいろいろ（見た目に）問題があります。

macOS 11.0.1について、AppleScript的には大きな違いはありません。大きな違いというのは、macOS 10.15からの大きな違いということです。10.15のあまりの不具合の多さに、β段階で「毒の沼」認定してメイン環境で利用することを放棄したため、個人的には11.0にすぐ移行したいところです（検証用のMac mini 2014しか対応ハードウェアがない問題）。

macOS 11.0搭載のAppleScriptはあいかわらずバージョン2.7。スクリプトエディタもビルドが少し変わったぐらいでバージョンは同じです。

スクリプトエディタのヘルプが、macOS 10.13、10.14、10.15と毎回更新されていましたが、今回はその余裕がなかったのか10.15, Catalinaのままです（あとでオンライン更新されるのかも？？？）。

毎回、OSのアップデートがあるたびに書き換えの必要があるScriptが出てきます。すべてのScriptが必要というわけではないはずですが、理由は大きく分けると以下のとおりです。

（１）Script専用補助アプリケーションやOS標準装備のアプリケーションの機能に変化が生じたり、名前が変わったり、統廃合されたりした
（２）AppleScriptの言語処理系、標準装備のScripting Additionsや標準命令に新たなバグが発生した
（３）OS自体の仕様変更、未知のバグが発生した
（４）GUI ScriptingでメニューなどのGUI部品を指定している箇所が、GUI修正などの理由によりそのままでは動かなくなった
（５）Cocoaの仕様変更により動かなくなったり修正が必要になった

スクリプトエディタのsdefの差分をチェックしてみたところ、macOS 10.14/10.15から変化はありません。つまり、今回は（１）（２）由来の発生の可能性は低いことが期待されます。（４）は当然そうなるものなので（些細な変更で発生するものなので）、必要最低限の箇所に使うべきものです。（５）は、Cocoa自体の仕様変更は割とひんぱんに発生しているので、なんともいえませんが、Cocoa自体に仕様変更やバグがなくてもScripting Bridge定義ファイルのバグや理不尽な変更（主にmacOS 10.13で発生した件。一切説明なし）によって影響を受ける可能性はあります。

カレンダー.appのバンドル内に同梱された大量のAppleScriptもβ時からそのままです。

（何か発見があったら追記）

アプレットのプロパティが保持されない件：理由＝（３）

LateNight Software Blogに掲載された「BIG SUR: LOST PROPERTIES」をGoogle翻訳で読んでみました（ちょっと時間がないので）。

macOS 11.0, Big SurではスクリプトエディタでAppleScriptアプレット書き出しを行うと、

Arm 64/Intel 64のUniversal Binaryで書き出されます。

そして、アプレット書き出し時にCode Signが自動的に行われ（Run Localy）、Apple Developer IDを持っていなくても実行バイナリにCode Signされることになります（Notalizationはまた別）Code Signされるということは、アプレットの情報書き換えが保持されなくなるということであり、property文で設定値を維持しようとしても、実行ごとに内容がフラッシュされる（保持されない）ことになります。

このことはmacOS 10.10ごろから「そういう風になるんだろう」とわかっていたので、property文で設定値を保持するような書き方は一切してきませんでした。設定保存の必要があればUser Defaultsへ書き込み。

サードパーティのOSAX（Scripting Additions）が廃止されることはOS X 10.6の頃からわかっていましたし、OS X 10.10の頃からpropertyで値を保持してはいけないことはわかっていました。

AppleScript Studioランタイムがdeprecated扱いに：理由＝（３）（５）

最新の「兆し」は、PowerPC→Intel→Apple Siliconと３世代にわたってメンテナンスされてきた「AppleScript Studioランタイム」（Automatorアクションでこれを使っているものがある）が、いよいよdeprecated扱いになったことです。

もともと、OS X 10.6のときにXcode上から開発用のテンプレートが削除されたためにAutomator Action作成時に積極的にAppleScript Studioの機能を使おうとも思わないのですが、これまで維持され続けてきたというわけです。あれだけの規模のものを、OSのGUI部品が変更され続けていく中メンテナンスしてARM対応まで行なって破棄するとは……自分がその仕事に携わっているならやり切れないものがありますが、既定路線ではあります。

今後、macOS上で実行できるAutomator ActionはAppleScriptObjCベースのものに一本化される、ということです。

ファイル共有のプロトコルがsmbに一本化：理由＝（３）

この話が出てきたのが何回目だか覚えていませんが、ファイル共有のプロトコル「afp」が使えないようになりました。「smb」のみです。

LAN上の他のマシンやファイルサーバー、NASのボリウムをマウントする処理は割とありふれたものですが、そのためのサーバーの指定方式がsmbに一本化されたという「変化」があったということです。

ファイルサーバーのマウント処理を記述してあるScriptについては、macOS 11.x以降では書き換えの必要があります。

AppleScript書類（.scpt）アイコンがプレーンテキストを示すアイコンに変更：理由＝（３）

なんなんでしょうね？　これは、、、ミスなのか、意図があるのか。

System Eventsの機能変更：理由＝（２）

これだけ機能が変わっていたらバージョン番号を変更してほしいところです。
→ 同じバージョン番号のまま大幅に機能が変更されたSystem Events

System Eventsの動作状態の変更：理由＝（３）

OSが起動して他のGUIアプリケーションを操作可能な状態になって久しい状態だというのに、System Eventsに対する操作を行おうとしたら、プロセスが起動していないといったエラーが表示されました（macOS 11.3 beta3）。

launchコマンドでSystem Eventsの起動を明示的に行うことで、問題なく操作できましたが、System Eventsに明示的にlaunch操作を行わなくてはならなくなったようです。リリースノートに記載すべきレベルの変更が加わっているように感じます。

NSStringのstringWithFormat:を呼び出すとクラッシュ：理由＝（３）

こんな基礎的な箇所でバグを作られるとウンザリします。また、使っている箇所が多過ぎてウンザリします。このバグのせいで、Mac App Storeで配布しているUni DetectorのCPUアーキテクチャ別のグラフ表示機能を実行すると（macOS 11.x台、11.5より前では）クラッシュしていました。
–> macOS 11.5で修正されました。macOS 11.0〜11.4の間、この機能がまともに動いていなかったわけです。AppleScriptのプログラムは、macOS 11に対しては最新のバージョン以外はサポートしないということになるでしょう。

NSString’s StringWithFormat:をmacOS 11で実行すると100％クラッシュ