More of a Technical Issue, Rather Than a Script Issue

This is more of a technical question rather than a script question. But, I’m wondering if anyone here has ever run into a similar issue, or if possibly I’m just dealing with macOS system issues and it’s time to reformat and reinstall macOS on my 2020 M1 MacBook Pro. Side note: None of these issues show up on my Intel 2014 Mac mini (both systems are running Monterey 12.6.8).

I’ve had issues (on the M1 MacBook Pro) that I posted here (Script Error Issue Question), where a script saved as an application by Apple’s Script Editor would result in an error, but the exact same script saved as an application by Script Debugger, would not throw the error.

Today I received a different error (see image), but it’s the same situation as above. This script (posted by peavine in post #30 here (Help Learning AppleScript)) saved as an application by Apple’s Script Editor results in this error, but the exact same script saved as an application by Script Debugger, does not.

I’ve included screen shots of the Get Info windows of both the Script Editor saved application and the Script Debugger saved application, just in case they may be of help.

I guess I could just continue on, making sure that any script applications that I run on the MacBook Pro are saved in Script Debugger, but thought I’d post this in case there is an easy explanation.
Saved By Script Editor
Saved By Script Debugger

Hey Homer,
you mentioned something regarding a resource or book for Applescript and awhile back, I came across this book. I quickly skimmed through it at book store. Looked good from what I saw.


Apple Training Series: AppleScript 1-2-3, 1st Edition. by Sal Soghoian and Bill Cheeseman.

Hi Homer712.

I’ve just leapfrogged several macOS versions from Mojave to Ventura, so I can’t say for certain if the following applies to Monterey. But it probably does.

The values of properties, globals, and “top level” variables (ie. variables set in the implicit or explicit run handler) are considered to be persistent properties of a script. In a script which actually runs (as opposed to being loaded as a library), the values of these variables are saved back to the script file at the end of each run. This changes the script file’s modification date, and probably its size and contents. Where the script’s been saved as an application, this could cause macOS’s security system to see the application either as a new one or one that’s been interfered with since it was last authorised to do something with security implications.

I seem to remember Shane saying that scripts saved from Script Debugger have some sort of setting which prevents “persistent” variables from being persistent. This could explain why applications saved from Script Debugger aren’t giving you the problem you’re seeing.

Otherwise possible solutions are not to save the scripts as applications, but to run them from, say, the system Script Menu, which then becomes the responsible application. In addition to this, I personally try wherever possible (and sensible) to use only local variables. These are variables which are explicitly declared as local or which are set and used inside ordinary handlers and aren’t declared as globals or properties at the top of the script. The easiest way to arrange this is to put the code you’d normally have in the run handler (or not visibly in a handler) into an ordinary handler and just have a call to that handler in the run handler. So instead of …

set fred to 7
set bill to 8
add(fred, bill)

on add(n1, n2)
	return n1 + n2

… you’d have:


on main()
	set fred to 7
	set bill to 8
	add(fred, bill)
end main

on add(n1, n2)
	return n1 + n2
end add

I wrote such a book about AppleScript.

AppleScript BASIC technics (29) Unlock Security Limitations

This book is written in Japanese and has 31 books.

Thanks, I was able to find it online, and you are correct, is seems to be aimed directly at us beginners.

Thanks, I tried a couple of things based on the information you provided.

  1. Even though the application created in Script Editor throws the error, running the script from within Script Editor does not, the script runs successfully.
  2. When the Script Menu is added to the menu bar and the script is run from there, it also runs successfully.

So, I think I’m going to chalk this up to one of those macOS mysteries that, although it now has a few workarounds, will possibly never be fully explained.

1 Like

I’m on Ventura now, but I’ve encountered Privacy & Security issues with AppleScript apps on Monterey as well. I’ve attempted to determine what causes such issues but never could establish a clear pattern. Saving an AppleScript app with Script Debugger usually fixed matters, and, as a last resort, I create a new AppleScript app with the same code but a different name.

The reliable solution, as Nigel suggests, is to run AppleScripts as scripts whenever possible. Unfortunately, there are occasions where an app is required and a script won’t do the job.

BTW, Script Debugger has Bundle & Export settings, and I wonder if these make any difference?

I’m trying my best to not get overwhelmed by Script Debugger. In addition to what you posted, its Preferences include: General, Editor, Text Substitutions, Themes, Execution, Building, Dictionary, Key Bindings, and Software Update.

So far, I’ve left everything at the default settings. It’s working, I’m learning and I have no immediate need to rock the boat. :grin:

FWIW, I’ve quoted below from Script Debugger help, although I don’t know if this is pertinent to the matter at hand.

Code Sign Apps. This popup menu lets you choose to sign applets using one of the valid signing identities stored in your login keychain. When running under a version of macOS before Big Sur, the first option is Do Not Sign, allowing you to turn off signing altogether. If you are running Big Sur or later, applets will be saved as universal Intel/Apple silicon versions, and will therefore require signing. In this case the first option will be Sign to Run Locally, meaning applets will be signed, but with no signing identity specified.

This apply to Monterey.

When you make applet (with name openLibrayFolder) in Script Editor that use ex. System Events. When you run this applet for the first time you will get a dialog. It will ask you or give your information what it like to do. When you have accept it.

If you set the checkbox to false in above image you will get a dialog image below.


It means the user do not have authorised to send Apple events to System Events.

If you set the checkbox to true the applet will work.

If you delete the applet it will also be gone from Automation in Security & Privacy.
If you move the applet or update it could be that you need to do this again.
The best practices I think in Script Editor is to export to applet instead of save… → applet
In other words the orginal code is your_applet_name.applescript and use export.

I also use sign to run locally

I checked on my Ventura computer, and Script Editor does have an option to “Sign to Run Locally” when exporting an AppleScript app. I agree that this seems a good practice.

Unfortunately, AppleScript apps that use System Events typically will not run on my computer and instead issue the not-authorized dialog. I exported my test app and added System Events to Accessibility but that didn’t make a difference. I finally got my test AppleScript app to run without error by deleting it from Accessibility and then doing a drag-and-drop of the app on the Accessibility pane. I think that was just a one-off, though.

FYI, there is a forum dedicated to Script Debugger for users of all experience levels.

Any learning curve questions you have will be promptly answered there.

Thanks, next stop will be to register there as well.