Reconciling AppleScript with modern software practices?

My day job is software development with modern languages. I have been promising myself for years that I would learn AppleScript and now I finally have some time to do it. I have a couple of scripts that I am happy with and that work, so now I am wondering how to do Source Code Control with AppleScript.

Modern software projects are just a bunch of text files that typically coexist together in a certain directory. It is easy to use a Source Code Control tool like git to keep versions of the code and store it in a safe place like Github. You can experiment in your sandbox without fear of breaking a functioning system. The thing I can’t yet grok about AppleScript is how to do that.

AppleScript favors a binary format, which certainly can be stored in git, but you can’t do a diff between one version and another. AppleScript wants to sprawl all over my file system, in a multitude of places like

  • ~/Library/Scripts
  • ~/Library/Script Libraries
  • ~/Library/Scripts/Folder Action Scripts

If I want to experiment with new additions to a script that resides in one of these standard places, I have to risk breaking an existing setup to keep these required locations.

Has anyone come up with a good workflow to handle these issues?

Have you considered activating Fast User Switching and setting up an additional user account (or several) for testing purposes?

You don’t need to use those locations - I rarely use them, mostly because I rarely use the script menus.

You can save scripts as .applescript instead or in addition to the compiled .scpt files. These are just text files which you can manage with git.

Does this work with Script Libraries? I am creating functions that I can reuse in other scripts such as

tell script "My Text Processor"
    changeCaseOfText("scripting is awesome!", "upper")
end tell

My reading of the document indicates these Special Folders are required by the AppleScript system for tell script scenarios.

Take a look at OSA_LIBRARY_PATH in the docs here:

That was going to be my recommendation as well. Keep the .applescript files in git, not .scpt files.

So how does that workflow look? Lets say I create a new file in Script Editor as .applescript. While I’m in the code-test-debug cycle, don’t I need to save as a .scpt file? Or does that only need to occur when I want the script to be able to run stand-alone?

Yes that’s what I was imagining.

You can use .applescript files in Script Editor just as usual. Once you have a “release” that you want to distribute, you could make a .scpt

Having said that, I don’t do a lot in AppleScript, so I’m not an expert, by far. Most of my AppleScripts are fine in plain-text files and I call them via osascript in shell scripts, etc.

I’d recommend taking a look at Late Night Software’s Script Debugger help, and Doug’s AppleScript - Using Script Editor (3 pages). They each give some insights into the pros and cons of the different save formats and what you can and cannot do with them.

A simple way to think about the .script vs. .applescript scenario is that you would strictly version control your source code, but when you compile it (AppleScript happens to support editing the ‘compiled’ script), you would probably just keep an archive/backup copy rather than apply the same level of version control; though of course you could - you just can’t work with the content in the same way.

1 Like

Another thing to think about is that

do shell script



can eliminate a lot of your applescript, especially if you have tools in other languages that do what you want (probably faster…).

In the example above, I wouldn’t use applescript for the actual case transform. My ideal rule of thumb would be to only use AS where 1) data structures are too complex to convert or 2) I need to change the UI. In practice I use a lot more because i’m lazy and familiar with it, but it’s not an approach I’d recommend if you can do the same thing easily in a faster language.

1 Like

Thank you to all for the great tips and ideas. I think I have a good enough handle on things to move forward!

1 Like

FYI, the script that created all of this kerfuffle is posted here Script Library for manipulating display resolution