So... did anything happen with Applescript in Sierra?

I was glad to see Apple wasn’t abandoning Applescript with all the new additions in Mavericks/Yosemite/El Capitan… but I haven’t heard a word about Applescript in Sierra. Did anything change?

This no longer works:

tell application “System Events”
key code nnn
end tell

Creating nodes in the /Volumes folder requires root privileges, on pre sierra systems the /Volumes has 1777 permission, now it has 1755. Since mount volume command is not capable of mounting a volume somewhere else than /Volumes this command no longer works (maybe when the script runs as root). However command line utilities running as root works fine or mount the volume somewhere else than in /Volumes (on your home folder for example).

There’s some joy for those afflicted with intermittent loss of custom syntax formatting, and a couple of other things to be aware of. I’ve written a post covering what I’ve found so far (there are no release notes at this stage), which you can read here:

For Script Debugger users, Sierra-compatible upgrades are available for both version 5 and version 6.

And if you’re using ASObjC Runner, note that it does not run under Sierra, and will not be updated to do so.


Do you mean it fails altogether, or that it results in an authorization dialog?

An authorization dialog will be prompted and the script waits for the command to be finished. Since the command cannot run without help from the end-user I think it’s fair to say it fails.

Well it’s certainly near useless…

Did I miss the Release Notes somewhere?

I may be one of the few who use the Script Editor Template to create Cocoa-AppleScript Applets. A single MainMenu.nib is now inside a Base.lproj folder.

I was seeing a peculiar thing with whereby an Applet’s process name wouldn’t be listed in the Process column but rather the process name of a previously run Applet would be displayed; this makes me think there’s something weird going on with some Applets that haven’t been recently updated?

No. I’m just going on what I found, plus the response to a bug report.

Look up “Base Localization”. It’s actually a lot easier to use in Xcode, but I’m not sure about in Applets. The idea is that each item containing text in the .nib is automatically assigned an identifier, which is used to match content at run time. Check out one of the MainMenu.strings strings in one of the other languages.

If they’ve been renamed in the Finder rather than by saving, the process name will reflect the original name. Could that explain what you’re seeing?

Right. This doesn’t look like a problem yet.

Not sure. When I remade the Applet and dragged over stuff from the Resources of the original it seemed OK.

Next issue: Can’t seem to Export an Applet. A codesigning issue ensues:

“/Volumes/Main/.TemporaryItems/folders.501/TemporaryItems/(A Document Being Saved By Script Editor)/Make a Text resource fork, Finder information, or similar detritus not allowed”

Not sure what “detritus” the message is referring to. As far as I know my Developer ID is all up to date. I’ve also tried codesigning outside of Script Editor and that failed as well.

Also, an Applet simply Saved in 10.12 will not run on previous OS and I get a message that 10.12 is required.

That sounds like the issue I covered in the post referenced above:

I haven’t actually tried that yet. Ouch…

Ah, that’s a big help. Much obliged, as usual.

AFAIK, the only obvious update is that Xcode 8’s crappy old AppleScript interface got replaced with a new one. Which is kind of bizarre considering that almost all 10 million Xcode users utterly despise the AppleScript language and want it to DIAF, while macOS’s supposed programmer-friendly alternatives, ScriptingBridge and JavaScript for Automation, are incompetent, broken and almost entirely ignored by both Apple and its programming community. (But I digress.)

As for AppleScript itself, the lack of progress is slightly disappointing, if largely unsurprising. I’ve just filed an enhancement request for a standard library to be added to it as this would provide significant benefit to all AppleScript users at little cost to Apple, and copied it here for reference:

Other AppleScript users who’d also like to see decent text, date, math, and list processing commands included as standard are encouraged to file their own duplicate requests (include the original rdar://28465563 reference in your own ticket to save Apple’s poor Radar maintainers extra work) as the more requests Apple get for a feature the more likely they are to do something about it.

One more thing. if there’s any Swift-curious AppleScripters here, you might also like to check out SwiftAutomation, my newest and most definitely last Quixotian attempt to save Mac automation from itself. Requires Swift 3, Xcode 8, and OS10.11 or later. The SwiftAutomation framework is feature-complete, and there’s a nifty AppleScriptToSwift app included which lets you type in AppleScript commands and automagically translate them to their Swift equivalents, which is very cool. Way easier than trying to read its half-baked documentation, which is still a bag of balls right now (though I’m working on it; copy editors welcome).

One big annoyance is I’ve not [yet] figured out how to use SwiftAutomation (or any other third-party framework) outside of Xcode-built apps. Playgrounds are bloody useless and potentially dangerous for application scripting: they automagically re-run all your previous commands every time you type a new line “ very bad for commands like make, duplicate, and delete! Infuriatingly, Swift 3.0 still doesn’t support building third-party frameworks for installing into /Library/Frameworks “ right now everything has to be embedded into an .app bundle or Xcode project. So I’ve no idea how to import it when running Swift code in #!/usr/bin/swift ‘scripts’, which’d be absolutely kicking.

Still, for now it’s something to play with and explore, and proves [yet again] that AppleScript-quality automation support is absolutely 100% achievable in “traditional” languages. just as long as it’s designed and used by actual AppleScripters! Oh, and programmer-friendly languages like Swift have millions of users to AppleScript’s paltry thousands, so if macOS automation is survive “ and thrive! “ in future then it has to win over some of those millions, and soon. Otherwise, without lots of new macOS automation users flocking to their apps, macOS developers have no reason to support it either. And what better way to turn all those app developers into enthusiastic macOS automation supporters than by turning them into enthusiastic users of it too?! :smiley:

Whenever I include a .scpt file as a class file (for example, like Shane’s old “Applet With Progress” example), I get the “detritus” error message when attempting to Export with codesigning. This occurs even when creating a new .app from the Cocoa-AppleScript template and creating fresh new files. If I remove the .scpt file, it codesigns OK. I’ve tested this with several different Cocoa-AppleScript applets.

I don’t think there’s anything inherently improper with the .scpt file since the .app runs fine and, of course, it codesigns in El Cap.

The .scpt is written as a script object. Could this be the issue?


Are you re-saving the .scpt files under Sierra?

Yes, all the work is being done in Sierra.

Plan B is to run xattr -rc on it before signing.

I love it when Plan B finally comes together. I was doing xattr wrong. -rc did the trick.

I presume that this should be run on any file placed in the Resources folder in the event it may contain a resource fork?

As always, Shane, much obliged.

I’m presuming so. You might want to use the recursive -r option to do the whole folder.