hoakley November 18, 2016 Macs, Technology

Goodbye AppleScript

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.

imagescript6

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.

swiftcode

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.

swiftplay4

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.

13Comments

Add yours

1

macman2015 on November 19, 2016 at 12:07 am

Nice article. Thanks. The stuff about Swift and Swift Playgrounds is very interesting and informative.

From the outside (that is, as someone who doesn’t work at Apple), I haven’t seen a lot of progress or improvement in AppleScript or Automator over the last several years. It makes me wonder whether Sal’s group was working on things that never made it to fruition. In a way, I’m wondering whether anything would be different today if Sal’s group had been disbanded a year ago. Or two. Or five. To me, AppleScript was fairly mature several years ago, and Automator is about what it first came out. Maybe, had they made more noticeable progress, Sal’s group would still be part of Apple.

This is not to say they didn’t make progress at all. I’m just saying it wasn’t very noticeable to me. And I’m a scripter.

LikeLike
- 2
  
  hoakley on November 19, 2016 at 8:20 am
  
  Thank you for your kind words. I agree with AppleScript and Automator – marking time is perhaps an overstatement.
  I believe that Sal and his team have been busy with other projects, including http://dictationcommands.com and Accessibility features.
  Howard.
  
  LikeLike
3

Vince_A on November 19, 2016 at 10:55 pm

Good article. Thought provoking. A bit depressing.

The difficulty with learning Applescript is not so much the language itself, which is much more approachable for non-progammers to wet their feet with than Obj-C, but the implementation of the scripting dictionaries for every single different app. Something that works rather straight-forwardly in one app, would be written totally differently in another. You find many rabbit holes when you are just trying things blindly in Script Editor. Purchasing Script Debugger changed my Applescripting life forever. Using the “Explorer” view of the dictionary, I can see into the dictionary and find exactly what I need in each different app. It isn’t perfect, but it has allowed me to be successful writing many scripts which would probably have failed or taken a lot longer to get working without it.

As for the security problem, there should be various ways to address this on MacOS aside from killing Applescript altogether. A mechanism to allow scripters to Code-sign scripts they want to share shouldn’t be hard to implement. iOS scripting, I think is a totally different, and unrelated animal and should not be mentioned as a problem for Applescript. Workflow or your suggested Swift Playgrounds may be the answer there. But, Apple didn’t initially intend for iOS Apps to be scriptable, probably based on security concerns. That also could be partly because they wanted apps to be small in size and narrowly focused on a few small tasks. As memory and CPU ability increases in phones, these constraints will likely vanish, and as the popularity of Workflow increases, so will the pressure on Apple to let apps interact in some way, for the benefit of users..

Applescript Obj-C isn’t rapidly adopted by many scripters because the Applescript part is hard, it is more the intimidation of Xcode and APIs and Obj-C things that probably scare people off. Hooking plain Applescript into Xcode with a few buttons and fields really isn’t that hard. But, who wants to dig through the documentation on the APIs that you need to access for anything but the most basic programs? I don’t doubt that Swift could be given some hooks that allow it to substitute for Applescript if Applescript is killed, but the same obstacles to ease of use would persist — the nonstandard implementations in the dictionaries of the applications you are scripting. That is the part that needs to be addressed — with a tool similar to “Explorer” dictionary view in Script Debugger.

Apple’s latest apps are actually pretty supportive of Applescript. The initial rewrites of the “dumbed down” Pages and Numbers a few years ago had *very* limited scripting dictionaries, but the most recent updates have much more robust scriptability. Console is a terrible example… anyone who understands a crash report or log file will be using UNIX to access these text based files anyway.

Time will tell.

LikeLike
- 4
  
  hoakley on November 19, 2016 at 11:08 pm
  
  Thanks for your long comment. Just one point of fact: you cannot access Sierra’s new log file as text, as the main log is no longer text-based. A lot of advanced users used Console in the past, and will not touch the complexity of the shell command log, so are now effectively locked out of their access (unless they use LogLogger, which is written in AppleScript!). If you look at Console’s AppleScript dictionary, which is present, it doesn’t support the most basic of features, but it still has a dictionary. Why? It is a dictionary like the Marie Celeste – started, and abandoned.
  We should also acknowledge Sal’s vital role in ensuring good AppleScript support in its existing apps. Who is there now to do that?
  Howard.
  
  LikeLike
5

Cowicide on December 3, 2016 at 4:07 am

I’ve been pretty amazed at how well most of my old AppleScripts have held up over the years, including with Sierra. If anything, they’ve seemed to run faster after I updated to Sierra. I really hope they don’t mothball it because it’s going to kill the workflows of many Apple users. Frankly, if Apple does that, I might leave the platform entirely considering their hardware in 2016 has been so lackluster in raw speed for power users who work with video, 3D, graphics, etc. compared to Wintel offerings.

LikeLike
- 6
  
  hoakley on December 3, 2016 at 8:17 am
  
  Thank you.
  Considering that there is no equivalent scripting feature at all in Windows, I’m not sure whether it offers a serious alternative, does it?
  Although recent versions of macOS have continued to support AppleScript, it has not actually had any significant development or improvement for many years now, apart from AppleScriptObjC which seems to be a very specialised and minority field. As I have written in other articles, a Swift-based scripting system which still uses AppleEvents could offer a lot of new and more powerful features, and could extend to iOS. Would that not be an attractive way forward?
  Howard.
  
  LikeLike
7

hoakley on March 18, 2017 at 1:06 am

I have for some years been meaning to learn Applescript though as yet not got round to it. In light of events and your post would you advise not to bother?

LikeLike
- 8
  
  hoakley on March 18, 2017 at 7:02 am
  
  I’d wait until WWDC this June makes the situation a bit clearer, I hope.
  AppleScript is a different language, and unless it has a secure and significant future on Apple systems, I wouldn’t see much point in learning it, except perhaps out of curiosity.
  Howard.
  
  LikeLike
9

kenneth on June 5, 2017 at 12:59 pm

.
We should also acknowledge Sal’s vital role in ensuring good AppleScript support in its existing apps.

LikeLike
10

Rimu Atkinson on July 31, 2017 at 1:16 pm

Did WWDC clear this up? Does AppleScript live on?

LikeLike
- 11
  
  hoakley on July 31, 2017 at 2:21 pm
  
  ‘Live’ isn’t the word. It survives for now, but see this article.
  Howard.
  
  LikeLike
  - 12
    
    Rimu Atkinson on August 1, 2017 at 4:09 am
    
    Thanks Howard 🙂
    
    LikeLike
13

arsenios on August 18, 2017 at 12:36 pm

.
Applescript Obj-C isn’t rapidly adopted by many scripters because the Applescript part is hard, it is more the intimidation of Xcode and APIs and Obj-C things that probably scare people off.

LikeLike