AppleScript and Mavericks
Mac OS X Automation covers new AppleScript features in Mavericks:
In OS X v10.9 or later, when you create or change documents using the AppleScript Editor or Automator applications, iCloud can keep the scripts, workflows, and applets up to date in those editors on your other Macs.
Code Signing support has been added as an export feature to both the AppleScript Editor and Automator applications, enabling Apple developers to easily generate signed copies of their applets and droplets.
AppleScript Libraries provide a new plugin architecture for extending the power and abilities of AppleScript. AppleScript Libraries are user-created script files and bundles, composed in AppleScript or AppleScript/Objective-C, which contain specialized commands that can be referenced in scripts to provide extra or “missing” functionality.
For its 20th anniversary debut in OS X Mavericks, AppleScript delivers a long-sought ability: an import command — dramatically extending the scope and power of this unique language.
A new AppleScript construct, called the “use statement”, imports the terminology and functionality of AppleScript Libraries and scriptable Applications through a simple single-line declaration placed at the top of a script, such as:
use application "Finder", or:use script "My AppleScript Text Library".
No longer will scripts and workflows have to display dialogs to inform users that time-consuming or complex automation processes have completed. With integrated notification support for AppleScript and Automator, users can leave their automation processing unattended, confident that they will be notified of the results in the built-in Notification Center.
Accessibility Preferences and GUI Scripting:
In OS X Mavericks, security controls are more granular, requiring the individual addition of applications, or automation applets that script the accessibility frameworks, to an approval list, displayed in the Security & Privacy system preference pane.
In OS X 10.9, AppleScript introduces an alternative syntax for calling handlers and methods. Instead of using underscores and running the terms together, like this:
theString's writeToFile_atomically_encoding_error_(thePath, true, current application's NSUTF8StringEncoding, missing value)You use an interleaved syntax similar to Objective-C, like this:
theString's writeToFile:thePath atomically:true encoding:(current application's NSUTF8StringEncoding) |error|:(missing value)
This is great for AppleScriptObjC. Unfortunately, although you can use the interleaved syntax for your own handlers in regular AppleScripts, you still cannot call into the Cocoa frameworks from regular AppleScripts (like you can via the PyObjC and RubyCocoa bridges).
Don Southard:Most of all, I am happy to see Apple putting a focus on the power user with these enhanced automation tools and I hope it is a sign of the bright future OS X still has had of it.
But improvements in the AppleScript language itself are like the proverbial tree falling in a forest. If no applications bother to use AppleScript, do those improvements exist? Not in any practical sense. No one in their right mind uses AppleScript as a standalone language; it’s all about adding functionality to an app or acting as glue between apps.
6 Comments RSS · Twitter
There's a full session at WWDC 2013 you can watch going over these. After WWDC I was pretty excited that Apple was going to push Applescript more. However as Drang said, if apps don't support the tech it's not terribly useful.
What Apple really needs is a VP who cares about these sorts of things and pushes it in through the app team silos.
Sal Soghoian at Apple is pretty good at "reminding" various teams that their AppleScript could be better.
That said, I suspect the regressions in iLife/iWork this time around come down to timing and a rewrite for better compatibility with iOS. Hopefully it's a platform to build back on top of in the future.
"What Apple really needs is a VP who cares about these sorts of things and pushes it in through the app team silos."
But why should they? Apple has boldly transformed itself into a relentlessly consumer products and services company, and has done unbelievably well as a result. The only real reason they still keep pro users around is not because they generate significant revenue but because their continued presence adds status to the Apple marque. If all of Apple's pro users were to bail for Windows and Linux tomorrow, the direct effect - a tiny dip largely in high-end, low-volume unit sales - would barely be noticed, but the loss of status to Apple would indirectly reduce their ability to demand luxury prices for all of its other products from all of its other customers.
If pro users want to understand why Apple does what it does, and what the long-term implications might be for their own businesses, they have to look at Apple's motives from Apple's point of view. A Lexus isn't very much better at getting you from A to B than a Toyota; the reason people buy Lexus is because they want the high status of other Lexus owners to reflect on them too. This is why, for example, the new Mac Pro is a Lexus - a slick ultra-luxurious product aimed at the top-end consumer market (and priced accordingly) - and not a tough, practical Toyota pick-up truck as you'd normally expect of a product that actually works for a living.
99.9% of Apple customers don't know or care that AppleScript exists, and most of them couldn't/wouldn't use it even if they did. It's actually pretty awful as end-user programming languages go - a LOGO-based language would be far better for imperative coding - and too granular and time-consuming for the sorts of customization tasks that most users would want to do, for which a declarative dataflow language-cum-editor would be more appropriate. And because the AS team and community have failed to engage effectively with the larger Mac/iOS/iCloud developer world, 99% of Apple and third-party developers view AppleScript as nothing more than damage to be routed around, instead of what it could/should be: a fantastically powerful mechanism for combining existing components (in this case apps) into something far greater than the sum of its parts - comparable to Unix's philosophy and CLI environment, only open to everyone and not just a few eccentric old neckbeards.
I'm also not sure that allowing users and other third-parties to build and tailor their own user experiences exactly meshes with the modern Apple's business motives, which is to create a highly polished, meticulously designed and carefully controlled experience, where consumers tread well laid-out routes that Apple provide for them. The last thing Apple would then want is to provide users enough freedom to lay their own bypasses around the various toll booths established by Apple at carefully arranged pinch points to ensure the lovely "Services" lucre continues to roll in long after the original hardware is sold and the software handed over for free.
"Sal Soghoian at Apple is pretty good at "reminding" various teams that their AppleScript could be better."
In much the same way that Don Quixote was pretty good at engaging giants, I suspect. I'd love to be proved wrong, natch, but right now I see no signs to the contrary. I'm solidly with Dr Drang: without a large, powerful mass of Mac/iOS/iCloud developers on board, the AS team are doing no more than rearranging the deckchairs on the poor old Titanic. Oh well, iIcebergs ahoy!
[…] reserved. get _array's |count|() -- AppleScript changes “_array's addObject_(1)” to the interleaved syntax: _array's addObject:1 -- AppleScript changes “_array's insertObject_atIndex_(0, 0)” to: […]
