macOS 13.6.2アップデートが配信されました。Cocoa-AppleScript AppletがmacOS 13.xの途中で動かなくなり、macOS 13.6.x台で修正されるのではないか？ などと思っていましたが、そういう状態にはなっていないようです。
ちなみに、macOS 13.xよりももっと古いOSで「Cocoa-AppleScript Applet」のアプレットを作成し、そこから実行バイナリ部分（/Contents/MacOS/CocoaApplet）を抜き出して、macOS 13.x上で作ったCocoa-AppleScript Appletの同一バイナリを削除して入れ替えると動く、という検証報告も入っています。
正直、Cocoa-AppleScript Appletは登場以来、「こんなので使えるか！？」という存在でした。その後OS X 10.10で一般のAppleScript実行環境でCocoa呼び出しが許可されてから、Scripter側にCocoa活用のノウハウが蓄積され、「標準環境よりもできることが多い」とのことで再評価されたものでもあります。
macOS 14の英語環境だけで発生している現象ですが、12時間制の時刻表記設定にしてdateオブジェクトから文字列に変換すると、
時刻と「AM」「PM」の間にUTF-8で202Fのキャラクタ「Narrow No-Break Space」を入れてくるようになったもよう。これを入れるとどういう「いいこと」があるのかは、自分にはわかりません。
macOS 10.12あたりで日本語IMからFinder上のファイル名を入力した際に不可視文字を突っ込まれるという「大惨劇」が起こって、こっそり「なかったこと」にされたようですが、あの時にはリネームできないわファイル名を指定すると一致しないわ、既存の不可視文字入りファイルを修正してもそのままでは保存ができないわで、ひどい目に遭いました。現在日時をそのままファイル名に指定すると大惨劇が起こりそうです。
まぁ、でもAppleに報告してもどうせ真面目に取り合わないでしょうし、日本語環境でこの惨劇は発生しないので、英語圏の誰かが報告すればいいんじゃないでしょうか。
なお、Sonomaの日本語環境で12時間制の時刻表記設定にしてdateオブジェクトから文字列を取り出しても、「午前」「午後」といった12時間表記にともなう表記文字と時刻情報との間に、このような不可視キャラクタが混入することは確認できませんでした。
AppleScriptObjC（Cocoa Scripting）の実行環境は大きく分けて3つあります。
1つ目は、Script EditorもしくはScript Debugger上で動かすもの、あるいはアプレットの書き出しを行なったもの。実行環境IDを取得すると、AppletとDropletは別のIDが返ってきますが、だいたい同じものです。
2つ目は、Xcode上で作成するCocoaアプリケーションです。AppleScriptでアプリを作成して、Mac App Store上で販売することもできます。かなり多くのCocoaの機能を利用できます。
3つ目が、これら2つの中間的な機能を持つCocoa AppleScript Appletです。Script Editorのファイル＞テンプレートから新規作成＞Cocoa-AppleScript Applet.appを実行すると編集可能になります。
Cocoa-AppleScript Appletは、Script Editor上のCocoa Scriptと同様の機能が使える上に、アプリケーション由来のイベント（起動中であるとか、起動終了したとか）を利用できます。
Cocoa-AppleScript Appletが登場したOS X 10.7時代、Xcode上のようにInterface Builderで手軽にGUIが作成できるわけでもなく、Script Editor上で普通に動かすScriptのようにログを表示してデバッグができるわけでもなく、何か明確な用例が存在するわけでもないため「これでどないせーっちゅーんじゃ？」と、とても手を出せないものと感じました。自分はこれを明確な「失敗作」として評価していました。この環境を嬉々として使っている人物といえば、edama2氏ぐらいのものです。
その後、macOS 10.10以降で通常のScript Editor上で動かすAppleScriptでもCocoaの機能が利用できるようになったため、Cocoa Scriptingのノウハウが蓄積され、「より高機能なCocoa Scripting環境」としてCocoa-AppleScript Appletが再評価されるようになりました。
Script Editor上で記述するCocoa Scriptで機能的に不十分だと感じるようになる場面で、Xcodeを使ってフル機能のアプリケーションを作るほどでもない、という状況において、Cocoa-AppleScript Appletという第3の選択肢が存在していることの意義はあったのです（使っているユーザーがめちゃくちゃ少ないとは思いますが）。
そして、ごくたまに様子を見るぐらいだったCocoa-AppleScript Applet環境ですが、最近（macOS 13.x上で）動かないという声が寄せられるようになりました。自分も動かないことを確認しています。テンプレートから1行も追加していない状態でも動かないので、これは明らかにApple側のミスでしょう。
バグレポートすれば直してもらえるのかもしれませんが、こうした情報が共有されるとか、Appleがドキュメントを出すようにしないと、いつも不手際をこっそり誤魔化すだけで「給料をもらって毎日バグを作るAppleエンジニア」「Appleのエンジニアは製品を作らない。バグを作る」といった批判をかわせない状態になることでしょう。
これは、年表を頻繁に作る立場の人間からいえば、Mac OS X 10.3で「is in」演算子が動作しなかったのと同じぐらいの大規模なバグに見えます。
本件、macOS 14RC上でも同様に発生しています。おおかた、「証明書の期限が切れている」といったたぐいのトラブルだと思っています。
Calendar.appのイベント（予定）に、ファイルを添付できるようになっています。ここに、AppleScriptアプレットを添付して実行することで、タイマー実行アプリとしてCalendar.appを利用する、というスタイルが初期のMac OS Xで見られました。Mac OS X 10.6ぐらいまででしょうか。
その後、どうもCalendar.appのイベントにAppletを添付しても実行されなくなった、という話をよく聞くようになりました。
自分も、タイマー実行アプリとしてCalendar.appは「使えないもの」と判断し、自前でタイマー機能などを作り込んで使ってきました。確実さでいえば、これは実に確実ではあるものの、それを外部に提供するのかという話については、いい「落とし所」を見出せない感じではあります。
こちらもタダで出すつもりはないけれど、これどうせ国内外のScripter連中は買わないよね、というところで話が止まっているものでもあります。モノがモノなので、Mac App Storeにも出せないでしょう（あらかじめ、どういうアプリを操作する、という設定を行なって提出する必要があるので。事前にわかるわけがない）。
そんな中、X（旧称Twitter）上で「Calendar.appをAppleScript Appletのタイマー起動用に使っている」という話を聞きつけ、その内容について実際にやりとりをして、自分の手元でもできることを確認しました。
その時点での自分の理解では、「イベントにAppletを添付して、イベントのアクションで『添付ファイルをオープンする』という指定を行えばOK」だという話だと納得しました。なるほど、自分は使い方を誤解していたのか、と。
しかし、その翌日に「別のAppletも添付して試してみよう」ということで、別のイベントを作成して別のAppletを添付して「添付ファイルをオープン」させてみたものの、今度はイベントの指定時刻に通知は来るものの、添付ファイルであるAppletは起動されませんでした。
Calendar.app自体のバグなのか、それともイベントへのApplet添付・実行には何か気づかないパラメータが存在しているのか？（イベント登録時のアカウントであるとか、ローカルの通知だけにしておかないとダメとか） そのあたりがまったく不明です。
昨日、一昨日ぐらいの段階でCalendar.appへのAppletの添付・実行は2・3度成功していたので、なかなか謎なところがあるものです。
昨日の今日でナニではありますが、M1 Mac miniの起動SSDに別パーティション（Beta）を作って、macOS 14をインストールしました。
パーティション作成→BetaパーティションへのmacOS 13のインストール→BetaのmacOS 13で起動→macOS 14にアップデート
という手順を経る必要がありました。
電子書籍「AppleScript最新リファレンス v2.8対応」を出すにしても、いろいろと確認すべき事項があったため（macOS 14の処理系がバージョン2.9だったらシャレになりません）、細部の確認が行えていないと怖い部分がいろいろありました。
macOS 14のAppleScript処理系のバージョンは2.8のままで変更はありません（予想どおり）
「システム設定」（System Settings）のAppleScriptによるコントロール機能が回復。各PaneのIDを取得してrevealコマンドで表示できるようになった。ただし、すべてのPaneについてIDが割り振られているかは未確認。どうせAppleのことなので、IDが割り振られていないPaneであるとか、指定しても表示されないPaneの存在が予想される（1つありました→表示まで時間がかかるPaneだったもよう。すべてチェックして、表示できないIDのPaneはありませんでした）
全体的に実行速度が若干macOS 13よりも向上しているように見えますが、クリーンインストールしたためなのか、Rosetta 2をインストールしていない環境であるためなのかは不明
日本語環境でText To Speechのキャラクター「O-Ren」「Hattori」が追加されているものの、sayコマンドで指定できるようにはなっていない（音声キャラクタの使用ライセンスの問題なので、バグではない。ただし説明がまったくない点はあいかわらず不親切）
aliasからPOSIX pathに変換すると結果がおかしくなるといった「macOS初期β版によくある」不具合は見られなかった
macOS 12のβ版でかなり長い間修正されなかった（Release版では直った）「スクリプトメニューが表示されない」不具合は見られなかった（直前に発生した不具合を何回も繰り返すAppleあるある）
スクリプトエディタのコンテクストメニュー・スクリプトに、絵文字つきのファイル/フォルダのコンテンツを入れると、コンテクストメニューに「項目が重複して表示される」不具合が修正された（macOS 13βでも一時期直っていた時期もあったので再発する可能性あり。まったく油断できない）
要素数の多い配列（list）の生成、ランダムシャッフル、ソートなどCocoaの機能を用いた高速処理の速度については速度低下は見られず
700箇所の位置情報と8,000箇所の位置情報（鉄道駅、バス停留所）の距離計算を行うベンチマークで、macOS 13だと1分45秒程度だったものが、macOS 14では1分35秒程度。遅くなっているわけではなさそう
指定配列要素の順列組み合わせ計算（Permutation）の計算結果も若干速くなっている。誤差程度だが、遅くなるという傾向は見られなかった
「Mail.appでAppleScriptからメール生成＋送信を行うと、メール1通あたりに生成されたプロセス2個がメモリ上から消去されず、メール作成すればするほどプロセスがたまってメモリが喰いつくされ、動作速度が壊滅的に遅くなる」不具合は未検証（Mail.app自体のバージョンアップは行われていない）。
macOS 12/13と初期Release版でNSDataDetectorによるデータ認識が日本語環境だけ問題を起こしていたバグについても検証が必要（何回も不具合を出している要チェックポイント。Apple自身がリリース前にチェックすべき）
→ ひととおりテキストからの情報抽出を行わせてみたところ、問題なく動いているようです。ただし、ここ数バージョンのmacOSは、リリース版で大幅に劣化する（未知のバグがたくさん発生）ので油断はできません
連絡先（Contacts）のAppleScript用語辞書のうち、プラグイン（廃止済み）のSuites「Address Book Rollover Suite」がhiddenになった（そのままでは表示されない。とくに問題はない）
ミュージックのAppleScript用語辞書のうち、playlistの「loved」属性が「favorited」に変更された。AppleEventコードなどはそのままで予約語が変更
Safari v17のAppleScript用語辞書で、隠し命令「show credit card settings」が追加された。なお、macOS 13.x上に提供されているSafari 17betaでも同様の変更が確認されている
Shortcuts Events添付のsdefがいろいろmacOS 14で書き換えられている（バージョン番号は変わらず）。これを見るのはなかなか面白い。
スクリプトエディタ上でテンプレートから作成できる「Cocoa-AppleScript Applet」が動作しない（macOS 13から発生している現象）
「AppleScript最新リファレンスv2.8」の作成で、一番手間がかかったのは、Markdownで書いた原稿をPagesに移し替えることでした。Markdownでは雑なレイアウトを作ることはできても、結局のところ「表」の制御がまったくできないために、Markdownで作り続けることは無理だと判断しました。掲載プログラムリストについても、行折り返しが不自然になる箇所があり、そのために全体の文字サイズが変わってしまうなどの「不可解な挙動」がいくつか見られました。
とっくの昔に結論が出ていたことですが、もう本作りにMarkdownは利用していません。
そして、作り直すさいにさまざまなコンテンツを再チェックすることで、なるべく間違いがなくなるように努めてきました。この表もその1つです。
昔作ってそのまま使い回してきましたが、Digital Hub Scriptingの箇所が不自然です。
Digital Hub ScriptingはmacOS 10.13の時点でSystem Eventsに移行した、と考えていました。でも、今日、ねんのために確認してみたら、
あれっ？（＾ー＾：：
Digital Hub Scriptingについては、個人的な使用頻度がおそろしく低く、あまり使ってきませんでした。System EventsのSuites（命令群）の移り変わりについては割とチェックしてきたのですが、Digital Hub Scriptingについてはちょっと自信がありません。
手元の稼働状態にあるマシンで一番古いのはOS X 10.7.5の環境で、これをチェックしたところ、Digital Hub Scripting.osaxは存在していました。
バージョン1.7です。
macOS 13.6の環境でチェックしてみたところ、
あいかわらずバージョン1.7でした。もはや、初期のMac OS Xの環境については起動可能なものがない（か、確認に時間がかかる）ため、多分このような感じなのでは？ というところでしょうか。OS X 10.6.8については未確認ですが、おそらく10.6.8の段階でDigital Hub Scripting.osaxは収録されていたことでしょう。
こんなところではないかと。もはや、考古学の領域ですが、勘違いで間違っていた部分を修正できたことは喜ばしいことです。ただ、この情報はほとんど誰も追いかけていないようなので、間違っていても怒られない気配が濃厚ではあります。
外付けSSDに別バージョンのOSをインストールしておいて、β版の評価時には外付けSSDで起動する……という運用がmacOS 12あたりからできなくなってきています。そのため、業務用のMacとβテスティング用のMacを別に用意できず、macOS 14, Sonomaのβテストについては「完全無視」という今日このごろです。
書籍などで、β版OSでスクリーンショットを撮るわけにもいきませんので、当然な状況です。また、β版で気合いを入れてチェックしても、Release版でβ版以下のクオリティのOS（バグだらけ）になってしまうことが続いており、βテストの意義そのものを疑っています。
そんな中で、Sonomaのβテスターから漏れ伝わってくる「SonomaのCocoa Scriptingが遅い」という噂。
すべてのテスターから詳細な情報を聞けていないものの、何か特定の機能で10倍ぐらい速度が遅くなっている領域があるようです。よくある、Permutation（いくつかの要素の全パターンの組み合わせを計算出力）における速度低下とかいう「処理データ数がふえると遅くなる」という話ではなく、どうも遅くなる箇所が偏在しているようです。
いわく、
–InDesignの組版でCocoa Scriptingを利用しており、10倍ぐらい遅くなった
–GamePlayKit.frameworkの機能を呼び出して配列のシャッフルを行ったら10倍ぐらい遅くなった
などなど。
テスターが自分のマシンが何なのかを書かないので、どの程度深刻なのかが見えてきませんが、OSをアップデートしたら最新のマシン（の特定の処理）が10分の1の速度になったら嫌ですよね？
OS自体の機能はたいして機能アップしないのに、バグとか不具合ばかりが増えるというのは残念なことです。
macOS 13.x上でも日本語入力の速度の極端な低下が見られたりと、SoCの高パフォーマンス・コアと省エネ・コアの振り分けに失敗している疑惑があるものの、macOS 14βの問題がこれによって発生しているのかどうかは不明です。
macOS 10.15の際にもCocoa Scriptingの速度低下が見られ、macOS 12まで修正されませんでした（macOS 11で自分がレポートして修正）。
毎度毎度、目がさめるような不具合やトラブルを起こして、Release版でさらに巨大な不具合を作り込むとは、もはや職人芸としか言いようがありません。某社の組織の運営とか管理方法に大きな問題があるとしか思えません。
日常的に利用するAppleScriptは、macOS標準搭載のScript Menuに入れて使用しています。エンドユーザーに「Script Editor上で実行しろ」とかいうのは無茶ですし、「全部Appletに書き出してアプリケーションとして実行」とかいうのも、セキュリティ的な縛りが増えた環境においては、無茶な話です。だいたい、日常的に利用している数百本のAppleScriptを全部Appletに書き出すというのも（自動処理でできるけど）無茶な話です。
そのため、日常的に利用するAppleScriptは、個人的にScript Menuから実行していますし、Script Menuを「最終防衛線」として定義し、AppleがOSアップデートのたびに作成するバグに対して文句を言っています。Script Menu上で動かなかったら問題視しています。
さて、そこに新たな頭痛の種が舞い込んできました。ここ数日いじくりまわしているPowerPointです。
いつものように、Script Menuに操作系のScriptを入れて実行すれば、それでおしまい！ というわけには行きませんでした。PowerPointの書類からTOCつきのPDFを書き出すAppleScriptを書いて、Script Menuに入れたら実行できなくなりました（途中までは実行できるのに……）。Script Editor/Script Debugger上では問題なく実行できるのに、です。
この場合、Script Menuがランタイム環境（実行環境）になるわけで、各種セキュリティ設定もScript Menuに対して行っています。AppleScript Appletを数百個自動生成できたとしても、数百個のAppletに対してすべてセキュリティ設定を行うのは現実的な話ではありません。Script Menuに対して権限設定をまとめておけたほうが便利です。
そのため、Script Menuには「オートメーション」「フルディスクアクセス」「アクセシビリティ」など考えられる一通りのセキュリティ設定が行われているわけですが、先のPowerPointを操作するAppleScriptが、Script Menu上からは実行が完了しませんでした。
どうもファイルアクセス権限に関する問題（Script Editor上から実行しても、初回はダイアログが出る）のようなのですが、この権限がScript Menuから実行すると取得できないようで…
この問題をAppleに報告すべきなのか、Microsoftに報告すべきなのか、現状だと判断がつかないところです（たらいまわしにされる予感）。
PowerPointなんか使う方が悪い、という話までありそうな、、、、
Microsoft 365のExcel v16.71、Windows版とmacOS版のソースコードが共通化されたというふれ込みではあるものの、実はけっこうフォーム部分が違うし、VBのマクロエディタで日本語が記入できないとか、互換性のない関数（Mac上で動作しないENCODEURL、Switch,IFS、FILTERXML、WEBSERVICEなどの関数）の存在など、いろいろ勘弁してほしい出来です。
しばらくはNumbersだけで用が済んでいたのですが、ここのところWindows版のExcelの講座なども行っていたので、併せてmacOS版のExcelについても追加調査。細かい点のチェックを行っていました。
そんなExcelでアドインのオンラインストアからQRコード作成用アドインを探してみたところ、フリーなものは存在していないようです。
Cocoaの機能を利用すれば、割とすぐにできてしまう程度のQRコード。わざわざアドインの力を利用する必要などなかったのです。AppleScriptでQRコードを生成して、Excelのワークシートに差し込めばよいだけです。
ところが、ひさしぶりにExcelのScriptを引っ張り出してきて、昔書いた「Excelに指定の画像を配置する」Scriptを実行してみたところ、エラーで動きません。
ワークシート上にshapeを作成できるのに、そのshapeに指定パスの画像を割り当てる処理でエラーになります。
そんな時、「出来の悪いプログラマは、POSIX pathで誤魔化して実装する」という経験則が思い出されました。
目を閉じると、AppleのKeynoteで一時期行われていた、画像配置コマンドにPOSIX pathを要求していたアレな実装であるとか（あれはひどかった）、いまだにアレであり続けているAdobe Acrobat DistillerのdistillコマンドがPOSIX pathを要求する件であるとか（file pathって書いてあるのに、aliasじゃなくてPOSIX pathを要求するという地雷仕様）、枚挙にいとまがありません。
そんなわけで、普通に書いても通らなかったのでパスをPOSIX pathで与えてみたところ、見事（？）配置されました。
| AppleScript名：画像をワークシート上に配置.scpt |
| set anImagePath to choose file set anImagePOSIX to POSIX path of anImagePath tell application "Microsoft Excel" set cwb to workbook 1 tell cwb tell worksheet 1 set aPicShape to make new shape at the beginning set width of aPicShape to 312 set height of aPicShape to 312 user picture of aPicShape picture file anImagePOSIX end tell end tell end tell |
Keynote, Pages, Numbersのバージョン13.0がリリースされました。AppleScript用語辞書的な変更点はありません。
Keynote v11からずっと、新規書類を保存するとエラーになる。Full Disk Accessの権限をKeynoteに与えていてもエラーになる、という重大な問題が解消されないままである、という認識でおりました。状況はKeynote v13.0でも変わりません。
これは、Apple側が問題として認識していないのではないか？ という仮説を立て、いろいろ試してみました。
まずは、v12から継続している状況についての説明。Keynoteで新規書類を保存する際に「as Keynote」という、明らかに「指定してくださいね」というオプションがAppleScript用語辞書の中にあるので、指定したくなるところですが
| AppleScript名：Keynoteで書類を新規保存（A）.scpt |
| set newFile to ((path to desktop) as string) & "newDoc1111.key"
tell application "Keynote" set newDoc to make new document save document 1 in file newFile as Keynote end tell |
これを指定するとエラーになります。これが、Keynote v12.0から続いており、１年以上継続している状況です。以前のバージョンで通っていた記述がエラーを出すようになった、というものです。
ふとここで、「as Keynote」というオプション指定をはずしてみると…….
| AppleScript名：Keynoteで書類を新規保存（A）.scpt |
| set newFile to ((path to desktop) as string) & "newDoc1111.key"
tell application "Keynote" set newDoc to make new document save document 1 in file newFile end tell |
エラーが出なくなりました！！！（＾ー＾；；；； ファイル保存もできました。
なんなんでしょう、これは、、、、
いろいろ不具合が多すぎて、本当にこれがリリース版なのか理解に苦しむmacOS 13。リリース当初から、AppleScript経由でPagesの（大量の）書類に順次PDF書き出しを行わせると、PDF書き出しされない書類が発生することがわかっていました。
同じバージョンのPages 12.2.1でも、macOS 12.x上では問題が発生していなかったため、明確にmacOS 13.xが理由ではあるのですが、不具合の発生源がよくわかりません。
（１）Pages書類オープン後に時間待ちが必要？
macOS 13移行当初、Pages種類をオープンした後に一定の時間（１秒程度）待機を行って、内部の状態が安定するのを待ってPDF書き出しを行うようにしました。数十程度のPages書類であれば、これで問題は起こりませんでした。
（２）数百個のPages書類を順次オープン→PDF書き出しするとミスを行う
その後、百以上のPages書類を順次オープンして、時間待ちして、PDF書き出し処理を行ってみたところ、明確にPDF書き出しできない書類が複数出てきました。何回実行しても書き出されません。また、そのPages書類単独でPDF書き出しを行わせると問題なく書き出しが行えます。
このPDF書き出しミスを行う書類の動作を観察していると、指定した時間待ちが正しく行われません。delayコマンドに問題があるのかと考え、shellのsleepコマンドを試したりもしていますが、正しく時間待ちが行われません。
さらに、普通にPages書類からPDF書き出しできていたとしても、それを数回繰り返すとPDF書き出しされなくなる（何か、一定の回数書き出すと問題が発生するらしい）ため、macOS 13自体の再起動かログアウト→再ログインが必要でした。
そもそもmacOS 13の出来がよくない、いろいろ問題がありすぎるということ自体が問題なわけですが、、、「複数回実行しないと再現しない」「原因の所在がどこにあるのかよくわからない」といった状況で、レポート自体を行いにくいというのが現状です。
ほかにも、Finder上で選択したファイルをCommand-Oでオープンさせるとオープンできない場合があったりと（なんだこれ？）、何がやりたいのかよくわからないOSバージョンです。セキュリティ強化はもちろん重要ですが、まともに動かないOSをリリースされても、、、、さらに、Beta段階では許可されていた外付けSSDからの前バージョンのOSの起動がmacOS 13リリース以後は封じられており、そういうのは「まともなOS」をリリースできるようになってからやってほしい気持ちでいっぱいです。
もう、macOS 13自体、やり直してほしい気持ちでいっぱいです。macOS 10.13、macOS 10.15と同じかそれ以上にダメなバージョンにしか見えません。
macOS 13のリリース版でスクリプトエディタを使うと、新規書類を作成しても「保存できない」とか、作成した書類を破棄できないとか、そもそもAppletとしてエクスポートする際にCode Signを指定するとハングアップするとかいう、macOS 13β版でも発生していなかった不具合のオンパレード。
もはや「この状態で何をバグレポートしろと？」「絶対に、リリース前にチェックとか一切してないだろ」という仕上がりに、開いた口がふさがりませんでした。
macOS 13.1の正式アップデートがリリースされ、これらの挙動は解消されたように見えます。見えるのですが、macOS 12でさんざんやらかしまくったように、β版で同じようなバグをノーチェックで出してくるので、油断ができないというべきなのか、信じた奴がバカなのかという状況。
とはいえ、β版でやらかしたトンでもないバグをApple側が認識していないこともままあるので、Appleの魔の手から環境を守るためにはβ版を試さないといけないんでしょう。Appleは、OSを開発しているんでしょうか？ それとも、全世界に嫌がらせをしているんでしょうか？
また、Appleがやらかしてくれたようです。あの会社はNSNotFoundの定義値を何回間違えたら気が済むんでしょうか。これで通算４回目ぐらいです。macOS 10.12で発生し10.13.1で修正された定義値のミスをまたやったわけで、失敗がまったく生かされていない。大したものです。
今回のバグは、文字列の検索処理を行っているときに発見しました。指定文字列から対象文字列の登場位置と長さをリストで返す処理を行っていたところ、NSRangeからlocationを取得したときに、これ以上見つからない場所まで来たときにNSNotFoundを返すことを期待されるわけですが、そこに前回（macOS 10.12…10.13）と同様のおかしな値を返してきました。
この（↓）AppleScriptをmacOS 13上で実行すると、エラーになります。
追記：macOS 13.1でもエラーになります。
| AppleScript名：テキストのキーワード検索（結果をNSRangeのlistで返す）.scptd |
| — Created 2017-08-09 by Takaaki Naganoya — 2017 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" –http://piyocast.com/as/archives/4771 property NSString : a reference to current application’s NSString property NSMutableArray : a reference to current application’s NSMutableArray property NSLiteralSearch : a reference to current application’s NSLiteralSearch set aStr to "ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC " set aRes to searchWordRanges(aStr, "ATGC") of me as list –> {{location:0, length:4}, {location:10, length:4}, {location:20, length:4}, {location:30, length:4}, {location:40, length:4}, {location:50, length:4}, {location:60, length:4}, {location:70, length:4}} on searchWordRanges(aTargText as string, aSearchStr as string) set aStr to NSString’s stringWithString:aTargText set bStr to NSString’s stringWithString:aSearchStr set hitArray to NSMutableArray’s alloc()’s init() set cNum to (aStr’s |length|()) as integer set aRange to current application’s NSMakeRange(0, cNum) repeat set detectedRange to aStr’s rangeOfString:bStr options:(NSLiteralSearch) range:aRange set aLoc to detectedRange’s location log aLoc if (detectedRange’s location) is equal to (current application’s NSNotFound) then exit repeat hitArray’s addObject:detectedRange set aNum to (detectedRange’s location) as number set bNum to (detectedRange’s |length|) as number set aRange to current application’s NSMakeRange(aNum + bNum, cNum – (aNum + bNum)) end repeat return hitArray end searchWordRanges |
症状も前回とまったく同じなので、対処も前回と同じです。Appleは定期的にNSNotFoundの定義値を間違えるトンでもない会社なので（計測された事実）、NSNotFoundまわりはAppleがバグをやらかすことを前提に書いておくべきなんでしょう。
| AppleScript名：テキストのキーワード検索（結果をNSRangeのlistで返す）v2.scptd |
| — Created 2017-08-09 by Takaaki Naganoya — Modified 2022-12-01 by Takaaki Naganoya — 2022 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" property NSString : a reference to current application’s NSString property NSMutableArray : a reference to current application’s NSMutableArray property NSLiteralSearch : a reference to current application’s NSLiteralSearch set aStr to "ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC " set aRes to searchWordRanges(aStr, "ATGC") of me as list –> {{location:0, length:4}, {location:10, length:4}, {location:20, length:4}, {location:30, length:4}, {location:40, length:4}, {location:50, length:4}, {location:60, length:4}, {location:70, length:4}} –> {{location:0, |length|:4}, {location:10, |length|:4}, {location:20, |length|:4}, {location:30, |length|:4}, {location:40, |length|:4}, {location:50, |length|:4}, {location:60, |length|:4}, {location:70, |length|:4}} on searchWordRanges(aTargText as string, aSearchStr as string) set aStr to NSString’s stringWithString:aTargText set bStr to NSString’s stringWithString:aSearchStr set hitArray to NSMutableArray’s alloc()’s init() set cNum to (aStr’s |length|()) as integer set aRange to current application’s NSMakeRange(0, cNum) repeat set detectedRange to aStr’s rangeOfString:bStr options:(NSLiteralSearch) range:aRange set aLoc to detectedRange’s location –macOS 13でAppleが新たに作ったバグを回避 if (aLoc > 9.999999999E+9) or (aLoc = current application’s NSNotFound) then exit repeat hitArray’s addObject:detectedRange set aNum to (detectedRange’s location) as number set bNum to (detectedRange’s |length|) as number set aRange to current application’s NSMakeRange(aNum + bNum, cNum – (aNum + bNum)) end repeat return hitArray end searchWordRanges |
Appleと協議した結果、そこは仕様として認識していないという話で、とくに仕様を変えていないという話で平行線をたどってしまいました。
結局、書き方を少々変えることで問題そのものを「なかったこと」にする方向で決着。納得はできませんが、macOS 10.11とか10.12の時代に書いたScriptでもあり、その実行環境は手元に残っていません（macOS 10.13は何台か存在しています。macOS 11のASのCocoa呼び出しバグの検証時に活躍）。
| AppleScript名：テキストのキーワード検索（結果をNSRangeのlistで返す）v3.scptd |
| — Created 2017-08-09 by Takaaki Naganoya — Modified 2022-08-29 by Takaaki Naganoya — 2023 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" property NSString : a reference to current application’s NSString property NSLiteralSearch : a reference to current application’s NSLiteralSearch property NSMutableArray : a reference to current application’s NSMutableArray set aStr to "ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC ATGC ACGT ATGC AGTC " set aRes to searchWordRanges(aStr, "ATGC") of me as list –> {{location:0, |length|:4}, {location:10, |length|:4}, {location:20, |length|:4}, {location:30, |length|:4}, {location:40, |length|:4}, {location:50, |length|:4}, {location:60, |length|:4}, {location:70, |length|:4}} on searchWordRanges(aTargText as string, aSearchStr as string) set aStr to NSString’s stringWithString:aTargText set bStr to NSString’s stringWithString:aSearchStr set hitArray to NSMutableArray’s alloc()’s init() set cNum to (aStr’s |length|()) as integer set aRange to current application’s NSMakeRange(0, cNum) repeat set detectedRange to aStr’s rangeOfString:bStr options:(NSLiteralSearch) range:aRange set aLen to (detectedRange’s |length|) as number if aLen = 0 then exit repeat hitArray’s addObject:detectedRange set aNum to (detectedRange’s location) as number set bNum to (detectedRange’s |length|) as number set aRange to current application’s NSMakeRange(aNum + bNum, cNum – (aNum + bNum)) end repeat return hitArray end searchWordRanges |
macOS 13.1Betaで地味でうっとおしく、わずらわしく嫌がらせとしか思えないバグが１つ。スクリプトエディタでテンプレートから新規作成したAppleScriptが、ファイル保存も破棄もできない状態になっています。
普通に新規作成したScriptも、デフォルトでiCloud Driveに自動保存され、破棄できなかったのでiCloud Drive上のファイルを削除したら、スクリプトエディタ上の名称未設定書類を破棄できるようになりました。
作業するたびに画面上に保存も破棄もクローズもできないゾンビ状態のスクリプトエディタ書類がたまっていくのですが、これはどういう検証をしたらこういう状態になるんだか。
保存も破棄もできないスクリプトエディタ書類をGUI側からいろいろ確認してみたところ、デフォルトの保存先が「アプリケーション」フォルダになっており、それで一時ファイルも作れず、保存もできない状態になっているようです。
もう少し試して、デフォルト保存先を「アプリケーション」以外のユーザーディレクトリのどこか（デスクトップとか）に指定したら、複数あったゾンビ書類は破棄できるものも出てきたのですが、このデフォルト保存先フォルダをいろいろいじくらないと破棄できないとかいうのは、正直ダメすぎる動作だと思います。
macOS 12.6.1がアップデートして12.6.1になるというわけのわからないバージョン番号の採番ルールが展開されている今日このごろ。
macOS 12の初期において、Shortcuts.appやCotEditor内部のAppleScript実行環境において、script objectで論理分割した中にあるハンドラを呼べない という問題が確認されました。ただし、macOS 12.6.1で気づいたということであって、もう少し前のバージョンでこの変更が加わっていた可能性もあります。
ハンドラ呼び出しの範囲がscript objectを超えられないというわけで、CotEditor PowerPackの作成時に大幅にScriptを書き換える必要があって手間がかかった記憶があります。
AppleScript基礎テクニック集25巻にて「CotEditorのメニューScriptとShortcuts.appでは対策が必要」と書こうとして、念のために実際にmacOS 12.6.1の上でCotEditor v4.3.6で確認したところ、動きました。Shortcuts.appでも同様にscript object内部のハンドラを外部から呼び出せるようになっていました。
＃ 慌てて、書籍の方を書き換えました
各プログラム側で何かそんなマイナーな問題への対策を行ったような雰囲気はなかったので、OS側の実行モジュール（osascript？）で対策を行ったような雰囲気があります。ただ、Appleがリリースノートを一切出さないので、確認のしようがありません（ものすごく不信感しかないので、リリースノートは出してほしいなー。まさか、詳細なリリースノートを出さないことで、クラッカーへの情報流出を防止できている、とか現状を肯定的に捉えているのだろうか）。
β版も出ないで唐突にリリースされたmacOS 12.5.1および11.6.8において、Finderのselectionでスクリーンショット画像を取得し、Finderにopenコマンドを送ってLaunch Serviceまかせでオープンすると、「……を表示するためのアクセス権がないため、開けませんでした。」というメッセージが表示され、画像がオープンされないという問題が報告されています。
tell application "Finder" open selection end tell
たしかに、Finderまかせでアプリケーション無指定でファイルオープンさせるのは「楽」なのですが、もしもこれが「スクリーンショット画像を装った実行ファイル」への対処だったりすると、バグとも言い切れないような印象を受けます（何の問題なのかが報告しづらいです）。
いろいろ確認してみると、スクリーンショットであることを示すメタデータ、
kMDItemIsScreenCapture = 1
が付いている場合に、このアクセス権がないというダイアログが表示されるようです（他の因子もあるかも？？？）。
me@myMac ~ % mdls /Users/me/Pictures/as\ runtimes.jpeg
_kMDItemDisplayNameWithExtensions = "as runtimes.jpeg"
kMDItemBitsPerSample = 24
kMDItemColorSpace = "RGB"
kMDItemComment = "Screenshot"
kMDItemContentCreationDate = 2022-08-21 01:51:41 +0000
kMDItemContentCreationDate_Ranking = 2022-08-21 00:00:00 +0000
kMDItemContentModificationDate = 2022-08-21 01:51:41 +0000
kMDItemContentModificationDate_Ranking = 2022-08-21 00:00:00 +0000
kMDItemContentType = "public.jpeg"
kMDItemContentTypeTree = (
"public.jpeg",
"public.image",
"public.data",
"public.item",
"public.content"
)
kMDItemDateAdded = 2022-08-21 01:51:41 +0000
kMDItemDateAdded_Ranking = 2022-08-21 00:00:00 +0000
kMDItemDisplayName = "as runtimes.jpeg"
kMDItemDocumentIdentifier = 0
kMDItemEXIFVersion = "2.2.1"
kMDItemFSContentChangeDate = 2022-08-21 01:51:41 +0000
kMDItemFSCreationDate = 2022-08-21 01:51:41 +0000
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = (null)
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = (null)
kMDItemFSLabel = 0
kMDItemFSName = "as runtimes.jpeg"
kMDItemFSNodeCount = (null)
kMDItemFSOwnerGroupID = 20
kMDItemFSOwnerUserID = 504
kMDItemFSSize = 259097
kMDItemFSTypeCode = ""
kMDItemHasAlphaChannel = 0
kMDItemImageIsScreenshot = 1
kMDItemInterestingDate_Ranking = 2022-08-22 00:00:00 +0000
kMDItemIsScreenCapture = 1
kMDItemKind = "JPEGイメージ"
kMDItemLastUsedDate = 2022-08-22 05:31:24 +0000
kMDItemLastUsedDate_Ranking = 2022-08-22 00:00:00 +0000
kMDItemLogicalSize = 259097
kMDItemOrientation = 1
kMDItemPhysicalSize = 262144
kMDItemPixelCount = 1003255
kMDItemPixelHeight = 1073
kMDItemPixelWidth = 935
kMDItemProfileName = "Cinema HD Display"
kMDItemResolutionHeightDPI = 72
kMDItemResolutionWidthDPI = 72
kMDItemScreenCaptureGlobalRect = (
15,
25,
935,
1073
)
kMDItemScreenCaptureType = "window"
kMDItemUseCount = 6
kMDItemUsedDates = (
"2022-08-20 15:00:00 +0000",
"2022-08-21 15:00:00 +0000"
)
ただ、これがFinderの問題なのかといえば、Finder上でファイルをダブルクリックしてデフォルトのアプリケーションでオープンさせるという動作はできるので、Finderのバグと言いにくい。
AppleScriptの問題なのかといえば、個別にオープンするアプリケーションを指定すれば問題は起こらないので、問題として報告しにくい。
Launch Serviceの問題なのかといえば、Launch Serviceそのものの問題とも言えない。
Apple内の複数チームにまたがる「複合要因」による障害というのは、Appleのチーム間の調整がとぼしいことにより、問題が顕在化したまま治らない傾向があります。ユーザー側もこの問題を「バグ」として報告しにくいものがあります。
Finderにアプリケーション・ファイルをオープンさせるとアプリケーションを起動できてしまうという、Sandboxの「穴」をふさいだのではないか、という見立てもあるわけですが、正直よくわかりません。
少なくとも、これらのバージョンのOSではこういう動作を行うよ、という情報をユーザー間で共有するぐらいしか「できること」がなさそうに見えます。
個人的には、こういう処理はしないので「そうなの？？」ぐらいの印象でしたが、ちょっとしたAppleScriptをコピペで書いて、さまざまなツールから起動するだけという種類のScripterはよく利用する記述のようなので、不満を感じる内容のようです。
macOS 12.5上のスクリプトエディタで、バンドル形式のAppleScript書類を「実行専用」で書き出してみたところ、Finderのファイルプレビューで中身が見えますね（＾ー＾；；；
これを脆弱性と言わずに何と言うのだろーか？ Apple純正のスクリプトエディタで「実行専用」で書き出すと、Finderプレビューで内容が読めてしまうというのは。
重要なScriptについては、Script Debuggerで書き出すことをおすすめします。
▲スクリプトエディタで内容を読めない「実行専用」形式で書き出した書類なのに、Finderプレビューでソース情報が見える
毎回毎回、何かかしら嫌がらせをブチ込んでくるmacOS 12.5シリーズ、RC（21G69）で「applescript://」Custom URL Linkが一定以上の長さになると無視されることが判明しました。
これは、本Blogなどに掲載しているURLリンク入りのプログラムリストの機能を無効にするものです。
この動作は、macOS 10.15のPDFViewで行った嫌がらせと同じ仕様です。さんざん文句を言ったところ、Preview.app上でのURLイベントクリックについてはStop、他のアプリケーションのWindow上のPDFViewについては嫌がらせをしなくなったという経緯があります。
自分も本件はAppleにバグレポートしますが、Appleはレポート件数で重要かそうでないか判断するので、本Blogをご覧の方々にもAppleへのレポートをお願いしたいところです。
–> Demo Movie of macOS 12.5RC applescript:// URL Link ignorance
macOS 12.xのBetaではいろいろ楽（苦）しませていただいています。ええもう本当に。
本日ダウンロードできるようになったmacOS 12.5（21G69）がBetaなのか正式リリースなのか不明ですが（Release候補、という噂が）、いまのところAppleScriptの実行が封じられたり、Dockに登録したアイコンにファイルをドラッグ＆ドロップで２・３回渡すとファイルがオープンできなくなるといったBeta 5の不具合には遭遇してはいません。
Apple側はRelease Notesを出すわけでもなく、説明も一切しないので、何を基準に内容を判断すべきなのかよくわかりません。
macOS 12.3の頃のβでもさんざんやらかしてくれましたし、macOS 12.5 betaでもやらかしました。しばらくβに付き合うのは勘弁していただきたい。これだけ大規模な問題のあるBetaをノーチェックで出すのは（頭が）どうにかしている、としか言えません。
macOS 10.13の「Beta段階ではまともに動いていたのに、Release段階で廃墟リリース」というやらかし。10.15の「夏の間にゴミクズ化してまともに動かない」とか、macOS 11.0の「（機能によっては）Apple Siliconで10年前のIntel Macの70倍遅い」（12.xで直りましたが）とかいう、目の覚めるようなクズOSアップデートの数々。
社内でダメなものにダメと言わないから、こんなものを出し続けるのではないでしょうか？ 社内でもチェックぐらいはしてほしいですよね。これで明らかになったのは、Apple社内でmacOSのβ版をまるっきり使っていない、まったく試していないということです。
■表 macOS 12.x上で発生した（している）AppleScript系のバグと解決状況一覧
| 発生バージョン | 内容 | 解決したか？ | 状況説明 |
| 12.x | スクリプトエディタのコンテクストメニューで、絵文字を含むフォルダ/ファイルの内容が（複数階層下では）重複して表示される | No | |
| 12.3 | AppleScript書類をオープンできない | Yes | |
| 12.2？ | Scriptを実行すると「表があふれました」というエラーが表示される | ？？？？ | |
| 12.2？ | インストールされていないアプリケーションを操作するScriptをオープンできない | Yes | 12.5では保存されたままの内容でオープンできている |
| 12.3 | Finder上のselection itemsをオープンした際に、作成したアプリは起動されるがファイルはオープンされない | Yes | macOS 12.3.1/12.4beta1で解消 |
| 12.5beta5 | アプリケーション同士のイベントのやりとりが２回以上発生するとエラー-609になる | Yes ??? | 12.5にて解消？ 確認中 |
本日リリースされたmacOS 12.5beta 5で大問題が発生しています。Scripterは本アップデートに絶対にアップデートしてはいけません。
# macOS 12.xの環境が複数あって、まともに動作しない状態にしてもダメージがなければ、macOS 12.5 beta 5を体験してもよいでしょう。イキュラス・キオラ（いやな記憶を消す魔法）
# macOS 12.5正式リリース版では修正されたようです。
KeynoteでもCotEditorでもいいのですが、AppleScriptから（Script Editor、Script Debuggerなど実行環境を問わずに発生）GUIアプリケーションを操作すると、１・２回目は正常に動くのですが、３回目あたりから（同じ処理であっても）エラー -609になります。
一部で「AppleScriptユーザーにだけ影響があるのでは？」と言われましたが、全ユーザーに影響があります。
Dockの上に登録しているアプリケーションのアイコンに、書類をドラッグ＆ドロップする操作を３回繰り返しただけでオープンできなくなりますし、Finder上で書類をダブルクリックないしCommand-Oでオープンしても、３回目からはエラーになります（Finderの再起動が必要に）。
今朝方から、Switch Controlでいつも画面上に出しているフローティングパレットからSafariのコントロールができなくなっていて、「Webサイト側の仕様が変わったのか？」などと思っていたのですが、CotEditorもKeynoteもみんなこの状況に陥っていました。
どうも、AppleEventのやりとりを監視しているようで、プロセス間通信が同じアプリケーション間で発生すると２〜３回目からエラー -609になります。
自社製品を使っていない管理職が「こうしろ」とてきとーに仕様を決めているようにしか見えないのですが（ーー；；；；
–> See macOS 12.5 beta 5 bug example movie 1
–> See macOS 12.5 beta 5 bug example movie 2
これまでにも、AppleはOS X 10.7あたりでURLイベント経由で実行されたAppleEventについて、複数のアプリケーション操作をともなう動作を行なったときには、問答無用で処理を止めるといった変更を、Scripterに何の説明もなく行ってきました。
このURLイベント系の場合には「セキュリティ向上」という話の枠組みの中で「仕方ないかな」という納得感はありましたが、このmacOS 12.5 beta 5の「３ステップ爆弾」（Three steps bomb）についてはまったく納得できません。
この仕上がりでリリース（β版だけど）する連中の気が知れません。使っていると、ムカムカします（Dockへの書類のドラッグ＆ドロップも３回目以降はエラーになります。本当に使って試したのか疑問な仕上がり）。macOS 13の出来が不安になるような出来です。macOS 10.13のときにも盛大にやらかしたので、macOS 13という名前で不吉なものを感じてしまいます。
＃ macOS 12.5正式版では修正されたようです。リリースノートも何もないので、Apple側がこのどえらいバグをどこまで認識しているのか不明ですけれども