本日配布開始になったmacOS 26.3 Beta(25D5087f)において、これまで確認されていた「Finderのempty trashバグ」が出なくなったことを確認しました。
これは、AppleScriptからFinderのゴミ箱のクリア(empty trash)コマンドを実行すると、コマンドの実行後にエラーを返すというmacOS 26のリリース時から発生していたバグです。
ただし、macOS 26.3は1月後半のリリースが見込まれているため、それまでにバグが復活する可能性もあります。
本日配布開始になったmacOS 26.3 Beta(25D5087f)において、これまで確認されていた「Finderのempty trashバグ」が出なくなったことを確認しました。
これは、AppleScriptからFinderのゴミ箱のクリア(empty trash)コマンドを実行すると、コマンドの実行後にエラーを返すというmacOS 26のリリース時から発生していたバグです。
ただし、macOS 26.3は1月後半のリリースが見込まれているため、それまでにバグが復活する可能性もあります。
# Because this information contains important content, linking to macscripter.net or reproduction is prohibited. This is because the macscripter.net administrator’s policy prohibits links to Japanese articles.
Xcode上で作成したAppleScript App Project(AppleScriptObjC)において、Projectに組み込んだ.scpt/.scptdを呼び出したときに、

のように、「FSFindFolder failed with error=-43」のエラーが出て実行できない問題に直面しました。
同エラーは特定のフォルダが見つからない、というCarbon由来のエラーのようですが、とくに呼び出しているScriptではファイルパスの処理は一切していません(カレンダー計算しているだけです)。
このエラーは電子書籍「AppleScript+Xcode GUIアプリソース集」の執筆時に、

本来はTable Viewに指定年の日本の祝祭日をすべて掲載するつもりだったのですが、その計算Scriptをバンドル内に組み込んで呼び出すとエラーに。
引数を単に返してくるだけの単純なハンドラ(testMeハンドラ)を呼び出す分にはエラーにならず、もちろんXcode Projectに組み込むAppleScriptはスクリプトエディタ/Script Debugger上で実行するとエラーになりません。
同書籍の執筆時には「とても解決するための時間が取れない」と考えて祝祭日の計算ライブラリを外して収録・掲載していました。ちょうど、Xcode 26+macOS 26に合わせた内容のアップデート作業を行なっていたところ、本来の計算機能を組み込んでみたところ、やはり動かないことからAppleにバグ(AppleScriptObjC.framework側?)として報告したものです。
組み込んだScriptを呼び出しても、シンプルなテストハンドラでは実行を妨げられないのですが、複雑な処理を行うと問題になります。

macOS 26.1がリリースされ、macOS 26.0で発生していたFinderまわりのバグが、一応修正されたような形跡もあるのですが、結論からいえば別のエラーが出るようになりました。
macOS 26.0:
ゴミ箱に何も入っていない状態で、AppleScriptからFinderに「empty trash」を実行すると、タイムアウト時間(180秒)まで待ってタイムアウトエラーに。

macOS 26.1、26.2:
ゴミ箱に何も入っていない状態で、AppleScriptからFinderに「empty trash」を実行すると、時間待ちしないでエラーに。

一応、empty trashをtry〜end tryで囲っておけば、ゴミ箱が空の場合に発生するエラーを回避できます。
| AppleScript名:empty trash test 2.scpt |
| tell application "Finder" try empty trash end try end tell |
macOS 15/26にて、AirDropをAppleScriptから利用するAirSharing Libを、スクリプトメニューに入れたAppleScriptから呼び出せないという現象に直面しています。
スクリプトエディタ上で動かすと動作するのですが、スクリプトメニューから動かすとまったく動作しません。一般ユーザー向けのAppleScript実行環境であるスクリプトメニューで動作しないのはかなり問題です。
AirSharing LibはもともとSal Soghoianが書いたプログラムにWiFi制御系のコードを追加して書いたものですが、現状のmacOS 15上で動作する最低限の記述だとこんな感じ(↓)です。
スクリプトメニュー上で動作するために、何かの「おまじない」が必要なのか、そもそもスクリプトメニューの仕様上それが禁止されるようになったのか? なかなか不思議なところです。
動作確認できたAppleScript実行環境:
スクリプトエディタ、Script Debugger、Switch Control、Automator、Claris FileMaker Pro 2025、FastScript 3、Xojo 2025




