Some AppleScripts running into Mavericks problems

Dave Nanian at Shirt Pocket, the maker of SuperDuper!, recently pointed out in his blog issues with AppleScripts and the new Mavericks version of OS X. A dialog, unfamiliar to customers, may interrupt the proper running of the script.

Nanian said SuperDuper! 2.7.1 backs up Mavericks "just fine," still, every OS release presents new challenges, and Mavericks is no exception.

As you may know, our scheduling feature runs a little application called "Copy Job" behind the scenes. Copy Job gets launched by the system, figures out what the scheduled copy should be, and then launches SuperDuper! to actually do the copying.

When Copy Job starts, one of the first thing it does is ask the OS whether SuperDuper! is already running. That way, it knows whether or not it should quit it at the end of a successful backup.

For some reason, in Mavericks, this check (and a second one that checks whether Growl is running) now generates a scary security warning that claims Copy Job is trying to strangle kittens or some such—and then doesn't give you an easy way to disable the warning (it's a multi-step, confusing process, as you'll see).

We've found a way around this prompt, but it requires that you delete and recreate your existing schedules. To be blunt, that sucks, I wish it wasn't necessary, and I'm truly sorry for the hassle.

Nanian joked in a tweet that a simple script calling System Events is "So, yeah, this is a [REDACTEDS] security violation:"

tell application "System Events"
return exists process "SuperDuper!"
end tell

Michael Tsai in his blog pointed to a detailed discussion at Mac OS X Automation on Accessibility Preferences and GUI Scripting. 

Developers have often relied upon AppleScript’s ability to control the user-interface, to provide an automation solution when no direct scripting support of an application or process was available. While this valued ability continues to be fully supported in Mavericks, the enhanced security focus of the new OS requires a few changes in how scripters access and apply the Accessibility frameworks.

The article states that in OS X Mavericks, security controls are more granular and require "the individual addition of applications."

In OS X Mavericks, AppleScript applications ("applets") that use Accessibility features may ask for the same information each time you use them, appearing not to remember the settings you previously entered.

This repetition occurs because, by default, applets that use Accessibility features in OS X Mavericks do not save their properties when run. Applets that save their properties modify their own contents in order to save that information. This self-modification makes the applet appear to OS X as a different app each time it is executed, thereby triggering the authorization process repeatedly.

The bottom line to Mac managers: Check all scripts in workflows when testing Mavericks.