Not quite as simple as all that

Nigel Warren:

The fact that iWork on the Mac has lost functionality isn’t because Apple is blind to power users. It’s because they’re willing to make a short-term sacrifice in functionality so that they can create a foundation that is equal across the Mac, iOS, and web versions. It will take time to bring these new versions of iWork up to parity with what the Mac used to have. In the meantime all platforms have to live with the lowest common denominator.

This is what I think, too. Doesn’t make it any easier to stomach if you relied on features that have gone away though. And let’s see how long “short-term” is.
Daring Fireball: iWork 13 is the New iMovie 08

This analogy falls short when discussing Applescript’s lack of support in iWork and its oftentimes murky support from Apple and its partners. From an application/GUI standpoint, sure, iWork is garnering the same reaction as iMovie and Final Cut Pro. Not that I want to point out the obvious here, but Applescript is not a GUI. Applescript is a programming language in its own right that extends the capability of any supporting application to well beyond the confines of its GUI. Looking at the current state of Applescript support is important to take into consideration here because there exists a deeper, more complex, history than what exists for iWork.

  • Search “Applescript” on Apple’s homepage, and there is no evangelism of any kind. There are, instead, links to developer documentation. What evangelism did exist has long since been migrated over to an external site run at one point by a freelancer specializing in Applescript solutions but now any clue of ownership is now hidden. What, exactly, is the Applescript community is to think of this? While there is nothing from Apple stating that Applescript support is going away, but there is an implication that Applescript is less than a second-class citizen in the Apple world, simply sent out to pasture and brought in for the occasional grooming. Attempts to improve Applescript’s profile are either weird or poorly implemented.
  • ApplescriptObjC was created to allow Applescript developers to create Cocoa applications in native Applescript, but it has some serious flaws. The source code file name changes from .applescript to .scpt upon compilation which destroys any links to included files. This is ultimately manageable but that just creates more ceremony before development can begin. Also, blocks are cannot be implemented in ApplescriptObjC, either.
  • Scripting Bridge, which goes the other way by allowing Applescript calls via native Objective-C (as opposed to using the NSApplescript class). But it relies on two command line apps that generate grossly erroneous or incomplete header files (with no tools for troubleshooting issues) and typically results in an API that is severely limited in scope by randomly not allowing the creation of certain classes.
  • Automator appears to be a bridge between budding power users that can’t code to those that can, but is a separate implementation in addition to Applescript despite both use the same frameworks. More work to implement another niche technology? Really?
  • Now we have a major name on the Mac, Adobe, allowing their Applescript APIs to fall apart and currently not allowing external script calls.

Given that context, iWork’s change in Applescript is not “the sky is falling” but rather the latest in a long line of dysfunctional behaviors from Apple.

If an analogy is sought of Applescript’s drop from iWork, then it could go something like this: For a certain class of “power users” (an analogy I equate to “people who drive trucks”), dropping Applescript support from a core application cutting off any further independent development and is akin to Apple dropping the Cocoa frameworks and Objective-C. Hard stop. There is no GUI to fall back on for what Applescript does for a lot of its users.

For that subclass of power users, those that have built processes and workflows that save their companies thousands of dollars and hours each year in productivity, any drop in Applescript support marginalizes those users into maintaining quickly-outdated systems. When talking about those power users, adding a “though” to “Doesn’t make it any easier to stomach if you relied on features that have gone away” is dismissive of the impact. The reaction from certain users is not about iWork but about the state of Applescript in general.

Given this affects a subclass of a subclass of all users, robust Applescript implementations are a relatively small niche. As such, support was never as solid or apparent as, say, Core Data. If support for a technology that I use to automate quantifiably money-saving processes is dodgy to the point where whole code migrations are required, then I, as well as others, will need to seek out more stable platforms. So, try to stomach that.