| AppleScript名:AirDropTest.scptd |
| — – Created by: Takaaki Naganoya – Created on: 2025/09/23 — – Copyright © 2025 Piyomaru Software, All Rights Reserved — use AppleScript version "2.8" use framework "Foundation" use framework "AppKit" use scripting additions property airDropService : missing value set theFile to POSIX path of (choose file with prompt "AirDropで共有するファイルを選んでください:") my performSelectorOnMainThread:"shareWithAir:" withObject:(theFile) waitUntilDone:true –my shareWithAir:theFile–for debug on shareWithAir:thePOSIXFile set theFile to thePOSIXFile as string set fileURL to current application’s NSURL’s fileURLWithPath:(theFile) — AirDrop用の共有サービスを取得 set airDropService to current application’s NSSharingService’s sharingServiceNamed:(current application’s NSSharingServiceNameSendViaAirDrop) if airDropService ≠ missing value then airDropService’s performSelectorOnMainThread:"performWithItems:" withObject:{fileURL} waitUntilDone:true else display dialog "AirDrop共有サービスが利用できません。" buttons {"OK"} default button 1 end if end shareWithAir: |
macOS 15.xで続いていた、Shortcuts.appの「AppleScriptを実行」アクションにおいて、デフォルト入力されるべきハンドラなどのScriptが新規追加時に入力されないバグが、修正されたようです。
これは、macOS 26BetaのShortcuts.app上で本バグが修正されていたことから、macOS 15.5上のShortcuts.appの再確認を行ったところ、実際に修正されていることが明らかになりました。

macOS 15.5上のShortcuts.app ようやく「AppleScriptを実行」アクションのバグが修正されたもよう
バージョン番号のリナンバーが行われ、macOS 15の次はmacOS 26ということになりました。AppleScriptで「system info」を実行すると、 system version:”26.0″が返ってきます。
スクリプトエディタのバージョンは上がっていませんが、Dark Modeへの対応が行われており、エディタ背景がDark Modeで暗くなるようです。ウィンドウの角丸の半径が大きくなって、全体的にオモチャみたいな印象を受けます。個人的に嫌いではないですが、画面を広く使えない(余白が多い)ので現場によっては困ることも。
AppleScriptのバージョンは2.8で変更なし。まだそんなに真剣に使っていないので、AppleScriptから見て挙動が変わったかといった点はわかりません。
β版のmacOSでありがちな、バージョン取得機能ミスや、aliasからPOSIX pathへの変換ミスなどは見られませんでした。
ただ、WWDC Keynoteで見られたガラス調のUIの見た目については、現時点では見られず、これがまだ実装が間に合っていないためなのか、M1 Mac miniだと環境的に再現しないのかは不明です。
テキスト読み上げ音声系のVoice Characterが増えたりはしていないのですが、「プレミアム」と「拡張」が同時に存在しているなど、ポリシーにゆらぎが見えます。どちらかにするのではないんですね。
バグ:
スクリプトエディタ内からスクリプトメニューをオンに設定しても、ステータスメニュー上にスクリプトメニューが表示されません。すぐにオフになります。この点はバグでしょう(調査が始まったとの話)。
→ 本件はリリース版で修正ずみです(βで修正されていました)
Xcode 26でAppleScript App templateが認識されませんでした。関係者に報告していますが、回答はもらっていません。一応、既存のXcode ProjectをmacOS 26に持って行って、ビルド+実行できることは確認しています。テンプレートの場所や記法が変わったのかも?
→ Xcodeのテンプレートのフォルダが変更になったようです。従来は、~/Library/Xcode/Templatesでしたが、Xcode 26では~/Library/Developer/Xcode/Templates に変わっていました(ドキュメントとかヘルプに記載なし)。
→ 関係者との協議のすえ、これは自分の勘違いで最初から ~/Library/Developer/Xcode/Templates であったことが判明しました。
リリース版のmacOS 26で試したところ、従来どおりの組み方ではStatus Menu Itemを作成するAppleScriptがうまく動作していません。バグなのか、仕様変更なのかは不明です。


■FinderのBug
Michael Tsai氏がX上に投稿しているのを見つけましたが、Finder上でゴミ箱が空の状態で、empty trashを実行するとFinderが応答せず、タイムアウトエラーになるというFinderのバグが確認されています。
自分も、同じ内容をmacOS 26.1βの日本語環境で再現することを確認しました。


