Xcode 13.2がリリースされ、賛否両論いろいろ意見が出されていますが、自分にとっては有害であり、Betaの段階でバグレポートを出していましたが、修正されずにリリースされました。
Interface Builder上でApp Delegateを選択してもScriptコード内のイベントハンドラが認識されないため、インタフェースのアクションとコードのひもづけが行えません。
▲左：Xcode 9.xで作ったAppleScriptのプロジェクトをXcode 13.2でオープンしたもの、右：Xcode 13.2上でゼロから作ったAppleScriptのプロジェクト XIB上でAppDelegateのイベントハンドラを追加できず、GUI部品の操作に対応するハンドラのひもづけができない
もはや「またか？」というぐらい何度も発生しているバグであり、責任者に知性が欠如しているのではという疑いを持たずにはいられません。
＃ Xcode 13.3が正式リリースされましたが、相変わらず使えません
目下、最大の関心事はmacOS 11向けにXcode上のCocoa AppleScriptアプリケーションをApple Sillicon & IntelのUniversal Binaryでビルドする方法についてです。
まず、Xcode 12と言われるものは２系列存在しています。Xcode 12.1GMと呼ばれるものと、Xcode 12.2Beta 3です。
調査前には、「Xcode 12.1GMを使ってビルドするんじゃないの？ GMだし」と思っていました。Mac App StoreはReleaseビルドのXcodeからのアプリケーション送信しか受け付けない仕様になっているため、Beta版の出来がいくらよくても、GM版、Release版が必須です。
ただ、Xcode 12.1GMでCocoa AppleScriptアプリケーションをUniversal Binaryでビルドしようとしても、出来上がるバイナリはIntel 64bit向けのみです。
だいたい、Xcode 12.1GM上ではビルドターゲットとして「macOS 11.0」を選択できません。
これまでにARM/IntelのUniversal Binaryビルドできたのは、Xcode 12.2Beta2。GM版ではどれもビルドできていません。
実際に、Xcode 12.2Beta3上でCocoa AppleScriptアプリケーションのプロジェクトをUniversal Binaryビルドできることが確認できました。
ただし、Xcode 12.2beta3上でも、既存のXcodeプロジェクトではUniversal Binaryビルドが行えず、新規作成したプロジェクト（コードはほぼからっぽの状態でテスト）でのみUniversal Binaryビルドできました。まだ、既存のプロジェクトのUniversal BinaryビルドができないあたりがBetaっぽいですが、注意を要するところです。
スクリプトエディタから書き出したアプレットは、macOS 11.0Beta初期からUniversal Binaryで書き出されていることを確認しています。
その他、Mac OS X 10.6で廃止になった「AppleScript Studio」のランタイムがXcode上の開発テンプレート廃止後も実行のみサポートが継続されています。
これはAutomator登場初期に作られたAutomatorアクションがこのAppleScript Studioのランタイムを利用していたためです。
Automatorアクションの実行サポートのためにAppleScript Studioのランタイムが最新OS上でも維持され続けてきました。先日、ついにこのAppleScript Studioランタイムの将来的な廃止がAppleのWebサイトに掲載されていました。
AppleScript StudioランタイムのARM Binary（ここも、Xcode上で「ARM」という言葉を使わないようにいろいろ記述が変わっている）化を行なっているとは思えないので、おそらくARM/Intelの両方のCPUサポートを３〜４年ぐらい行い（AppleScript StudioランタイムはRosetta2で実行？）、Rosettaの廃止ライミングでAppleScript Studioランタイムも一緒に廃止するのでしょう。
AutomatorアクションのAppleScriptによる開発テンプレートはAppleScriptObjCベースのものに（とっくの昔に）変更になっています。AppleScriptObjCベースで開発していれば問題ありません。
Xcode 12GMではビルドできなくなっていたIntel/ARM Universal Binaryが、Xcode 12.2betaでビルドできることを確認しました。
このビルドの確認は、AppleScript Cocoaアプリケーションのプロジェクトのビルドで行い、生成されたバイナリにIntel/ARMアーキテクチャのバイナリが含まれていることが確認できました（fileコマンドでUniversal Binaryを確認。ARM Mac実機上での実行確認は行っていません）。
me@MacMini2014 ~ % file /Users/me/Library/Developer/Xcode/DerivedData/asTest3-delafurpjctyxkasofeysytgsiny/Build/Products/Release/asTest3.app/Contents/MacOS/asTest3 /Users/me/Library/Developer/Xcode/DerivedData/asTest3-delafurpjctyxkasofeysytgsiny/Build/Products/Release/asTest3.app/Contents/MacOS/asTest3: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] /Users/me/Library/Developer/Xcode/DerivedData/asTest3-delafurpjctyxkasofeysytgsiny/Build/Products/Release/asTest3.app/Contents/MacOS/asTest3 (for architecture x86_64): Mach-O 64-bit executable x86_64 /Users/me/Library/Developer/Xcode/DerivedData/asTest3-delafurpjctyxkasofeysytgsiny/Build/Products/Release/asTest3.app/Contents/MacOS/asTest3 (for architecture arm64): Mach-O 64-bit executable arm64
Mac App StoreではBeta版のXcodeからのバイナリ提出を認めていないため、Universal Binary版のAppleScriptアプリケーションをMac App Storeに提出するためには、このXcode 12.2正式版のリリースを待つ必要があることでしょう。
現時点で先行して、macOS 11.0 Big Sur対応をIntel Mac向けのみで（ARMバイナリなしで）行うことは不可能ではありませんが、あまり意味がないことでしょう。まだRelease前ということもあって、Betaごとに仕様が変わってきています。とくにGUIまわりで。細かなバグもBetaごとに異なるものが見られます。
Xcode上でAppleScript Cocoa Applicationをビルドする際に、Build ArchitectureをUniversal Binaryに設定した状態で、Target OSをmacOS 10.13ぐらいに設定して問題がないか（Build条件をしぼられていないか）確認したところ、確認した本バージョン（12.2beta）では大丈夫でした。
補足までに、macOS 11.0, Big Sur上のスクリプトエディタでアプレット書き出しを行い、アプレットがIntel/ARMのUniversal Binaryのランタイムとともに書き出されていることも確認しています。
me@MacMini2014 ~ % file /Users/me/Desktop/appTEST.app/Contents/MacOS/applet /Users/me/Desktop/appTEST.app/Contents/MacOS/applet: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] /Users/me/Desktop/appTEST.app/Contents/MacOS/applet (for architecture x86_64): Mach-O 64-bit executable x86_64 /Users/me/Desktop/appTEST.app/Contents/MacOS/applet (for architecture arm64): Mach-O 64-bit executable arm64
InstrumentsはXcodeに同梱されているメモリ使用状況などの記録、ビジュアル化を行うツールで、アクティビティモニタの強化版といったものです。
監視対象のモジュール（Instruments）を選択してドキュメント上に配置し、監視対象プロセスを選択して記録すると、動作中のプロセスの各種リソース使用状況がわかります。
そのInstrumentsがAppleScriptに対応している（sdefを持っている）ことがわかりました（調べたことがなかった）。
Dock上でXcodeのサブメニューから起動が可能です。
▲macOS 10.14.6上で動作するInstruments version 11.3.1。バージョン番号はインストールされているXcodeと同じものを名乗っているもよう
Instrumentsを使って開発中のアプリケーションのメモリ使用状況を記録して可視化（グラフを眺めるぐらい？）してみると、ダラダラ長時間記録するよりも、目的の箇所で記録を行なったほうが使い勝手がよく、Instrumentで記録した書類が複数できてきます。
それらを選択してオープンするのに、Instruments書類（単なるログ？）はファイルサイズが巨大。これをオープンするとけっこうな処理時間がかかります。Scriptから操作できたほうがよさそうだと考えて、冗談半分でAS対応していないか調べたところ、対応していると出ました。
InstrumentsのAppleScript用語辞書の内容を見てみると、ファイルのオープン/クローズができる程度で、他に何ができるというわけでもありません。
Documentの新規作成ぐらいはできそうですが、試してみたところクラッシュします。新規作成時に、どのリソースを監視するかというモジュール（Instruments）を指定する必要があるので、ドキュメント作成時にこのInstrumentsを指定できないあたりでGUI側との機能の不一致が起こっているのでしょう。
また、ドキュメントを新規作成したあとで、個別にInstrumentsを追加できるコマンドも必要になっていくことでしょう。
| AppleScript名：指定書類をオープン |
| — – Created by: Takaaki Naganoya – Created on: 2020/05/19 — – Copyright © 2020 Piyomaru Software, All Rights Reserved — set aFile to choose file with timeout of 3600 seconds tell application "Instruments" open aFile end tell end timeout |
| AppleScript名：最前面のドキュメントから情報を取得 |
| — – Created by: Takaaki Naganoya – Created on: 2020/05/19 — – Copyright © 2020 Piyomaru Software, All Rights Reserved — tell application "Instruments" tell front document properties –> {file:file "Cherry:Users:me:Documents:Instruments_withoutRetina.trace:", modified:false, name:"Instruments_withoutRetina.trace", class:document} end tell end tell |
| AppleScript名：新規書類作成（クラッシュ） |
| — – Created by: Takaaki Naganoya – Created on: 2020/05/19 — – Copyright © 2020 Piyomaru Software, All Rights Reserved — tell application "Instruments" make new document –This command cause crash end tell |
Xcodeで編集中のAppleScriptのプログラムを構文確認（コンパイルと表記されている、構文チェックと中間コードへの変換チェック、省略表記の展開など）するAppleScriptです。
本ScriptはXcode 9.2＋macOS 10.12.6でテストしたものです。macOS 10.14＋Xcode 10.2で実行したところ、file documentのnameに「– Edited」という入っていてはいけない文字列が入っていたり（それはWindowのtitleであってdocumentのnameじゃないだろう、、、、）、AppleScriptからXcodeを（データ書き込み）操作するとXcodeがクラッシュしたりと、まともに動作していない印象です。
Xcode 10.1＋macOS 10.13.6で動かしたぶんには、Xcode上の表示は更新されていないものの、プロジェクト内の他のファイルをいったん表示させたあとに再度Scriptを表示させると書き換わっていました。Xcode 10.2＋macOS 10.14.4の組み合わせでおかしな動きを行なっているようです。
XcodeのテキストエディタはAppleScriptの構文色分けを反映して表示しませんし、編集中にコンパイル（構文確認）するための機能がありません。インデント合わせやtellブロックやifブロックのネスティングの確認なども行えないため、記述のための最低限の機能を備えておらず、まともにプログラムを書くのであればScript Debuggerの併用は必須といえます。
先日のmacOS Nativeのミーティングにて、プレーンテキストエディタであるCotEditor上に記述したテキストのAppleScriptをコンパイル（構文確認）し、実際に実行して結果をCotEditor上の新規書類に出力するデモを実施。
このデモ内容は、はるかかなた昔から行なってきたものであり、CotEditorにかぎらず、あまねくどんなテキストエディタに対しても実行できるものです。macOS標準搭載のテキストエディットに対してすら同様のScriptを実行できます。
……と、振り返っていたときに、冒頭の「機能が致命的に足りない」Xcodeのテキストエディタのことを思い出したのです。
Xcodeのテキストエディタは（AppleScriptにとっては）致命的に機能が足りない欠陥品ですが、欠陥品には欠陥品なりの扱いをすればよいのではないかと気づきました。Xcodeに対してAppleScriptを実行することで、ソースを取得し、AppleScriptでAppleScriptをコンパイルし、Xcodeに書き戻してやればよいのではないか、と。
ずいぶんと昔に書いたXcode操作のScriptに若干のルーチンを足して動かしてみたところ、想像どおりうまく動きました。
ただし、少々のテストを行なっただけなので、実際にもっと使い込んでみる必要性を感じます。また、Xcode側が不可思議な挙動を行うため、Xcode上でAppleScriptを記述する場合には、依然としてScript Debugger必須です。
ちなみに、XcodeのAppleScriptサポート機能はいまひとつ不思議な挙動を行います。tellブロックでオブジェクト（documentとか）をくくり、その内側でオブジェクトに対する操作を行おうとするとエラー。tellブロックを正常に認識せず、tellブロック内でもそのオブジェクトへの参照を「of it」のように書く必要があります（実は、CotEditorもこのタイプ）。
最近、そのような不思議な挙動を行うアプリケーションがいくつか見られたため、「はいはい。君はof itが必要な人なんだね」と乗り切りましたが、これに気づかないと永遠にXcodeのまともなScriptは書けません。要注意です。
| AppleScript名：最前面のAS sourceを構文確認.scptd |
| — Created 2018-05-19 by Takaaki Naganoya — 2018 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" use framework "OSAKit" property OSAScript : a reference to current application’s OSAScript property OSALanguage : a reference to current application’s OSALanguage property OSALanguageInstance : a reference to current application’s OSALanguageInstance property targX : 1024 –View Width property targY : 2048 –View Height tell application "Xcode" –最前面のWindowの情報を取得 set winProp to properties of front window set aDoc to document of winProp –Xcode のworkspace document（xcodeproj） –> workspace document "WKWebViewDemo.xcodeproj" of application "Xcode" set docProp to properties of aDoc set xcodeDocPath to path of docProp –> "/Users/me/Documents/Objective-C/WKWebViewDemo_MAC-master/WKWebViewDemo.xcodeproj" set aFileDoc to name of winProp –> "ViewController.m" try set aDoc to file document aFileDoc –> source document "ViewController.m" of application "Xcode" on error –Storyboard/Xib file/info.plist/Assetsなどを表示中の場合にはエラーになる return false end try set aDocPath to path of aDoc –> "/Users/me/Documents/Objective-C/WKWebViewDemo_MAC-master/WKWebViewDemo/ViewController.m" end tell if aDocPath does not end with ".applescript" then display notification "Front Xcode document does not seem an AppleScriptObjC source" return end if set theSource to read ((POSIX file aDocPath) as alias) as «class utf8» set aRes to retComiledAppleScriptString(theSource, "AppleScript") of me tell application "Xcode" tell aDoc set text of it to aRes end tell end tell –Compile AppleScript Source on retComiledAppleScriptString(aStr as string, osalangName as string) set osaCon to current application’s OSAScriptController’s alloc()’s init() set osaView to current application’s OSAScriptView’s alloc()’s initWithFrame:(current application’s NSMakeRect(0, 0, targX, targY)) osaCon’s setScriptView:osaView osaCon’s setLanguage:(OSALanguage’s languageForName:osalangName) osaView’s setString:aStr osaCon’s compileScript:(missing value) –Compile（構文確認） set aRes to (osaView’s |string|()) as string return aRes end retComiledAppleScriptString |
Xcodeで編集中のテキストの選択中の範囲のテキストを取得するAppleScriptです。
Xcode v9.2＋macOS 10.12.6およびXcode v9.3.1＋macOS 10.13.5betaで動作を確認しています。
Xcode上で編集中のソーステキストの選択範囲（selected character range）を取得し、さらに実際に選択範囲のテキストを取得しています。
Xcode上でソーステキストではなくXibファイルやplistなどの他のファイルを選択中の場合にはfalseを返します。
また、本Scriptでは個別に独立したWindow上に表示中のテキストについては無視します。
常識的なMacのテキスト編集系のGUIアプリケーションであれば、
①指定パスのテキストをオープンできる
②テキストを指定パスに保存できる
③表示中のテキストの選択範囲のテキストを取得できる
④表示中のテキストの選択範囲の内容を書き換えることができる
という動作は期待したいところですが、Xcodeについては①②が怪しく（Workspace Documentに新規テキストを追加するとかできそうもない）、③はなんとかなったものの、④ができるかどうか試行錯誤してみないとわからない、といったところです（パスを取得できているので、Xcodeを経由しないで直接ファイルを書き換えれば不可能ではなさそうですが、、、）。
AppleScript対応アプリケーションが標準でそなえているopen/close/quit/count/delete/exists/make/moveなどのコマンドをのぞくと、XcodeのAppleScript用語辞書に掲載されているコマンドは、build、clean、stop、run、testの５つだけ。archiveとかのproduct（ビルド後に生成されるバイナリ）を操作するための命令は用意されていません（わざと？）。
| AppleScript名：表示中のソースの選択中の範囲のテキストを取得する v3 |
| — Created 2018-05-19 by Takaaki Naganoya — 2018 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" tell application "Xcode" tell front file document try set selRange to selected character range if selRange = {} or selRange = missing value then return false –No Selection or other copy selRange to {aSelBegin, aSelEnd} set aText to text of it set aSelText to text aSelBegin thru aSelEnd of aText on error return "" –No Selection or other end try return aSelText end tell end tell –> (* " property parent : class ＼"NSObject＼" property NSTimer : class ＼"NSTimer＼"" *) |
Xcodeでオープン中のソースコードのファイルパスを求めるAppleScriptです。
Xcode v9.2＋macOS 10.12.6、Xcode v9.3.1＋macOS 10.13.5betaで確認しました。
おおまかにいえば、Xcodeは大きくわけて２種類の書類を扱っています。１つは、拡張子「.xcodeproj」のXcodeプロジェクト（Workspace）書類。
そして、個別のソースコード書類（SwiftとかObjective-CとかAppleScriptとか）。
そんなわけで、普通のGUIアプリケーションとはdocumentの概念がやや異なり、少々めんどくさい上にXcodeのAppleScript用語辞書に載っている用例自体も「え、そんな書き方を推奨するの？」という、なんとも不思議な仕上がりになっていますが、まあいいんでしょう。
ちなみに、本ScriptはXcodeのメインウィンドウ上でソースコードを表示する場合と、個別のウィンドウで表示する場合に対応しています。
また、Xcodeのウィンドウ上でXibファイルやInfo.plistやアイコンのAssetsなどソースコード書類以外のものを表示している場合には、エラートラップをかけてfalseを返すようにしています。
▲XcodeのAppleScript用語辞書に書かれている記述例。Workspace Documentのオープン完了待ちをpropertyを確認しつつループで待つという仕様。そんなとこ、非同期実行してドーする、という不思議感満載
| AppleScript名：Xcodeでオープン中のソースコードのパスを求める |
| — Created 2018-05-19 by Takaaki Naganoya — 2018 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" tell application "Xcode" –最前面のWindowの情報を取得 set winProp to properties of front window set aDoc to document of winProp –Xcode のworkspace document（xcodeproj） –> workspace document "WKWebViewDemo.xcodeproj" of application "Xcode" set docProp to properties of aDoc set xcodeDocPath to path of docProp –> "/Users/me/Documents/Objective-C/WKWebViewDemo_MAC-master/WKWebViewDemo.xcodeproj" set aFileDoc to name of winProp –> "ViewController.m" try set aDoc to file document aFileDoc –> source document "ViewController.m" of application "Xcode" on error –Storyboard/Xib file/info.plist/Assetsなどを表示中の場合にはエラーになる return false end try set aDocPath to path of aDoc –> "/Users/me/Documents/Objective-C/WKWebViewDemo_MAC-master/WKWebViewDemo/ViewController.m" end tell |
