Script debugger and old applications such as Aperture

AppleScript
#1

Hi,

This is a newbie question to get confirmation of what I have understood.
Could you please confirm that I get it right ?

I purchased Script debugger mainly to allow me to script Aperture, the old Apple photo editing software.
This worked OK until recently, most likely pre-Big Sur upgrade.

Aperture was a 32-bits application. In order to survive the upgrade to 64-bits mandatory status, some smart folks designed an application (called Retroactive) that could replace some 32-bits pieces in the Aperture code and turn it into a 64 bits application.
This went smoothly, prolonging Aperture life in the 64-bits world.
(note that there was no other way to launch the initial 32-bits Aperture anymore)

However, Aperture code having been modified, it is not the same application anymore, and as such is not notarised; and can’t be. Let’s call it ApertureNew.

ApertureNew is still scriptable and can respond to AppleScript events. It has a dictionary that can be displayed. You can still write code with Apple ScriptEditor program and it is functionnal.

With the advent of Big Sur, however, Apple Events needs to be authorized to operate.
By default, being an Apple application, ScriptEditor is authorized, (given maybe the System preferences “system events” authorization ), so this is not a problem. Apple Scripts continue to operate, including on ApertureNew.

However, with other applications relying on Apple events to control ApertureNew, such as Houdah Geo or Script Debugger, they must be explicitly authorized on ApertureNew to work as intended.
And this is were we hit the wall. ApertureNew being non-authorized, there is no way to authorize Script Debugger (or HoudahGeo, or whatever non apple app) 's apple events to control ApertureNew. No option to check in System Preferences/Security/ Confidentiality/Automation interface.

As a consequence, the same Applescript saved as a ScriptEditor document that would work to control ApertureNew, will not work if saved as a Script Debugger document. And cannot either be conceived inside Script Debugger for obvious debugging reasons and lack of dictionary/explorer feature.

So basically Script debugger has become useless for building scripts for ApertureNew.
Not because of Script Debugger fault, but because of Apple.

(Note that I have Script Debugger version 7, but I don’t think it makes a difference)
(Note further, this also applies to other applications 64-bits-enabled by Retroactive, such as iTunes or iMovie, and more generally to any non notarized application)

#2

I don’t believe an app needs to be notarized for another app to be able to send Apple events to it.

Here’s a little test. Put this code in a new document:

on showDialog(x)
	display dialog x as text
end showDialog

and save it as a stay-open applet called “Stay open test.app”. Close it and launch it.

Now open a new script in Script Debugger and enter:

tell application "Stay open test"
	showDialog("Hello")
end tell

When you run this, you should get an authorization dialog. If you click OK, the script should work. If you then look in Preferences → Automation, you should see that “Stay open test.app” has been added to the list of apps Script Debugger can send Apple events to.

So whatever the issue is, I don’t think it’s related to notarization.

#3

You’re right, in that your tests does work.

But anyway the systems refuses to allow ScriptDebugger to send Apple Events to Aperture (or ApertureNew).

With the message error :

AppleScript execution error
Not authorized to send Apple Event to Aperture

If I change the name of the app in the script and explicitly define this application to SD as the aperture app in the finder, I get the same message, with no option to authorize it in system preferences either.

#4

FWIW, I tried using Retroactive with iTunes and it seems to work OK under 10.15. The first time I tried to script it I was asked for permission to send Apple events to bash, which probably makes sense given it works by using a bash script as a binary.

#5

OK. Thanks four your answer, I might have messed with some authorization in the past.

#6

I believe the target application needs a valid code signature for macOS to reliably identify the application and remember that you granted permission to automate.

Retroactive tries, but silently fails, to sign Aperture with an ad hoc certificate. I was able to patch and code sign Aperture. See the comment on issue #160 of the Retroactive Github project.

After that I could grant HoudahGeo permission to automate Aperture.

The steps I needed to perform after processing Aperture with Retroactive were:

cd /Applications/Aperture.app/Contents/Frameworks/AppKit.framework
sudo mkdir Versions/C/Resources/
cd Versions/
sudo ln -s C Current
cd ..
sudo ln -s Versions/Current/Resources Resources
sudo ln -s Versions/Current/AppKit AppKit

sudo /usr/libexec/PlistBuddy -c "Add :CFBundleExecutable string" /Applications/Aperture.app/Contents/Frameworks/AppKit.framework/Versions/C/Resources/Info.plist
sudo /usr/libexec/PlistBuddy -c "Set :CFBundleExecutable AppKit" /Applications/Aperture.app/Contents/Frameworks/AppKit.framework/Versions/C/Resources/Info.plist

codesign -vvv -fs - /Applications/Aperture.app