AppleがmacOS 16でクリップボードへのアクセスをiOSアプリ同様に制限する(認証を求める?)らしい、という話が出てきました。
Apple、Macアプリによるクリップボードの無断アクセスを制限へ
それだけなら、「なるほど」という話になるのですが、例によって検証をまともに行わないことが予想されるために、アプリ/アプレットのアイコンへのドラッグ&ドロップや、「サービス」を提供するプログラムにGUIがない場合に影響が出てくることでしょう(認証はGUIを持つプログラムに対してのみ行えるため)。
# 「サービス」機能は各アプリでメンテナンスしていないはずなので、対応せずに全滅するかも?
これは、相当に広い範囲にわたって影響が出るはずなので、問題動作がいたるところで発生することが予想されます。
各AppleScript実行プログラムに対してセキュリティ設定を行わないと、ファイルのドラッグ&ドロップやクリップボードの操作コマンドに問題が出るはずです。
macOS 15.5beta5(24F74)が配信されたので、報告済みのバグが修正されているかを確認しました。
日本語環境で特定パターンのファイル名のファイルパスをas aliasでキャストすると処理系まるごとクラッシュするバグ
→ 修正されたように見えます。報告したファイル名パターンで追試したものの、クラッシュは確認されません。
ただ、Appleの傾向として「一度直った箇所が、複数チーム間の連携不足(絶無?)ですぐに再発」するので、経過観察といったところでしょうか。これまでに発生した(つまらない)バグ同様、何回も繰り返して発生することが予想されます。
アクセシビリティ系の音声コマンドの一覧が呼び出せないバグは、本バージョンでは修正されていません。
macOS 15.5beta4が配信されましたが、とくに報告ずみのバグは何も直っていません。15.5台では直らないというよりも、バグとして認識していないんじゃないでしょうか?
正式リリースされたようですが、アクセシビリティの音声コマンドが動作していないバグについては、修正されていません。
macOS 15の初期バージョンでは動作することを確認していたのですが、目下macOS 15.5beta3でアクセシビリティ系の音声コマンドの機能が呼び出せないことを確認しています。
同機能は、日本語のファイル名をつけたAppleScriptアプレットを音声で呼び出せるため、音声操作が必要な用途では役立つものとして機能をチェックしてきました。ただ、Appleのワイヤレスヘッドセットのうち、AirPodsは音声認識に使えるもののAirPods Proが音声認識に使えなかったりと、ちょっと微妙な立ち位置になっていました。
AirPods/AirPods Proが使えるSiri系の操作機能と、この音声コマンドの2系統の音声操作機能が存在しており、統合するのかそのままなのか、さっぱり方向性が見えていない中のできごと。
アクセシビリティの機能が「システム設定」に存在しているのですが、画面上から内容を確認しようとするとエラーになります。
この問題は、日本語環境でも英語環境でも発生しています。

▲システム設定の「アクセシビリティ」>「音声コントロール」を選択

▲画面下の方の「Commands…」で音声コマンドの一覧を確認しようとして、クリックすると

