Script Debugger 8 introduces the Bundle & Export Settings dialog which combines various previous settings, and some new ones, in one place. But the new arrangement isn’t just about immediate convenience – it’s about re-thinking the way scripts are developed and distributed.
AppleScript was designed for maximum appeal to non-programmers, and one shining example of this approach was the way you can use the same file format for writing and saving scripts as you do running them. So if you were writing an applet or droplet, once you saved your code, you had a fully functional application. It couldn’t be simpler.
Of course that also exposed all your code, so in many cases it was more sensible to save a run-only version, but it was still pretty simple.
But slowly, things got more complicated. GateKeeper made code-signing attractive. And then notarizing was introduced. Now, with Macs running Apple silicon, code simply won’t run without some basic code-signing.
As well, new options have arisen, with things like script libraries and frameworks that can be embedded in applications. Applets can be customized more via Info.plist settings that have traditionally been hard to access. Some users wish to store code in code management systems, which don’t accommodate existing formats very well.
So for many users, what was once simple has become a bit of a juggle when it comes to producing scripts that others can run. And the simplicity of the original idea of a single file for development and deployment has ended up making the latter more of a chore.
At its heart, the Bundle & Export Settings dialog is designed to be an aid to making it simpler, and more logical, to separate development and deployment, especially of applets. We’ll come to how that might translate into a different workflow shortly, but first let’s look at the various settings involved.
The dialog has three tabs, with the first, and most important, being Bundle & Export. Most of these settings were in the Resources tab in Script Debugger 7. The new ones are at the bottom, in the Export Only Options section. These are:
-
Include used user script libraries. When this is checked, any required script libraries from the user’s
~/Libraries/Script Librariesor/Libraries/Script Librariesfolder will be copied into the exported bundle. -
Include used user frameworks. When this is checked, any required third-party frameworks in
~/Library/Frameworkswill be copied in the exported bundle’s Frameworks folder. -
Make included scripts and libraries run-only. This makes sure all embedded scripts are stored run-only.
-
Sign bundles and applets to run locally. When checked, exported bundles and applets will be code-signed to run locally – that is, without specifying a signing identity. This is a limited form of code-signing that is a minimum requirement for universal applets on Macs using Apple silicon processors, and will be performed when exporting applets from macOS Big Sur regardless of this setting.
-
Exported file’s name. This allows you set the name used for the exported file. By default, it is the same as the file you are exporting from, but you can enter whatever you want. This makes it easier to give the original file a more descriptive name.
The next tab is Privacy & Security. This controls various entries in the Info.plist file of an applet. These are normally all supplied by default, but this dialog gives you an opportunity to modify them – these messages appear in dialogs when the applet’s user is asked to approve access. You can also use the checkboxes so that entries don’t appear, for added security or peace of mind.
The final tab is Advanced Options. At the top are a range of optional security strings, which will appear in authorization dialogs. You can use these to give users more information on why an applet needs access to particular directories.
The bottom three entries are for users exporting Enhanced Applets using the Sparkle framework for automatic updating. You can enter the required Info.plist values here, rather than having to edit the file directly.
Putting all these settings in one place has another advantage: you can set them once. The actual export then becomes a simple matter of choosing a command from the Export Run Only submenu in the File menu.
