System security is tightened significantly in macOS 10.14 Mojave, and the impact on AppleScript is significant. Before you upgrade you should familiarize yourself with the new rules, not least because in some cases you may want to make changes to existing scripts first.

The changes affect three main areas and will have an impact on all scripters, to varying degrees. This summary is based on what we have found so far, and there may be other smaller issues. We will try to keep this article up-to-date if other issues emerge.

Farewell Scripting Additions

Scripting additions other than Apple’s Standard Additions (i.e. those located in /System/Library/ScriptingAdditions) will be practically unusable in Mojave. The additions, and their terminology, simply will not be loaded. If you open an existing script that uses a command from another scripting addition, the command will instead appear in raw chevron-style form («event ABCDEFGH»). If you run an applet that uses such a command, it will fail — quite possibly without any error message.

This is something that has been hinted at for a long time. Apple began discouraging developers from writing additions some time back, first encouraging them to consider writing scriptable faceless background applications instead. They have progressively introduced security restrictions on how addition commands can be used, and with the introduction of script libraries that can access Objective-C frameworks and include their own scripting dictionaries, it became a question of joining the dots and wondering when, not if.

Nonetheless, there has been no formal direct announcement, so this will come as a shock — and pain point — for some users. If you use third-party additions, you will need to start looking elsewhere for equivalent functionality. Either AppleScriptObjC or some of the publicly available script libraries offer similar abilities to some of the commonly used commands, and it’s possible some addition authors will offer equivalent or similar functionality in faceless background applications or script libraries.

So why “practically” unusable? An applet will still be able to load a scripting addition if it is within the applet’s bundle, rather than in /Library/ScriptingAdditions or ~/Library/ScriptingAdditions. It must be within a folder called “Scripting Additions” (note the space) within the applet bundle’s Resources directory, it must be code-signed, and the enclosing applet must also be code-signed with the same signing identity

If you have an existing script applet that relies on a scripting addition, you can, subject to any licensing conditions, code-sign and embed a copy of the addition within its bundle. But you would need to do this before you upgrade. Once you have it on a Mojave system, you will no longer be able or edit or test the script in Script Debugger (or any other script editor), because editors are unable to load additions from outside their own bundles.

So at best, you should probably consider embedding as a temporary fix.

Permission to Speak

Anyone who has done any interface scripting via System Events will be aware that applets need to be given permission to do so. These rights are controlled in the Privacy tab of the System Preferences Security & Privacy panel, under the heading of Accessibility.

As of Mojave, applications (including applets and third-party script editors) will require permission to send Apple events to other applications. The first time an app tries to script another application, the user will be asked to approve it. The app, and any target applications, will then be listed in the same panel of System Preferences, under the heading of Automation.

Script Debugger’s Dictionary Explorer works by sending Apple events, so if that is the first place you deal with a particular app, you will be asked for permission before exploring can proceed.

As with interface scripting, permission will be sought again any time the script is modified, whether as the result of editing, or changes to the value of persistent top-level properties. The exception to this is when the applet has been code-signed — in that case the script can be edited without requiring further authorization (provided the bundle identifier and signing identity remain unchanged).

If you do not give approval, future attempts to script that application will fail, generating an error -1743. Once you have declined, you will not be prompted a second time. To change your mind, you need to go to System Preferences and make the change there by checking (or unchecking) the appropriate checkbox. (You may also need to quit and relaunch the application before changes take effect.)

As a practical matter, if you distribute scripts you might want to include attempts to script any of the target applications near the beginning of your script [1], so users receive all prompts at once, and so you can bail-out gracefully if permission is not granted. There is no way to pre-authorize an application in System Preferences.

Framework Limitations

Apple’s Script Editor does not need to request permission before talking to another application, whereas Script Debugger, being a third-party application does. However, Script Editor has a more significant limitation when it comes to frameworks.

Script libraries can contain embedded Objective-C frameworks, providing them with extended functionality. Myriad Tables.scptd is an example of this, and there are others. However, in Mojave, Script Editor is unable to run scripts that use such libraries, because it refuses to load external code. Apple’s built-in Scripts menu has the same limitation.

Script Debugger has no such limitation, and neither does FastScripts. Importantly, applets also escape this limitation, even if saved from Script Editor.

Note that this only applies to script libraries that address third-party frameworks, not those that use the standard Cocoa libraries.

Permission to Poke Around

Certain system directories have been off-limits for some time, and in Mojave Apple is introducing tighter restrictions even for some user directories. Applications, including script applets and script editors, will not be able to access many such directories unless the user specifically grants them permission.

This includes a wide range of subdirectories of the Home directory and ~/Library. It means Mail and Safari files, as well as many settings files.

Users can grant applications access to these files in the System Preferences Security & Privacy panel, this time under the heading of Full Disk Access. There are + and – buttons, which you can use to add or remove applications from the list.

However, unlike the Automation setting outlined above, an application cannot prompt for this permission. This access cannot be authorized in a dialog, only in System Preferences. Failure to give this access will result in scripts throwing an error number 1 (“Operation not permitted.”)

If you do not grant Script Debugger this access, you will also not be able to write or test scripts that require this access. It will also restrict how certain functions work, for example, Open Quickly.

If you use other utility applications like FastScripts to run scripts, you will need to grant them similar access. (For many users, the number of applications requiring Full Disk Access for unrestricted functionality is likely to be large.)

Workarounds and Trouble-Shooting

Most of the new restrictions are an extension of the System Integrity Protection scheme first introduced in macOS 10.11 El Capitan. It is possible to disable SIP, in which case many of the above restrictions will not apply. (The requirement for approval to send events is handled separately, and cannot be disabled.)

There have also been reports where settings are not working as expected. If you think this may have happened, you can reset to default settings using the command line tool tccutil. To reset the Automation privileges, run this in Terminal:

tccutil reset AppleEvents

To reset the Full Disk Access privileges, run this:

tccutil reset SystemPolicyAllFiles

These commands are all-or-nothing — you cannot remove the privileges for just one application.

[1] – If its not convenient to restructure your script, you can send a query AppleScript command such as count windows or count documents which has no impact on the application’s state in order to trigger the system’s prompt for permission to interact with a target application.

For information on how these changes affect Script Debugger, see here.