▲エラーが出て表示されない
特定のパターンのファイル名のパスをaliasにcastする処理で処理系まるごとクラッシュするというmacOS 15.5β版(15.5 Beta(24F5053f))のバグ。
もっと以前から存在していたのかもしれませんが、特定のファイル名だとクラッシュを引き起こす前代未聞のバグがすごすぎて、いろいろ調べてみました。
文字依存する箇所はごくわずかで、いろいろ規則性があることがわかってきました。
・15.5 Beta(24F5053f)の日本語ユーザー環境(Primary LanguageをJapaneseにした状態)で発生。英語環境に変更すると発生しない
・ファイルパスをaliasにcastすると即・クラッシュ
・アルファベットとひらがな/カタカナが混在している必要がある???
・拡張子の種別は関係なく発生
・一定の文字数以上の長さが必要
・決定的な問題を引き起こすのは、濁点/半濁点つきのひらがな/カタカナが入っていること
・当初、記号文字やスペースが入っていることが条件かと思っていたが、これらを除去しても発生
・濁点/半濁点つき文字はファイル名の特定文字数以降に登場する必要がある。冒頭に移動させてもクラッシュは発生しない
・同じ処理内容のJXAでもクラッシュが発生する
・これらのクラッシュを誘発するファイル名がフォルダ名についていてもクラッシュは発生しない
現時点でクラッシュを発生させる最低限のファイル名は、
AAXAAXXあああああああああパ1.txt
であることを確認しています。
追記:
macOS 15.5β3(24F5053j)でも継続して発生中です。
追記:
macOS 15.5正式リリース時には解消されました。
きわめて珍しいパターンのバグに遭遇しました。自分の手元のmacOS 15.5Beta2環境(Apple Silicon Mac x 2)では再現率100%です(FB17285323)。再起動しても再現し、日本語環境で発生する一方で英語環境では発生しません。日本語環境であればJXAでも同様の現象の発生を確認しています。
「AppleScript+Xcode GUIアプリ ソースブック.key」
というファイル名のKeynote書類を、macOS 15.5β(日本語ユーザー環境)+Keynote v14.4で編集。このKeynote書類のボツスライドの移動用の「没.key」という書類をもとの書類の同階層に同じスタイルで作成するAppleScriptをスクリプトメニューから実行したところ、これがクラッシュ。
ねんのために、PagesとNumbersでも同様のテストを行なったところ、予想どおり100%クラッシュ。
これまでのmacOSでは遭遇したことのない現象だったので、原因を深掘り。
最終的に、Keynote/Pages/Numbers v14.4の書類からファイルパス(file)を取得し、そのfileをaliasにcastするとクラッシュするということが分かりました。
追記:Pixelmator Pro、CotEditorでも同様のファイル名に対して処理を行うとクラッシュすることが確認されました。
さらに追記:クラッシュを起こすパターンのファイルをchoose fileして、フルパスをstringにcastし、さらにaliasにcastするとアプリ操作に関係なくクラッシュすることが判明
さらに、ファイル名を短くしたり一部を取り出したりすることで、同様のクラッシュが発生するかどうかを調べてみたところ、
AppleScript+Xcode GUIアプリ ソースブ.key
AppleScript+Xcode GUIアプリ ソースブッ.key
AppleScript+Xcode GUIアプリ ソースブック.key
AAAAAAAA+XXXX GUIアプリ ソースブック.key
XXXXXXXX+XXXX XXXアプリ ソースブック.key
XXXXXXXX_XXXX XXXアプリ ソースブック.key
XXXXXXXX-XXXX XXXアプリ ソースブック.key
XXXXXXXX&XXXX XXXアプリ ソースブック.key
XXXXXXXX+XXXX GUIアプリ ソースブック.key
XXXXXXXX=XXXX XXXアプリ ソースブック.key
のパターンで、以下のAppleScriptを実行すると100%クラッシュが発生。スクリプトエディタでもScript Debuggerでもスクリプトメニューでも100%クラッシュ(実行プログラムのクラッシュ)します。
逆に、
AppleScript+Xcode GUIア.key
AppleScript+Xcode GUIアプ.key
AppleScript+Xcode GUIアプリ.key
AppleScript+Xcode GUIアプリ ソース.key
AppleScript+XCODE GUアプリ ソースブック.key
GUIアプリ ソースブックのコピー.key
ではクラッシュが発生しません(なんでや?)。
なんでこの組み合わせでクラッシュが発生するのか、macOS 10.12の時代に発生していた「日本語IMからのファイル名の入力時に余計なUnicode文字が入ることで、ファイル処理できなくなるバグ」の再現かと考え、このファイル名をテキストエディタにコピー&ペーストで表示させたものの、

