By this stage of the northern hemisphere winter, once we’re into February, we all need a little sunshine and warmth to look forward to. This year, for all Mac users, that must include June in California. To be more precise, Apple’s Worldwide Developer Conference.

If that seems a little nerdy, and you feel that your holidays a month or two later would be a better prospect, think what we will discover. macOS 10.13 is almost a certainty, Apple’s new file system APFS is another headline act, but the future of scripting is every bit as important.

That may seem to the average Mac user an incredible assertion, but without scripting, a lot of Mac use becomes impossible. By scripting I mean lightweight coding, as opposed to the formal development of applications containing substantial code. The sort of thing that is put together in a couple of hours or days for a specific purpose.

Apps delivered through the App Store and similar channels can only cover a finite range of tasks. Whether to provide custom integration between commercial apps, or to perform tasks which are poorly covered by them, scripting makes a lot of businesses, organisations, and workers able to do what they need to do, more efficiently.

Scripting is, though, an almost insoluble security problem. Apple wants to be able to require that all the code that runs on your Mac is signed. This establishes a chain of trust, from that app back through Apple to the person who created it. You can sign AppleScript apps, but that defeats in part one of their strongest justifications: not only can anyone write their own AppleScript app, Automator action, or shell script, but anyone else can also modify it to do what they want. In doing so, they invalidate the signature and the chain of trust.

Whatever Apple might do in the future with AppleScript, Automator, or AppleEvents, the underlying technology, leaving Mac users able to run unsigned code leaves a gaping hole in security. It also damages any attempt to produce a secure operating system, which must be one of the key features of macOS 11.

Over the last few months, I have been looking here at the potential of Swift 3, Apple’s current flagship language, for scripting purposes. Although I have described various strengths and weaknesses, what I have so far not commented on is the language itself. I am not referring to its theoretical properties, nor to enumerations of features, but to the practicality of its use.

I’ve lost count of the number of languages in which I have coded complete, working applications. They include Fortran, Common Lisp, Object Pascal, APL, C, AppleScript, and occam. Few languages pass my ultimate test, which is usability even when coding for long hours and thoroughly exhausted, in an ‘all nighter’. The best of those was Object Pascal, which is such a transparent language that I regularly worked on commercial code despite periodically falling asleep on my keyboard.

I haven’t yet attempted an all-nighter in Swift 3, but I am becoming impressed at how transparent it is in comparison with Object Pascal, for example.

One quality which I find very important in assessing whether a language is safe to use is whether I can readily see sensitive code. For example, Object Pascal shouldn’t normally pull the sort of stunts that are commonplace in C with pointers, but you can use variable-length arrays. Wherever my Object Pascal played dangerous like that, my source was lit in dazzling neon, and I only fiddled with that section when I was feeling as sharp as ninepence.

You don’t have such luxuries like that in languages like APL, which codes with the intellectual intensity of playing high-standard chess. Nor do you in C, where everything seems to become devious and opaque.

Last week’s coding in Swift was not particularly tricky, but confirmed that, in normal use at least, it seems as transparent and safe as Object Pascal. I’m still a novice, mind, but I was able to write most of the remaining code in my utility Consolation right first time: even the string manipulation did what I expected it to on first compilation.

Using Swift in Xcode benefits greatly from its coding aids. As a novice, I’m still learning about Swift’s use of ? and !, and Xcode’s continuous code parsing helpfully nudges me into using them correctly. Some of its control structures can become opaque, although those will inevitably ease as I get used to them. To the relatively naive or novice, for example
FS.begin { result in
if result == NSFileHandlingPanelOKButton {
guard let url = FS.url else { return }
do {
try fileContentToWrite?.write(to: url, atomically: false, encoding: String.Encoding.utf8)
} catch {
doErrorAlertModal(message: error.localizedDescription)
}
}
}
is a bit tangled even when pretty-printed. But like Object Pascal’s variable length arrays, such complexities need not be commonplace, and I know not to mess with them unless I’m fresh and quick-witted.

I still think that Apple has a lot more to do before it can push Swift 3 and Xcode as a serious competitor to AppleScript. As comments on this blog have pointed out, the bridge to scripting apps is a critical link in many uses. But if we are going to see a drive to run only signed code, Swift scripting is the best hope of achieving it. Apple just needs to put the resources in to do the job properly.

We’ll see what comes in June.