Scriptarian claims to provide a “modern alternative to AppleScript”, with its Swift-based scripting environment. Although it has a lot of promise, it still has some way to go before that, and some of its other claims, are justified. However, for a mere $10 it is an exciting glimpse of the future.

When you first open the app, and enter your registration code, it analyses the AppleScript dictionaries of the apps which it finds with standard AppleScript support. You can choose which you wish it to analyse, and which to ignore, and the app then goes off for a minute or so and turns those dictionaries into its support files, and HTML files for its inline documentation.

Not all dictionaries appear to work with this, so you may find your favourite apps are not accessible from Scriptarian. Hopefully future updates will reduce the number of apps so affected.

Its splash window then offers to create a new script project, open any recent scripts, or link through your browser to Apple’s Swift documentation.

Currently, its preferences are limited to basic editor settings. You can also rebuild the app dictionary support through a menu command.

Half a dozen simple example scripts give quite a good feel for its potential, and provide some Swift code for you to steal from. These need to be expanded, of course, and it would be nice if the examples contained helpful comments.

Its documentation consists of a combination of core features, which are available even if you do not give it access to any of your apps, and the products of its processing each of the app dictionaries at the start. You can search as shown, or browse by section and app name. Unfortunately, as its documentation is automatically generated from those dictionaries, it contains no examples or comments which could explain issues that may not be clear. In this respect it is no more or less helpful than an AppleScript dictionary. You will probably need a documentation browser with wider scope to assist, such as the superb Dash.

Browsing available methods for apps like TextEdit highlights Scriptarian’s biggest problem at present: its very limited support for commands and other components which are available to AppleScript. This is probably a limitation in its bridge to the AppleEvent controls in those apps, the AE Bridge.

For instance, TextEdit (hardly a complex example) has support for 13 commands in its AppleScript dictionary. Only 7 of those come through as Instance Methods in Scriptarian, and several of those lack the functionality of their AppleScript equivalents. The open() instance method in Swift takes no arguments, which makes it incapable of opening anything. Its AppleScript original takes an alias argument, which specifies the file(s) to be opened.

If TextEdit is set as your default text editor, you can still open a text document in TextEdit using the ScriptingFoundation function open(url:), but that is a workaround.

The editor has a lot of context-sensitive features, but these can prove a bit kludgy at times. It attempts to parse the text as you type it, and depending on how distressed it becomes during that process, the parser can crash and automatically restart. It needs to handle such editing more robustly, although this should not cause any significant problems when you are editing.

This emphasis on context does have good payoffs: autocompletion is impressive and very helpful.

The editor warns about errors by flagging the line where it thinks those errors are. If you click on the Run button to submit your code for compilation – which takes a few seconds – you will get a helpful message explaining the error.

Every time that you run your script, it is compiled afresh, which wastes time if you have not made any changes. However scripts run reasonably briskly. There are basic debug features such as breakpoints built in, but these inevitably lack the support provided by a mature product such as Mark Aldritt’s Script Debugger.

Swift language support seems excellent, and uses the latest version of the language, Swift 3.0.1. Although I was doing some fairly silly things at times, Scriptarian remained stable and fully functional throughout. It can sometimes be a bit sticky when trying to browse its documentation, but I suspect that bug will be easy to fix.

Once you have created and debugged your Swift script, you cannot yet generate a standalone app from it. Instead, it generates a Unix executable, which you then have to run from Terminal’s command line or (if you have a wicked sense of humour) from within AppleScript or Automator. These executables are tiny and appear to have full access to macOS, for example to use file open dialogs, so it should not take much effort to bundle them up as double-clickable apps.

Conclusion

Scriptarian is not yet a replacement for AppleScript. The major determinant of its success is going to be whether it can achieve complete support for AppleScript dictionaries, thus the AE Bridge. That has long been the holy grail in macOS scripting, and without it, I am afraid that Scriptarian will never become a production tool.

For the moment it is a sound and impressively robust Swift playground environment, which also has some impressive but patchy app scripting abilities. If you’re learning Swift, particularly with a view to using it for scripting, it is terrific value for only $10. Provided that you recognise its current limitations, I think it is an excellent purchase.