とくに謎のゴミ文字が入力されているということはないようです。
ちなみに、「AppleScript+Xcode GUIアプリ ソースブック」は企画検討中の電子書籍です。
| AppleScript名:Crash Test Script_Keynote.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2025/04/19 — – Copyright © 2025 Piyomaru Software, All Rights Reserved — tell application "Keynote" tell front document set curFile to (file of it) end tell end tell set curFile to curFile as alias |
| AppleScript名:Crash Test Script_PAGES.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2025/04/19 — – Copyright © 2025 Piyomaru Software, All Rights Reserved — tell application "Pages" tell front document set curFile to (file of it) end tell end tell set curFile to curFile as alias |
| AppleScript名:Crash Test Script_Numbers.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2025/04/19 — – Copyright © 2025 Piyomaru Software, All Rights Reserved — tell application "Numbers" tell front document set curFile to (file of it) end tell end tell set curFile to curFile as alias |
| AppleScript名:Crash Test Script_Pixelmator Pro.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2025/04/19 — – Copyright © 2025 Piyomaru Software, All Rights Reserved — tell application "Pixelmator Pro" tell front document set curFile to (file of it) end tell end tell set curFile to curFile as alias |
| AppleScript名:Crash Test Script_CotEditor.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2025/04/19 — – Copyright © 2025 Piyomaru Software, All Rights Reserved — tell application "CotEditor" tell front document set curFile to (file of it) end tell end tell set curFile to curFile as alias |
| AppleScript名:only choose file.scpt |
| set aFol to (choose file) as string set anAlias to aFol as alias |
ファイルのドラッグ&ドロップを受け付ける「ドロップレット」の異常動作がmacOS 10.12からずっと続いてきました。AppleScriptドロップレットに対して(Finderから)ファイルをドラッグ&ドロップすると、欠落するものが出てくるという現象です。
昨年、macOS 15.2betaか15.1あたりでこのバグが解消されたように見えました。
「見えました」というのは、一応現象としては観測できつつも、その動作を意図して実現していないんじゃないか、という懸念があったためです。つまり、Appleの現場なりマネージャー級で意思決定が行われた成果ではなさそうだ、と判定。
この動作がmacOS 15.5βで以前と同様の動作に戻っている(バグ的な動作)ことを観測しています。
on open droppedFiles
set fileCount to count of droppedFiles
display dialog “ドロップされたファイルの数: ” & fileCount buttons {“OK”} default button 1
end open
一応、ドラッグ&ドロップされたファイル/フォルダの受付で取りこぼしが出ないように対策は(Scripter側で工夫して)できているのですが、上記のように一般に知られている単純な受信コードでは対処できません。
ChatGPTをはじめとするLLMでは、上記のような単純なコードを出力することを確認しています。そして、Apple側がOSに不具合を発生させた場合にはLLMが出力するコードでは対処できません。
そして、macOSのヘルプメニューから表示できる「AppleScriptヘルプ」に書かれているドロップレットのコードがまともに動かないというのでは、話になりません。

