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 |
Piyomaru Software Booksの66冊目。「AppleScript基礎テクニック集(28)アプリケーションとの対話」を発売しました。PDF 35ページ＋サンプルScriptZipアーカイブ で構成されています。
→ 販売ページ
AppleScriptの文法をひととおり知っていて、実際に書くことができたとしても、それだけで何かをできるというものでもありません。各種GUIアプリケーションなりOSの機能を呼び出して、なにがしかの作業を自動化できなければ意味がありません。
ここで、いきなり「いつも行っている仕事をまるごと自動化しよう！」といった壮大な野望を目指しても失敗します。マウスやトラックパッドでGUIアプリケーションを操作するのと、AppleScriptで操作するのとでは「やりかた」や「方法」は若干異なります。そこには明確に「慣れ」が必要です。
その最初の第一歩が、アプリケーションとの間の「対話」です。対話してみて、様子を見て、それでアプリケーション操作の挙動を確認していきます。対話の仕方を知ることは、自動化を行うために必須の第一関門をクリアするためのノウハウなのです。
書く前にアプリケーションとの対話が欠かせない
対話の第一歩は、正確なアプリケーション名の指定から
参考資料：名前がローカライズされているアプリケーション
最初の会話「あなたの名前は？」
最初の会話「あなたの年齢は？」
AppleScript用語辞書で会話できる言葉を調査
選択中のオブジェクトを示すselectionを調査
「selection」の意味を調べる
オブジェクト選択してselectionの動作を調査
「selection range」の意味を調べる
表を選択してselection rangeの動作を調査
選択中のオブジェクトが「何か」を尋ねる
選択中のオブジェクトが「どうか」を尋ねる
書類上のオブジェクトを作成できないか？
audio clipを作成できないか？①
audio clipを作成できないか？②
対象オブジェクトに実行できるコマンドは？①
対象オブジェクトに実行できるコマンドは？②
対象オブジェクトに実行できるコマンドは？③
処理を組み立てるには「対話」が欠かせない
macOS 13.1Betaで地味でうっとおしく、わずらわしく嫌がらせとしか思えないバグが１つ。スクリプトエディタでテンプレートから新規作成したAppleScriptが、ファイル保存も破棄もできない状態になっています。
普通に新規作成したScriptも、デフォルトでiCloud Driveに自動保存され、破棄できなかったのでiCloud Drive上のファイルを削除したら、スクリプトエディタ上の名称未設定書類を破棄できるようになりました。
作業するたびに画面上に保存も破棄もクローズもできないゾンビ状態のスクリプトエディタ書類がたまっていくのですが、これはどういう検証をしたらこういう状態になるんだか。
保存も破棄もできないスクリプトエディタ書類をGUI側からいろいろ確認してみたところ、デフォルトの保存先が「アプリケーション」フォルダになっており、それで一時ファイルも作れず、保存もできない状態になっているようです。
もう少し試して、デフォルト保存先を「アプリケーション」以外のユーザーディレクトリのどこか（デスクトップとか）に指定したら、複数あったゾンビ書類は破棄できるものも出てきたのですが、このデフォルト保存先フォルダをいろいろいじくらないと破棄できないとかいうのは、正直ダメすぎる動作だと思います。
Twitter上で@usagimaruma氏がレポートしたところにより、FinderにSiri用の隠しAppleScriptコマンド「openVirtualLocation」が存在していることが明らかになりました。
ドキュメントに載っていないFinder AppleScriptの命令を見つけた。tell構文でFinderに対して 'openVirturalLocation "AirDrop"' みたいにすると、AirDropやiCloud Driveのウインドウを直接開ける。 pic.twitter.com/SZHb8c14T7
— usagimaru ⌘ (@usagimaruma) November 19, 2022
tell application "Finder" openVirtualLocation "AirDrop" end tell
/System/Library/CoreServices/Finder.app/Contens/Applications の下にある、
といった小型アプリケーションが、上記のコマンドを利用して機能を呼び出しています。バイナリをダンプすると、”openVirtualLocation”コマンドの部分を生AppleEventsで記述してあり、少し不思議な雰囲気です。
早速、手元の環境でチェックしてみたところ、報告されたとおりに動きます。
hidden=”yes”に設定されているために、普通にFinderをsdefをスクリプトエディタで確認しただけでは表示されません。
過去にさかのぼって、どのバージョンのOSから使えるのかを確認してみたところ、
macOS 10.14：NG
macOS 10.15：NG
macOS 11.6：Exist
macOS 12.6：Exist
macOS 13.x：Exist
と、Siriの搭載とリンクしているというよりは、ショートカット.appの搭載とリンクしているように見えるので、macOS 11のFinderにこのコマンドは搭載されていないのではないか、と推測します。
CotEditor v4.4.1＋macOS 13.1 Betaの組みわせで発生しているAppleScriptの問題について書いておきます。
CotEditorの内蔵スクリプトメニューから呼び出すAppleScriptは、実行プログラムがosascriptで、macOS標準搭載のスクリプトメニューと部品は同じですが、挙動や制約条件が異なります。
macOS 13＋CotEditorの内蔵スクリプトメニューから呼び出すAppleScriptで、「path to me」を実行したらエラーになる現象に直面しています。
| AppleScript名：mepath_without_block.scpt |
| set mePath to POSIX path of (path to me) display dialog mePath as string |
ただし、解決策はすぐに見つかって、tellブロックでpath to meを囲ってあげることです。tell current applicationで囲ってあげるのが一番手っ取り早いところ。using terms from scripting additionsも使えそうです。
| AppleScript名：mepath.scpt |
| tell current application set mePath to POSIX path of (path to me) end tell display dialog mePath as string |
「AppleScript実践的テクニック集（1）GUI Scripting」をmacOS 13環境に合わせた内容にアップデートしました。初版の283ページから315ページに増加。初版をお買い上げの方は、購入ページから再ダウンロードすることでアップデート版を入手していただけます。
→ 販売ページ
Update：macOS 13環境に合わせた記述変更、画面キャプチャ
macOS 13環境に合わせた記述変更（背景を黄色く塗ったページ）や、画面キャプチャを再度行い、macOS 13環境でも迷わないように内容を修正しました。
Update：UI Browserについての使い方を補足
PffiddlesoftからLate Night Software, ltdに移管された、GUI Scripting必携ツール「UI Browser」についての使い方を説明する章を追加しました。
Update：システム設定の各Paneの表示Scriptを掲載
macOS 12→13への変更で各ユーザーに影響の大きい「システム環境設定」から「システム設定」への移行にともない、各設定項目を呼び出す従来のやり方が通じなくなってしまいました。
本アップデートでは、システム設定の各Paneを表示するためのAppleScriptを多数収録。すべてのPaneを表示できるようにしているほか、第２階層のUIについても選択できるようにしています。
Update：macOSとの互換性の低いアプリケーションのGUI Scripting例をご紹介
他のOS上の互換開発環境で作られた、macOSと互換性の低いアプリケーションをGUI Scriptingで操作する実例について、ご紹介しています。
macOS 13でTTS（Text To Speech）キャラクタが追加され、日本語環境では各種読み上げ機能で「O-Ren」（女性）と「Hattori」（男性）というSiriの音声が使えるようになりました。
macOS 13の「システム設定」（System Settings.app）の「アクセシビリティ」＞「読み上げコンテンツ」で、「システムの声」（TTS読み上げキャラクタ）を選択、追加できるわけですが……
ただし、AppleScriptのsayコマンド（音声読み上げ、音声ファイルへのレンダリング）で、「Hattori」「O-Ren」が使えるというわけではありません。逆に、OSのサービス経由で音声名称を取得すると、
{"Kyoko", "Kyoko（拡張）", "Otoya", "Otoya（拡張）"}
などと結果が返ってくるものの、”Kyoko（拡張）”, “Otoya（拡張）”をsayコマンドで指定するとエラーになります。
say "こんにちは" using "Kyoko（拡張）" --> AppleScript Execution Error
| AppleScript名：TTS Voiceを言語で抽出.scpt |
| — Created 2017-03-28 by Takaaki Naganoya — 2017 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" use framework "AppKit" set aLoc to (current application’s NSLocale’s currentLocale()’s identifier()) as string –> "ja_JP" set vList to getTTSVoiceNameWithLanguage(aLoc) of me –> {"Kyoko", "Otoya"}–macOS 12まで –> {"Kyoko", "Kyoko（拡張）", "Otoya", "Otoya（拡張）"}–macOS 13 on getTTSVoiceNameWithLanguage(voiceLang) set outArray to current application’s NSMutableArray’s new() set aList to current application’s NSSpeechSynthesizer’s availableVoices() set bList to aList as list repeat with i in bList set j to contents of i set aDIc to (current application’s NSSpeechSynthesizer’s attributesForVoice:j) (outArray’s addObject:aDIc) end repeat set aPredicate to current application’s NSPredicate’s predicateWithFormat_("VoiceLocaleIdentifier == %@", voiceLang) set filteredArray to outArray’s filteredArrayUsingPredicate:aPredicate set aResList to (filteredArray’s valueForKey:"VoiceName") as list return aResList end getTTSVoiceNameWithLanguage |
TTS Voiceの環境に合わせて何かこれらのTTS Voiceのファミリー名称などを返すようにしないとダメなのかも？？？
| AppleScript名：TTS Voiceを言語で抽出 v2.scpt |
| — Created 2017-03-28 by Takaaki Naganoya — Modified 2022-11-12 by Takaaki Naganoya — 2022 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" use framework "AppKit" set aLoc to (current application’s NSLocale’s currentLocale()’s identifier()) as string –> "ja_JP" set vList to getTTSVoiceNameWithLanguage(aLoc) of me –> {"Kyoko", "Otoya"}–macOS 12まで –> {"Kyoko", "Otoya"}–macOS 13 on getTTSVoiceNameWithLanguage(voiceLang) set outArray to current application’s NSMutableArray’s new() set aList to current application’s NSSpeechSynthesizer’s availableVoices() set bList to aList as list repeat with i in bList set j to contents of i set aDIc to (current application’s NSSpeechSynthesizer’s attributesForVoice:j) (outArray’s addObject:aDIc) end repeat set aPredicate to current application’s NSPredicate’s predicateWithFormat_("VoiceLocaleIdentifier == %@", voiceLang) set filteredArray to outArray’s filteredArrayUsingPredicate:aPredicate set aResList to (filteredArray’s valueForKey:"VoiceNameRoot") –Voice Rootを取得 –要素をユニーク化 set theSet to current application’s NSOrderedSet’s orderedSetWithArray:aResList return (theSet’s array()) as list end getTTSVoiceNameWithLanguage |
ちょっと驚きの展開です。Bill Cheesemanの引退にともない、その後の展開が不安視されていたUI Browserの新たな話が上がってきました。
たしかに、Bill Cheeseman引退後のUI Browserの「あり得る」ストーリーの１つとして、（v3.x系の）Open Source化は考えないではなかったのですが、まさかBill Cheeseman本人によりすべてSwiftで書き直されたもの（v4）が、あらためてオープンソース版として公開されるとは思いませんでした。
公開されているのは、現行のUI Browser v3.0.2よりも新しい「v4」であり、完成したものではないようです。一応、興味があったのでProjectをダウンロードしてXcodeでビルドしてみましたが、UI Browser 4を起動することはできませんでした（ビルドは通ったが、起動途中で止まる）。
PFAssistiveFrameworkなどの心臓部分もすべてSwiftで描き直されているものの、「AccessibleElement.swift」が空行を含めてわずか570行程度であったりと、その機能から推測される（巨大な）コード規模とかけ離れた内容になっていることから、「手を付けられる範囲で手をつけただけ。完成品というレベルのものではない」という印象を受けます。
ただ、作り方が「ゼロから作り直した」のではなく、「C++のプログラムを順次翻訳している最中」に見えるため、これからも順次C++からSwiftに翻訳していくのかもしれませんし、そうではないのかもしれません。
v4が動くところまで行くのに、年単位で時間がかかりそうに見えます。
このようにちゃんと引き継ぎが行われるというのは、珍しいことであり……自分だったら、ある日いきなりBlogが消えておしまいでしょう。
macOS 13がリリースされた翌日に、iWork（Keynote、Pages、Numbers） v12.2がリリースされました。
本バージョンで、AppleScriptから新規iWork書類を作成して保存させられないバグは修正されていません。
Keynote v12.2：
フォントサイズ指定が整数値（integer）から実数値（real）が指定できるように変更された
Pages v12.2：
フォントサイズ指定が整数値（integer）から実数値（real）が指定できるように変更された
AppleScript用語辞書掲載サンプルScriptで、Word書類への書き出しで「.doc」の指定が削除された（.docxのみ掲載）
→ Pages 12.2＋macOS 13.1betaで連続してPages書類をオープンしてPDFを書き出していたら、どうもPDF書き出しできない場合があるようで（再起動で回復）。オープン後に少しウェイトを入れてからPDF書き出しするなど、様子を見ているところです。ファイルオープン後にASで後続のコマンドを受け付けるまでにアプリケーション内/書類内の初期化が間に合っていないのでは？ と疑っています。
Numbers v12.2：
フォントサイズ指定が整数値（integer）から実数値（real）が指定できるように変更された
AppleScript用語辞書掲載サンプルScriptで、Excel書類への書き出しで「.xls」の指定が削除された（.xlsxのみ掲載）
13という数字は、キリスト教国では不吉な数字と言われており、これはイエス・キリストの13番目の弟子が師を裏切ったからだとかなんだとか。とにかく、日本で言う「黒い猫」や「北枕」、「夜に爪を切ってはいけない」、「霊柩車が通ったら親指を隠せ」並みに不吉とされております（ここ、Google翻訳で英語に訳したら意味わかんないだろーなー。日本に伝わる「不吉な迷信」のかずかずを列挙しています）。
かくいう自分も13という数字にはとても嫌な記憶があります。macOS 10.13です。Betaの最中はとてもいい感じだったのに、Release版は完膚なきまでに壊れた状態でリリースされ「macOS史上最悪の事故物件」「macOS Vista」「（クオリティが）Low Sierra」との呼び名をほしいままにしています。
さて、macOS 13、従来どおりのナンバリングでいえばmacOS 10.18が2022/10/24にリリースされたわけであります。10月中のリリースは読み通りだったので、そんなもんだろうかと思いますが、従来のmacOSのリリースと趣が異なる印象を受けています。
かつて「Mac OS X 10.5のバグを全力で修正したのが10.6だ」という、バグ修正を主眼にリリースされたMac OS X 10.6のような、そういうOSバージョンに見えます。「macOS 12.7」といった趣で、OSのアップデータの容量も5GB少々と、これまでの半分程度のサイズです（ARMバイナリだから？）。
macOS 10.13：Beta中はまぁまぁの出来だったのが、Release時に事故を起こしてバグだらけでリリースされた「事故物件」。「毒の沼」と言われる。
macOS 10.14：Beta中からバグが多くて、呆れて放置。最終リリースごろに仕方なくmacOS 10.12から乗り換えたが、その頃にはいろいろバグも取れていた。この状態でリリースしてほしい。
macOS 10.15：夏の終わりごろに「このバージョンはアップデートしちゃダメだよねー」と開発者仲間の間で話題になっていたバージョン。自分もはじめてOSのアップデート紹介をBlogで行うことを拒否。後から調べても山のようにバグが存在し、AppleScriptでもCocoaの呼び出しが大幅に遅くなるような巨大なバグが存在。macOS 10.13並みに「使ってはいけないバージョン」になった。スキップ推奨。
macOS 11：Intel Mac上ではこなれたいいOSだったものの、Apple Silicon Mac上では不具合のオンパレード。バグレポート用のmacOSと言われた。ただ、Intel Macではとくに問題なかったのでIntel MacユーザーにはいいOS。
macOS 12：巨大な不具合（Apple Silicon Mac上でAppleScriptが低消費電力コア上で実行されて速度低下、macOS 10.15から続くCocoa呼び出し速度低下）が修正される。Apple Silicon Macの本当の性能が発揮される。ただし、Release後のアップデート（Beta時）で巨大なバグを連発。とくに、AppleScript絡みのバグが多発したためマシンが使えなくなる時期が頻発。最後の最後（macOS 12.6.1）で帳尻を合わせたものの、深刻なトラブルが絶えなかった。個人的にはテクニカル・ハラスメント系OSと呼んでいる。
で、macOS 13なんですが……いまのところ、そんなに時間を割いて本気で使い込んではいないものの（Beta段階では見た目からもうやる気を感じない作りで、色彩的にめまいを感じていました）、巨大なバグ（スクリプトメニューが表示されないとか）はBetaの段階で報告して修正されているし（Beta段階の話です）、AppleScriptの処理系もAppleScript version 2.8でとくにmacOS 12から変更はありません。
たとえば、Mail.appのバージョンもv16ととくに変わっていないですし、全体的にmacOS 12.7といって差し支えない内容だと感じます。そう考えると、いろいろバグも直っているようなので、そんなに悪くないOSに見えてきます。逆に、ここ数年のmacOSアップデートではAppleのエンジニアには呪詛の言葉しか出てこなかったことを考えれば、不具合を（いまのところ）それほど感じないというのは「すごい出来事」なのではないでしょうか（Beta段階の話です）。
「システム環境設定」が「設定」に名称変更され、画面構成が大幅に変わっている点については、Beta評価時にはアイコン色がグレーのものばかりで「何これ？」という状態でしたが、どうやらリリース版では差し変わったようでした。
とはいうものの、Frameworkまわりは変わっていそうなので、Cocoa系の機能を利用する上ではひととおりチェックが必要そうです。
本当の真価は、macOS 13に合わせてリリースされるiWork 12.2（多分）の仕上がり次第といったところでしょうか。AppleScriptから新規ファイル保存ができないという巨大なバグがv12からv12.1へと引き継がれたままで、この調子で行くと「PDFの書き出しができない」といったバグの再発が予測されます。
→ Pages v12.2.1の書類をPDF書き出しする際に問題が発生しています。PagesをAppleScriptからコントロールしてPDF書き出しさせた際に、数十程度の書類を連続してPDF書き出ししていると、何回も繰り返し実行すると途中からPDF書き出しを行わなくなります。このような症状に直面した場合にはOSの再起動かログアウトを行う必要があるようです。また、xattrの属性com.apple.quarantineの内容によってはファイルのオープンができないとか、オープンしてもPDFの書き出しを行えないといった不具合が発生しています。OS側のxattrの制御に変更を加えつつも、Apple純正アプリケーションが対処できていない可能性があります。
→ Finder上で書類を選択して、キーボードショートカット「Command-O」でオープンしようと操作して、エラーが出ることがあります。Appleのエンジニアはそろいもそろってバカなんでしょうか？ Finder上で書類がオープンできないというのは、由々しき事態だと考えます。
→→ 本件、「濁点/半濁点つきのファイル名を持つファイルをFinder上でオープンできない」という現象だったようです。日本語環境でしか発生しない系のバグ。
→ macOS 13の評価は「Betaの頃のほうがマシ」というもので、Release版で一気に崩落したmacOS 10.13やβ段階で「これはダメだ」と見放されたmacOS 10.15よりもよくないものです。社内のどこかに「トンでもなく仕事が遅いチーム」がいて、その内容をマージした瞬間にOS全体の動作がおかしくなる、という状態に見えます。
Beta段階では外付けのUSB接続のSSDにインストールして、本体SSD（macOS 12.x）との間で切り替えて起動して様子を見ていましたが、正式リリース後にこの切り替えができなくなっていました。
外付けSSDからの起動が行えず、仕方なくMac mini内蔵SSDから起動したmacOS 12.6.1の上でアップデートを実行し、インストール先を外付けSSDに指定してインストールを実行。これは完了して起動できたのですが、今度は内蔵SSDを指定してmacOS 12.6.1（多分）を起動できない状態。
選択肢がなかったので、仕方なく内蔵SSDにもmacOS 13をインストール。とくに変更点が大量にあるわけではないので、仕方なく使っていますが、前バージョンに切り替えて起動できない（？）点については「騙された」「説明がない」ととても嫌な気分になりました。
→ このあたりの「セキュリティ強化」（技術的な嫌がらせ）についてはWWDCでもあまり具体的には話をせず、どーでもいい内容のいつになったら実用段階になるのかわからないようなお花畑のような話に終始するので、WWDCがお花畑だらけの昨今。Appleが実際にやっている嫌がらせの数々をまとめた「アンチWWDC」みたいな実務的な話を聞きたいところです。
system info
--> {AppleScript version:"2.8", AppleScript Studio version:"1.5.3", system version:"13.0", short user name:"me", long user name:"Takaaki Naganoya", user ID:504, user locale:"ja_JP@calendar=iso8601", home directory:alias "Macintosh HD:Users:me:", boot volume:"Macintosh HD:", computer name:"M1 mini", host name:"m1mini.local", IPv4 address:"192.168.0.50", primary Ethernet address:"XX:XX:XX:XX:xx:XX", CPU type:"ARM64E", CPU speed:missing value, physical memory:16384}
・「システム環境設定」（System Preferences）が「システム設定」（System Settings）に名称および画面構成を変更。AppleScript用語辞書がついているものの、従来どおりのもので実際の機能とリンクしていない
→ 指定のPaneを表示するライブラリを書いて対応した（書籍のアップデート付録で対応予定）
・Font Bookが書き直され、AppleScript用語辞書がついていない
→ すでに、（個人的に）Font Bookを見捨ててNSFontによるフォント情報アクセスのためのAppleScriptを揃えているため、そちらに切り替え
・Music.app v1.3.2.16にAppleScriptコマンド「export」が追加された
・スクリプトエディタのアイコンにアプリケーションのアイコンをドラッグ＆ドロップしてもAppleScript用語辞書が表示されない
不具合かと思っていたのですが、これまで使えてきたアプリケーションのAppleScript用語辞書確認方法が使えないようです。
スクリプトエディタのアイコンにアプリケーションのアイコンをドラッグ＆ドロップする、という操作でAppleScript用語辞書が表示されなくなっています。１手間かけて、スクリプトエディタの「ライブラリ」ウインドウにアプリケーションをドラッグ＆ドロップして登録しておいて、登録したアプリケーション名を一覧からダブルクリックするという方法のみ有効です。
→ macOS 14で直っています。バグとも仕様とも取れない話で、そもそもAppleがRelease Notesをまともに出さなくなったので、目の前にあるOSを見て「バグだ」としか評価のしようがありません
・Finder上で書類をダブルクリックしても、オープンされない場合がある謎仕様
どうも、アプリケーションが起動していないと書類がオープンされない場合があるなど、あきらかにセキュリティ上の何らかの改変を加えた結果、「普通に動いていてほしい」部分にまで問題が出ています。Apple社員に行きあったら「おまえら、自社製品使ってるか？」「いい加減にしろ」と言って回りたい雰囲気です。「君たちには深く失望した」というのがメールの挨拶文になりつつある感じです。
・GUI Scriptingの機能を呼び出すAppleScriptをAppleScriptアプレットに書き出した場合、最初の１個目は認証され、アクセシビリティの（GUI Scriptingの）認証を取得できる。しかし、１個目のAppleScriptアプレットを削除して、２個目のアプレットを認証しても、「補助アクセスは許可されません」というダイアログが出てGUI Scriptingの実行を許可されない
・Siriの仕様がBeta版から変更になったため、Siri呼び出しAppleScriptライブラリ「AgentCallerLib」v1.2が動作しない（→ 対応のため修正しました）
・スクリプトエディタのコンテクストメニューから呼び出すアシスタントScript、これらにフォルダやファイルに絵文字を使用していると同じ項目が複数重複して表示される（macOS 13Betaで直っていたのに、Release版で再発）
・PagesのPDF書き出しに問題あり。ファイルの拡張属性（xattr）のうちcom.apple.quarantineの値によってはPDF書き出しできないという問題がある。また、繰り返しPDF書き出しを行なっていると、途中からPDF書き出しがスキップされます。
・Mail.appでAppleScriptからメッセージ作成＋送信を行なっても、メモリ上から関連する子プロセスが解放されない。
macOS 13についていろいろ意見交換をして気づいた点ですが、macOS 13がどういう位置付けのOSなのか？ これが従来のOSとは違っているのではないかと。
Appleにフィードバックしても修正されないバグが多々ある中で、過去にフィードバックしたさまざまなバグが修正されていることに気づきます。macOS 13で新たに発生したバグまでは手が回っていないようですが、システム環境設定をiOS風のシステム設定に変更するなどユーザーの目につく場所の「変更」を行う一方で、地道なバグ修正は行っている模様です。
このところのmacOSでは（10.15以降）、リリース後に段階的に機能を追加。リリース当初は「新規追加」とされている機能はすべて盛り込まれないことが常態化しています。
最も宣伝されている機能は「ステージマネージャ」ですが、真っ先に使わなくなりそうな機能です。その他、iOSから持ってきたアプリケーションなどがあるようです。
外付けのSSDを用意してmacOS 13βをインストールして試しています。beta5あたりから「ソフトウェアアップデート」を実行しても最新版にアップデートできない、という問題に直面して首をひねっていたのですが…..これが、アップデートを呼び出す画面上のささいな操作方法の違いにより、EULAが表示される順路を通ってくればアップデートでき、EULAが表示されない順路だとアップデートされないということに気づきました。
つまり、「EULAが表示されない順路」を毎回行っていたら、えんえんとアップデート作業を行ってもアップデートされないという作りになっているようで……これが「βあるある」なのか、Appleがまともに検証していない証左なのかはわからないですが、「落とし穴」を開けたままリリースしている状態だと認識しています。
落とし穴を回避して、Beta 6にはアップデートできました。スクリーンショットの掲載はできないので、詳細に画面操作を掲載することはできませんが、EULAが表示されなかったらアップデートは（ダウンロードやアップデートしているように見える画面が出ても）失敗します。
実際に試してみると、依然としてmacOS 13上ではスクリプトメニューが動作しないことに気づきます。廃止とかいった状態ではなくて、明確に存在するのに動作しないという状況は、以前のβ版から変わりません。
スクリプトメニューは、macOSの中では割と技術的な側面ではなくセキュリティ面で問題になりやすい部品です。それなりの実行権限を持ったソフトウェアであり、悪用されると困ります。ふだん使っているメニュー表示のまま、別の悪意あるScriptを組み込まれたら、その強力な実行権限でいろいろ操作できてしまいます。
ただ、デフォルトではオフになっており、スクリプトエディタの環境設定からオンにする必要があるという、何もよく知らないユーザーからは「見えない場所」にあるので、問題にならないという程度の存在です。
そして、ショートカット.appのメニューという「機能的に似た同じようなもの」が出てきているため、これとの取捨選択といった話もApple社内では出ていることでしょう。
ただし、ショートカット.appは一見「いろいろできそうなオモチャ」ではあるものの、実際に使ってみると「まともに動かないクズ」「検索キーワードに画像とイメージと写真とか類語語バラバラに使いたがるクズ」なので、実際にはショートカットのほうが消えるべき存在です。実用性がさっぱりです。下手をすると、Automatorの置き換えにすらならないかもしれません。
そうした実用性皆無のオモチャと実際に使える道具のどちらを重視するのか、といった話になると、現在のAppleの体制ではどうも「実用性皆無のオモチャ」を選択しそうで困ります。
スクリプトメニュー自体、AppleScriptで作れないことはないので、いっそ「AppleScriptで書き直したスクリプトメニュー」というものを用意してもよいのかもしれません。あるいは、FastScripts 3のような同様のソフトウェアの利用を考えるべきなのかも。
macOS 10.13というリリース時に崩壊した悪夢のようなアップデート、そしてmacOS 13という新OSのバージョン番号。macOS 13には、「余計なことをしないで地道でまっとうなアップデートを出してほしい」と思っています。
▲個人的にスコアをつけている各macOSのβ版のクオリティ。macOS 13は「議論やすり合わせの欠如を感じる」「macOS 10.15以来の嫌な予感を感じる」「必要な仕事をしていない割に余計なことをやっている感じ。総じて、仕事をしている人間の人数が少ない雰囲気」な出来。現状では10点。β版の間は大人しくしていて、Release後に極端なやらかしが頻発する傾向にある昨今のmacOS
macOS 12の各Betaの出来が著しくよくないので、macOS 13betaの出来映えに不安を覚える昨今です。macOS 12は、β版のときには非常に出来が良かったのに、リリース後にどんどん不具合が増えるという謎のリリースが行われていました。もう２年に一度ぐらいのアップデートぐらいにしないと無理だと思います。
外付けのSSDにmacOS 12.4→macOS 13 beta 3にアップデートの順でアップデートしてインストールしてみました。
慣れの問題なのか、iOSに寄せた画面構成に変更して、デザインがどんどんダメになっていっているような印象があります。「コレジャナイ感」が全体に漂っています。やる気のなさでWindowsと似ている印象です。
Blogへの画面キャプチャの掲載は控える必要はありますが、バージョン情報やその他のファイルについてはとくに問題ないものと考え、調査した概略を記しておきます。
真剣に使い込んだわけではなく、あくまでも触ったぐらいの試用です。
これは、macOS 12の時にもかなり後のβになってからバージョン番号が変わったので、なんともいえません。現状はそうだというだけです。
スクリプトエディタの環境設定から、スクリプトメニューを有効にしてもメニューバー上に表示されません。プログラム的には同じ場所に存在しており、単独で起動ができない状況。ただし、これが「廃止された」という話ではなく、現状では起動できていない（macOS 13のセキュリティモデルと合致していないため起動できない？？？）状況です（多分）。廃止、という状態ではないと思います。macOS 13 beta4でもまだ起動できていません。
System PreferenceがSystem Settingsに名称変更になりました。User InterfaceがmacOS（NEXTSTEP）風からiOS風に変更になっており、Preferences Paneの区分が変わってしまっています。AppleScriptから各パネルを表示できるようになっており、このあたりでmacOS 13上のパネルIDなり名称でオープンできることと、旧来のIDや名称で表示できるという状態にまで持っていくのか？ あるいは、いつものApple風のお仕事でいえば「macOS 13上では何もしなかった」ということもありえます。
スクリプトエディタの編集支援のために用意されている「Script Assistant」の仕組みにおいて、macOS 12では「絵文字入りのフォルダ、絵文字入りのファイル」が入っていると、項目が重複して表示されるバグが発生していました。macOS 13beta 4ではこれが発生していないことを確認しています。