.AppleScript vs . scpt
So I wanted to see what everyone’s are thoughts and what are the best practices for this.
.AppleScript vs . scpt
Both
- so essentially the first is a text file while the second is a compiled binary.
- Both can run the AppleScript code
.scpt
- supposed runs AppleScript faster (can’t really tell speed)
.AppleScript
- is searchable through the finder
those are at the high level the changes I’ve found.
?
- which version do you use? .AppleScript or . scpt and why do you prefer either?
Is there any best practices between the two when to use them?
Usually if I’m just prototyping a script and running it in SD I’ll save it as AppleScript until I’m ready to use it externally, then I’ll do save as…. script / script bundle or app.
I’m not 100% sure but I think if your require any “permissions” when you run them externally, The can not be in AppleScript format.
Most stuff I’m doing now is in Xcode but I’m still using some AppleScripts, which I’m calling from Obj-C using Bridging Headers. And loading the scripts at runtime. Those I’m keeping in AppleScript format. Granting permissions to the main app.
On your own machine, it’s largely a matter of your own preference and convenience.
- A text file can take up less disk space.
- It may be convenient to use a dedicated text editor to tidy up the source code of a large script.
On the other hand:
- A script’s source code has to be compiled before it can be run. Saving it in compiled form saves having to do that step at run time and saves having to use an application which can actually do the compiling.
- A compiled script can be exported without its source code if you don’t want other users to see it.
- Compiled AS code can be more portable than source code. For instance, if I, a Brit, write the specific date
date "Friday, 6 March 2026 at 09:29:03" into a script distributed as text, an American scripter will have to edit the date before it’ll compile on their own machine. But if I send them the script in compiled form, the date object will be decompiled to their own preferred format when they open the script on their own machine. In a text forum like MacScripter, though, the “best practice” is to use code which creates a date object rather than specifying it. Something like: tell (current date) to set {myDate, its day, its year, its month, its day, its hours, its minutes, its seconds} to {it, 1, 2026, March, 6, 9, 29, 3}.
Historically:
- Until quite recently, when scripts saved in compiled form were run, the values of their top-level properties, globals, and run-handler variables at the end of each run were saved back to the script file and persisted into the next run. The values are no longer saved, but do persist across consecutive runs in Script Editor (not Script Debugger) provided the documents aren’t closed between runs.
- Back in the very early days of AppleScript 30-odd years ago, it was also available in a handful of languages other than “English-like”. Compiled scripts were apparently portable between these too.
thanks everyone for the shared insight, greatly appreciate it !
In addition to being searchable, .applescript files work with QuickLook without needing an importer, but probably the biggest reason for their use would be version control. Granted, version control isn’t all that useful for a one-page script, but there are those that have scripts with hundreds of lines of code (you know who you are). Trying to remember what you changed since the last version 6 months ago (or trying to revert some section of it), or tracking the history of a GitHub repository is a bit tricky without it.
I have all my scripts in a git project for version control saved as .applescript. I use header comments on those scripts with an annotation for building the script into scpt (using a hotkey), which then copies it over to Script Libraries, which is where I consume/reuse those scripts in my client/front facing scripts.
.applescript header:
(*
@Build:
./scripts/build-lib.sh core/lov
*)
Client Script in any format (scpt, applescript, or app)
use lovLib : script "core/lov"
set lov to lovLib's new()
lov's handler()
Just chiming in with others that if you’re dealing with anything large/complex, you want git for code management, and then you definitely want .applescript. I’ve tried other things - Script Debugger has specific support for preferring the .rtf copy inside script bundles, and there are RTF merge tools - for keeping .scptd bundles or .app’s on git, but this was always a source of endless trouble for me, and I eventually ended up with 100% .applescript files on git, and I use a deployment script that moves dependency files into bundles and moves in icon files and sets them to deploy .app’s from .applescript files automatically. It’s a multi-stage deploy process, first saving as a .scptd file to create a bundle, then moving resources in, opening the bundle in Script Debugger, setting the icon, then saving as a .app with codesigning.
Everything is deployed via script to actual users off the .applescript file as run-only code, .scpt, .scptd, or .app.
For simpler setups, this is unecessarily complex, but for our setup it’s proved critical. Once the deployment app is built, it is no more work. Whenever I’m done editing a .applescript, it’s just a keystroke to save the .applescript and build and deploy the deployment copy.