GUIアプリのステータスメニュー上に置いたアイコン>メニューからアプリ本体のウィンドウをアクティブにできないという問題が発生していました。
macOS 13、14、15とずーーっとこの動作なので、全世界的に困らされている状況があって……久しぶりにXcodeでGUIアプリをAppleScriptで作って、この問題に例外なく自分も悩まされていました。macOS 15.2上ではこれで動いていたのですが、
edama2さんから情報を教えていただき、ここで用いていた「activateIgnoringOtherApps」がmacOS 15.2でDeprecated扱いになったとのこと。
ただ、Appleのdocumentで紹介されていたNSApplicationのactivate()メソッドを使っても、この場合にはまともに動作しませんでした。代替手段を紹介しておきながら、それがまともに動かないというのはいかがなものでしょう。
昨今のWWDCでは、さっぱり地に足のついた情報が紹介されておらず、見るだけ時間の無駄といった印象を持っています。あてにならない大本営発表ばかりではなく、まともな情報を期待したいところですが、それは難しいところなのでしょうか。
一応、AppleScriptのactivateコマンドが動作するようになったので(macOS 14ではactivateでも最前面に持っていけませんでした)、そのように修正を行いました。
–> Download process Control test Project
| AppleScript名:AppDelegate.applescript |
| — — AppDelegate.applescript — process Control test — — Created by Takaaki Naganoya2 on 2024/11/01. — — script AppDelegate property parent : class "NSObject" — IBOutlets property theWindow : missing value property NSMenu : a reference to current application’s NSMenu property NSMenuItem : a reference to current application’s NSMenuItem property NSStatusBar : a reference to current application’s NSStatusBar property NSVariableStatusItemLength : a reference to current application’s NSVariableStatusItemLength on applicationWillFinishLaunching:aNotification my initializeMenu:(aNotification) end applicationWillFinishLaunching: on applicationShouldTerminate:sender return current application’s NSTerminateNow end applicationShouldTerminate: on clicked:aSender my activateMe:(me) set aTag to (tag of aSender) as integer –Important!! set aTitle to (title of aSender) as string if aTag is in {41, 42, 43, 44, 45, 46} then –my activateMe:aSender current application’s NSApplication’s |activate| else if aTag = 100 then display dialog "Clicked" end if if aTitle = "Quit" then quit end clicked: on activateMe:aSender –macOS 13から15.0あたりまでactivateができなかった(多分バグ) –current application’s NSApplication’s |activate| tell current application to activate –theWindow’s makeKeyAndOrderFront:(me) theWindow’s orderFrontRegardless() end activateMe: –Status Menu Structure on initializeMenu:aSender set aList to {"Piyomaru", "Software", "", "Function", {"1", "2", "3", "4", "5"}, "", "Quit"} set aStatusItem to current application’s NSStatusBar’s systemStatusBar()’s statusItemWithLength:(current application’s NSVariableStatusItemLength) aStatusItem’s setTitle:" TEST " aStatusItem’s setHighlightMode:true aStatusItem’s setMenu:(createMenu(aList) of me) end initializeMenu: on createMenu(aList) set aMenu to current application’s NSMenu’s alloc()’s init() set aCount to 10 set prevMenuItem to "" repeat with i in aList set j to contents of i set aClass to (class of j) as string if j is equal to "" then set aMenuItem to (current application’s NSMenuItem’s separatorItem()) (aMenu’s addItem:aMenuItem) else if (aClass = "text") or (aClass = "string") then if j = "Quit" then set aMenuItem to (current application’s NSMenuItem’s alloc()’s initWithTitle:j action:"clicked:" keyEquivalent:"") else set aMenuItem to (current application’s NSMenuItem’s alloc()’s initWithTitle:j action:"clicked:" keyEquivalent:"") end if (aMenuItem’s setTag:aCount) (aMenuItem’s setTarget:me) (aMenu’s addItem:aMenuItem) set aCount to aCount + 10 copy aMenuItem to prevMenuItem else if aClass = "list" then –Generate Submenu set subMenu to current application’s NSMenu’s new() (aMenuItem’s setSubmenu:subMenu) set subCounter to 1 repeat with ii in j set jj to contents of ii set subMenuItem1 to (current application’s NSMenuItem’s alloc()’s initWithTitle:jj action:"clicked:" keyEquivalent:"") (subMenuItem1’s setTarget:me) (subMenuItem1’s setTag:(aCount + subCounter)) (subMenu’s addItem:subMenuItem1) set subCounter to subCounter + 1 end repeat end if end if end repeat return aMenu end createMenu end script |
オープンソースのPDFリーダー「Skim」のバージョン1.7.6において「open location」コマンドが実装されましたが、実際に試してみると動きません。確認は最新版の1.7.7で行いました。
これまでにも追加したコマンドを次のバージョンで廃止して、翌々バージョンで復活させたりと、いろいろその歴史をひもとくと「おっとっと」な動きが見られるので、そういうものなんでしょう。
本Blog上に存在するPDFのURLを指定。open locationでダウンロード+表示を試みるものの、表示されずにエラーになる。
→ Skimが「http://」をサポートしていないとのこと。https://からのダウンロードおよび表示は確認しました。
| AppleScript名:Skim v17.6で追加されたopen locationのテスト.scpt |
| set aURL to "http://piyocast.com/as/wp-content/uploads/2018/09/GUNDAM-UI.pdf"
tell application "Skim" set erRes to (open location aURL with error reporting) end tell |
# 本記事は、AppleScriptをCocoaを呼び出す際にRosettaを必要とする、という意味ではありません。
# macOSがデフォルトで用意しているランタイム環境のうちのひとつ、スクリプトエディタのテンプレートから
# 作成可能な「Cocoa-AppleScript Applet」という特殊なランタイムについての情報です。
# AppleScriptがCocoaを呼び出すためにRosettaが必要ということは絶対にないことを明記しておきます
macOS 13.6以降、スクリプトエディタに備わっているテンプレート「Cocoa-AppleScript Applet」から作成したアプレットが動作しなくなっていました。macOS 15.2Betaでもこの状況は変わりません。

▲スクリプトエディタ>ファイル>テンプレートから新規作成>Cocoa-AppleScript Applet.app を選択

▲Cocoa-AppleScript Appletのテンプレートで新規作成したところ

