After 25 years, Apple is about to kill AppleScript. The departure this week of the great Sal Soghoian, who has led Apple’s Automation Technologies and scripting systems for the last 19 of those years, marks the end of an era, and the end of AppleScript as we have known, occasionally cursed, and always loved it dearly. But it is not the end of scripting for macOS, and should open new and even more exciting possibilities.
AppleScript was introduced as one of the many major changes in System 7, which marked the Mac’s coming of age. Classic Mac apps – just like macOS ones – were event-driven. By providing hooks into those events, it became possible for other apps to control them. All it needed was a scripting language, hence the birth of AppleScript.
As a programming language, it was a partial success. Most diehard programmers saw it as a verbose toy, which did some things impressively easily, but a lot of other things rather poorly. Many advanced users saw it as being programming, and did their utmost to avoid it. But for those who immersed themselves, it proved anything but a toy. The IBM-built Network Server 500 and 700 were driven by Mac apps written largely in AppleScript, businesses were built on commercial apps which were cunningly integrated using AppleScript, and a superb rapid app development tool (Facespan) appeared to help its users write their own apps and tools.
Somehow – and I strongly suspect that a lot of that somehow was Sal Soghoian – AppleScript survived the great purge of Classic MacOS features, and made it into OS X. Strangely it has here been eclipsed by the other automation tools for which Sal was responsible, including Automator and Apple Configurator. Instead of equipping AppleScript with better tools to support the user interface, it became semi-integrated into the Xcode SDK, first with AppleScript Studio, then AppleScriptObjC. Unfortunately, coding an AppleScriptObjC app is considerably harder than writing plain AppleScript, and precious few developers seem interested in using it.
The biggest issues with AppleScript are now those of security and iOS support. Devised in a completely different threat landscape, AppleScript has no concept of entitlements or sandboxes, and could be abused to cause great damage. Its unpopularity with most programmers is probably the factor which has ensured that it has not been exploited to any degree.
It has therefore remained confined to the more liberal regime of OS X and (just) macOS. As Apple integrates macOS and iOS more tightly and limits what apps can do in macOS, AppleScript has become a problem. Apple’s solution, I’m afraid, is for Sal to leave, and further AppleScript development to be terminated.
If you’re looking for even clearer writing on the wall, try opening the scripting dictionaries of Apple’s most recent tools, such as Console 1.0. You’ll find them near-empty, and vestigial. Apple sees no need any more to build AppleScript support into its own apps – something which would have been unconscionable just a few years ago (thanks largely to Sal).
Developers and advanced users still need a scripting system, and with all those wonderful hooks in place through most of Apple’s own apps, it would be crazy just to abandon automation. I don’t think for a moment that is Apple’s intention, and I expect an announcement next year, probably before WWDC in the summer, that Swift Playgrounds will be the basis for AppleScript’s successor.
Since initial development work on Swift over six years ago, by Chris Lattner, its progress has been relentless. As a language now gaining ground on platforms other than Apple’s, its appeal to a broad range of developers is growing rapidly. Apple started to offer coding ‘playgrounds’ in Xcode some time ago, and in September released its first iOS-based Swift environment, in Swift Playgrounds for iOS.
As far as serious scripting goes, Swift Playgrounds are but a proof of concept, that an app running in an iOS sandbox can run code written in a general-purpose programming language. They’re an excellent educational tool, and probably the only way that we are likely to see a proper scripting system running in iOS.
Apple has invested heavily in Swift, and in 2017 I expect to see it confirm the death of AppleScript, and to announce its replacement by a new scripting system based on Swift playgrounds, which will not only run on macOS, but which will also empower iOS users. I’m heartbroken that AppleScript is going, and grieving at the departure of Sal Soghoian, but I’m looking forward to getting to grips with the Swift tools of the future.