If AppleScript is on its way out, what can replace it? Is Swift ready for serious scripting use, and how might that work?

These are the headline questions which I have been considering as I’ve been trying to port my AppleScript tool LogLogger into a Swift app. Aside from issues such as future support for AppleEvents, they are critical for anyone who currently scripts in macOS. And the more that I use Xcode 8.1 and Swift 3, the firmer my answers become.

Swift 3 is actually a very pleasant language to use, apart from its signs of immaturity. I have already remarked on its weakness in manipulating strings – the Griswolds who pioneered string processing languages like SNOBOL and Icon would have been shocked – and its tendency for classes which are very similar to those in Cocoa etc. but not actually compatible, which can be infuriating. But its syntax and common use should prove a very comfortable fit for many current scripters.

It doesn’t have the ‘natural’ language feel of AppleScript, but these days that is probably an advantage. When AppleScript was designed around 1990 few people knew a C-like programming language, and most potential scripters then would have known little beyond a bit of BASIC. Today I fear that AppleScript’s otherness is actually a barrier to its wider adoption. Swift is not a hard language to switch to if you have a background which includes a language from the C family.

Apple has also made access to Cocoa etc. much easier from Swift than from Objective-C. Although I am sure that Objective-C is not as bad as it looks, it has always seemed to me to be one of the ugliest and needlessly circumlocutious programming languages. Swift has its foibles, and ? and ! are the most obvious, but it is eminently readable and writable without undergoing formal conversion.

Swift also has a remarkable read-eval-print loop (REPL) making it almost ideal for use in scripting – as good as Python, I think. This enables code to be checked as you edit it, both in playgrounds and regular source code files. Xcode is most impressive at this, although some warnings can come and go rather erratically still. As a novice, I have found Xcode’s editing environment remarkably helpful much of the time, in guiding me to produce bug-free code.

This goes far beyond the checking which takes place when AppleScript is compiled, which only really checks syntax. It is very easy to write utter nonsense in AppleScript which passes those compilation checks. Xcode doesn’t yet check that your Swift code does what you think it does, but often comes spookily close.

My greatest reservations about Swift for scripting macOS (or iOS, for that matter) are in the rest of the development environment. In short, Xcode is too complex, and too easy to get lost in. For those developing regular apps and other software products, it is excellent, with all the flexibility and features that you might wish of an SDK. But these need to be skilfully cut down for scripting purposes, and for iOS.

The two areas which need to be augmented are front-end design, and class libraries.

Currently, Xcode provides a very powerful Interface Builder which works well, but needs to be slimmed down and simplified, particularly when it comes to inserting code actions and outlets. The scripter doesn’t need all twenty-three different variants of text boxes, and a list of controls which takes a couple of minutes to scroll through. When you insert a new control into a view, you need a simple default for the insertion of corresponding source code to handle that control, rather than having to drag a connection across to the correct point in your code.

To support these, the scripter needs high-level libraries to simplify many of the most common features of scripts: calling a command line script, file open and save dialogs, alerts and dialogs, for a start. Those standards entail less flexibility, but save the scripter from having to keep pasting in code snippets to perform those common tasks.

Currently, whether used in Xcode or the iOS app, and whether for macOS or iOS platforms, Swift playgrounds do not come close to providing general scripting support, as they lack key features such as a proper human interface and the ability to generate executable apps. Xcode’s playgrounds are an excellent aid when writing code, allowing you to develop and debug code snippets.

Swift Playgrounds for the iPad is an excellent educational tool for classroom use and independent learning. They both demonstrate that a lightweight scripting environment, such as that provided in Scriptarian (for all its other shortcomings) could be eminently usable.

With or without AppleEvent support, Apple has yet to ship a Swift scripting system which comes close to that already provided by creaky old AppleScript. Perhaps next year we will see something come much closer.