▲Cocoa-AppleScript Appletを作成して実行すると、このような警告ダイアログが表示される
通常のアプレットやScript Debuggerで作成したEnhanced Appletなどもあるため、致命傷ではないのですが……Scripter側でCocoaの利用経験がたまってきたために、「アプリケーション」という実行環境のさまざまなイベントを利用したいという声が出てきて、ようやくCocoa-AppleScript Appletが再評価されつつあった矢先の出来事でした。
# Cocoa-AppleScript Appletを使っているScripterなんて、edama2氏しか知りません
Appleにもバグレポートしているのですが、一向に直りません。そんな中、MacScripter.netにてred_menace氏が報告したところによると、「Rosettaをオンにして動かすと、動く」とのこと。なんの冗談だろうと疑いながら……
ためしに、Cocoa-AppleScript AppletをRosettaをオンにしてx64コードで動かすと、本当に動きました。これは驚きです。
ARM64Eバイナリが存在していないのかチェックしてみたら、
me@m1mini ~ % file /Users/me/Desktop/名称未設定Cocoa-AppleScript\ Applet.app/Contents/MacOS/CocoaApplet
/Users/me/Desktop/名称未設定Cocoa-AppleScript Applet.app/Contents/MacOS/CocoaApplet: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/Users/me/Desktop/名称未設定Cocoa-AppleScript Applet.app/Contents/MacOS/CocoaApplet (for architecture x86_64): Mach-O 64-bit executable x86_64
/Users/me/Desktop/名称未設定Cocoa-AppleScript Applet.app/Contents/MacOS/CocoaApplet (for architecture arm64e): Mach-O 64-bit executable arm64e
そういうわけではないようです。このことから、Appleの現場ではApple Siliconで動作チェックを行なっていないか、チェック自体を行なっていないか、文字が読めないようです。
macOS 15.2 Beta(24C5079e)において、以前本BlogでレポートしていたスクリプトエディタでFinderやスクリプトエディタ自身のAppleScript用語辞書をオープンできない問題が解消されていることを確認しました。
ただし、本問題は再発する可能性が高いものと見ています。電子書籍「AppleScript最新リファレンス v2.8対応」のmacOS 15向けの改修を行なっていますが、
「macOS 15でFinderのAppleScript用語辞書を閲覧できない件」についての対処方法の追加記事が無駄になったことは、喜ばしいことなのでしょうか。きっと、再現して必要になるのでは? と思っているものです。
スクリプトエディタのコンテクストメニューに、絵文字を使ったファイル名のAppleScriptやフォルダが複数回表示されるバグの場合にも、Betaで修正を知らされてもRelease版では直っていなかったため、複数プロジェクト間で矛盾した設定や処理が行われていること自体が解消されてこなかったのでしょう。
Appleの会社組織が極度に縦割り化されているため、チーム間の連携とかチーム間にまたがる問題がいっこうに解決されないといった問題が発生しており、Aチームで修正を行っても他のBチームやCチームでは以前どおりの処理を行なってAチームの修正が無駄になるといった話を散々目撃してきました。
macOS 15.2betaにおいて、macOS標準搭載アプリ「写真」(Photos.app)の表示用バージョン番号が誤って「1.0」と記載されています。macOS 15 Betaの段階では「10.0」と記載されていたので、Release後にバージョン番号がおかしくなったのでしょう。
実際にAppleScriptからバージョンを求めても、”1.0″が返ってきます。
| AppleScript名:macOS 15.2betaでPhotosのバージョンを間違っている検証 |
| tell application "Photos" version –> "1.0" end tell system version of (system info) –> "15.2" |
なお、これまでの写真.appのバージョン履歴は以下のようになっています。
macOS上のアプリのバージョン記述ミスについては、これまでにも何度か発生しており、有名なところではmacOS 13上の「連絡先」(Contacts)がバージョン2539といった謎表記になっていることが知られています(おそらくこれはビルドNo.で、バージョン記述するのを忘れたままになっていたのでしょう)。
自社アプリがApp Storeの審査を通れないのでは? それ以前に、バージョン管理してるんでしょうか????
GUIアプリを作ったときに、ステータスメニュー上に置いたアイコン>メニューからアプリ本体のウィンドウをアクティブにできないという問題が発生しています。
macOS 13、14、15とずーーっとこの動作なので、全世界的に困らされている状況があって……久しぶりにXcodeでGUIアプリをAppleScriptで作って、この問題に例外なく自分も悩まされていました。
その解決を行ったAppleScriptプロジェクトです。macOS 13.7.1上でXcode 15.2で試しています。
# 本記事投稿後にプログラムの見直しを行い、掲載リストおよびXcodeプロジェクトの差し替えを行いました。
GUIアプリ内から生成したステータスバー上のステータスアイテム。ステータスアイテムからメニュー表示。表示されたメニューから項目選択でメインウィンドウを最前面に表示する。
tell current application to activate
では何も起こりません(macOS 12まではこれで大丈夫だった)。
そういう操作を行なってもメインウィンドウが最前面に表示されず、メインウィンドウを強制的にアクティブにするようなコードを入れても、「UIがないプロセスから他のプロセスをアクティブにできない」といったワーニングが表示されるだけで、何も起こりません。
メチャクチャ困ります。
そこで、edama2さんに相談していろいろ試してみたところ、強制的にGUIアプリを最前面に持っていけました。
こちらの議論を参考にしています。
on activateMe:aSender
theWindow's makeKeyAndOrderFront:(me)
theWindow's orderFrontRegardless()
end activateMe:
当初、ウィンドウの生成を動的に行なっていましたが、その部分を削除しても動作することを確認できたため、削除しています。
なお、macOS 15.2+Xcode 16.1でビルドして実行してみたら、「tell current application to activate」だけでウィンドウを最前面に持っていけています。ここで紹介している処理は、macOS 13、14で同様の処理ができるように必要になってしまうようです。
macOS 13/14(+15.0〜15.1?)のバグと言って差し支えないでしょう。
| AppleScript名:AppDelegate.applescript |
| — — AppDelegate.applescript — process Control test — — Created by Takaaki Naganoya2 on 2024/11/01. — — script AppDelegate property parent : class "NSObject" — IBOutlets property theWindow : missing value property NSMenu : a reference to current application’s NSMenu property NSMenuItem : a reference to current application’s NSMenuItem property NSStatusBar : a reference to current application’s NSStatusBar property NSVariableStatusItemLength : a reference to current application’s NSVariableStatusItemLength on applicationWillFinishLaunching:aNotification my initMenu:me end applicationWillFinishLaunching: on applicationShouldTerminate:sender return current application’s NSTerminateNow end applicationShouldTerminate: on clicked:aSender my activateMe:(me) set aTag to (tag of aSender) as integer –Important!! set aTitle to (title of aSender) as string if aTag is in {41, 42, 43, 44, 45, 46} then my activateMe:aSender else if aTag = 100 then display dialog "Clicked" end if if aTitle = "Quit" then quit end clicked: on activateMe:aSender current application’s NSApp’s activateIgnoringOtherApps:(true) theWindow’s makeKeyAndOrderFront:(me) theWindow’s orderFrontRegardless() end activateMe: –Status Menu Structure on initMenu:aSender set aList to {"Piyomaru", "Software", "", "Function", {"1", "2", "3", "4", "5"}, "", "Quit"} set aStatusItem to current application’s NSStatusBar’s systemStatusBar()’s statusItemWithLength:(current application’s NSVariableStatusItemLength) aStatusItem’s setTitle:" TEST " aStatusItem’s setHighlightMode:true aStatusItem’s setMenu:(createMenu(aList) of me) end initMenu: on createMenu(aList) set aMenu to current application’s NSMenu’s alloc()’s init() set aCount to 10 set prevMenuItem to "" repeat with i in aList set j to contents of i set aClass to (class of j) as string if j is equal to "" then set aMenuItem to (current application’s NSMenuItem’s separatorItem()) (aMenu’s addItem:aMenuItem) else if (aClass = "text") or (aClass = "string") then if j = "Quit" then set aMenuItem to (current application’s NSMenuItem’s alloc()’s initWithTitle:j action:"clicked:" keyEquivalent:"") else set aMenuItem to (current application’s NSMenuItem’s alloc()’s initWithTitle:j action:"clicked:" keyEquivalent:"") end if (aMenuItem’s setTag:aCount) (aMenuItem’s setTarget:me) (aMenu’s addItem:aMenuItem) set aCount to aCount + 10 copy aMenuItem to prevMenuItem else if aClass = "list" then –Generate Submenu set subMenu to current application’s NSMenu’s new() (aMenuItem’s setSubmenu:subMenu) set subCounter to 1 repeat with ii in j set jj to contents of ii set subMenuItem1 to (current application’s NSMenuItem’s alloc()’s initWithTitle:jj action:"clicked:" keyEquivalent:"") (subMenuItem1’s setTarget:me) (subMenuItem1’s setTag:(aCount + subCounter)) (subMenu’s addItem:subMenuItem1) set subCounter to subCounter + 1 end repeat end if end if end repeat return aMenu end createMenu end script |