What’s new with automation in Yosemite

Apple introduced a great variety of new automation features and updates in Yosemite. I've written up a quick summary below with links to more detailed information.

AppleScript

AppleScript users have been requesting a built-in progress indicator for years. In Yosemite, Apple delivers. New AppleScript properties allow script developers to show and control a traditional progress bar in applets. In Script Editor, progress is shown at the bottom of the main window. For the Scripts menu, an "Automation" menu appears to show progress.

CombinedProgressFrom left to right, how the new progress indicator displays in applets, in Script Editor and the Automation menu (run from the Scripts menu)

For more information, see this short video from the new features page at macosxautomation.com.

AppleScript users have been able to access the power of Objective-C since the introduction of AppleScriptObjC five years ago. Originally, script developers had to learn to use Xcode to take advantage of this feature. In Mavericks, AppleScriptObjC can be used directly within regular scripts, but only through the use of separate script library files saved in a special format.

In Yosemite, separate libraries are no longer needed: AppleScriptObjC can be used directly in any script. Shane Stanley has released an update to his book, Everyday AppleScriptObjC, which covers how this works. As usual, Shane's book contains a lot of powerful sample scripts with detailed explanations. In the introduction he writes, "…in Yosemite, AppleScriptObjC is available everywhere, all the time. Truly Everyday AppleScriptObjC…Welcome to the modern world of AppleScript."

For power users of AppleScript, streamlined AppleScriptObjC access is the most significant new feature. But Yosemite also brings some improvements to AppleScript handler parameters, do shell script, as well as bug fixes. See the full release notes for more information.

Automator

Otto is getting some love in Yosemite as well. Workflows can now be saved as Dictation Commands, a new feature in Yosemite which appears to be an improvement over Speakable Items. A post by Christopher Breen at MacWorld covers how to turn on Dictation Commands and then start a workflow with a spoken command. (Red Sweater developer Daniel Jalkut discovered that Dictation Commands can also launch scripts.)

Sal Soghoian has released a set of new Automator Actions for Keynote. These are not included with Yosemite, but are available as a free download. The set includes many cool actions here, including Present Slideshow with Narration and Add Charts with Numbers Table Data.

CombinedNewActions2Two of the new Keynote Actions available for download.

Automator in Yosemite has a new Run JavaScript action allowing Automator users to call custom code written in JavaScript for Automation (see below for more info). This new action works in the same way as the existing Run AppleScript action.

New scripting support in iWork applications

Pages, Numbers and Keynote now all provide scriptable access to placeholder text objects, including a tag property for specifying a custom script tag to make it easier to change objects via scripting. Pages has added the ability to assign a tag for placeholder text in the user interface with the "Script Tag" field shown below.

PagesScriptTag3
The new Script Tag field in Pages makes it possible to assign custom tags to placeholder text for easy access via script.

To demonstrate these enhancements and provide some cool mail-merge/database publishing capabilities, see the new Pages Data Merge application. A demo movie provides more information.

As an automation developer, I'm always looking for better scripting support in Apple's own applications. Even with all this news, I find the new Script Tag field in Pages one of the most encouraging automation improvements in Yosemite. It is great when Apple adds any new objects to a scripting dictionary, but to add a user interface element specifically for working with scripting automation is huge. Let's hope we see even more of this in the future.

I've examined the scripting dictionaries of all three iWork applications, and beyond placeholder text and cosmetic improvements I see one new feature: Numbers has scripting support for the new Transpose feature.

JavaScript for Automation

There is now a new choice in writing scripts: JavaScript for Automation (JXA). Every application which supports Apple Events can also be scripted via JXA, which works via the scripting bridge.

Past attempts by Apple and third-party developers to bring Apple event support to sophisticated scripting languages such as Ruby and Python have not seen widespread adoption. But JXA has two big advantages over previous efforts: 1) JavaScript itself is hugely popular, with a great number of users developing for web browsers and other purposes. 2) Apple has integrated support for JXA directly into Script Editor.

You can use Script Editor to view dictionaries detailing an application's commands and objects. Like AppleScript, JXA can access Objective-C and Cocoa frameworks. The latter feature has led to some excitement at the prospect of using JavaScript in Script Editor to develop native Mac OS X applications with rich interface elements. While the idea of avoiding Xcode to develop applications certainly has appeal, I'm interested to follow what kind of success JXA developers have with writing Mac OS X apps without Xcode.

AppleScript users have had access to this feature for years, but other than the good work by Doug Adams at Doug's AppleScripts for Itunes, I have yet to see many AppleScript users adding interfaces this way. Instead, Automated Workflows and other developers have used AppleScriptObjC in Xcode to develop full-featured applications, perhaps in part due to the availability of Shane Stanley's excellent book on the subject, AppleScript Objective C Explored. I would advise JXA users wanting to develop apps to read this book. It has an excellent summary of the most important Xcode features, and much of the information about when classes (coming via the scripting bridge) need to be coerced is applicable to JXA as well.

Resources for learning more about JXA include a new video from Sal, Apple's release notes, and the JavaScript for Automation presentation at WWDC 2014.

Extensions in Yosemite

Automation in the AppleScript world has often been about scripting multiple applications to interact with each other. For years I've been using AppleScript to build scripts which grab data from apps like Word, Excel or FileMaker, generate sophisticated charts and other graphics in Illustrator, use InDesign to combine it all together in a sophisticated page layout, create PDFs and then distribute the final product via e-mail, FTP or other means. AppleScript can make this into a one step-process.

The ability of Mac applications to interact with each other faced some new challenges with recent OS X sandboxing restrictions. In Yosemite, we are seeing a new effort by Apple to standardize how applications can interact: Extensions. Alex Guyot with MacStories has an excellent article covering Extensions in Yosemite. (He also discusses JXA.)

Currently, Extensions allow for some UI-centered interactivity between applications. Automation developers may find immediate use for FinderSync Extensions and possibly other types of Extensions. Will Extensions in the future allow new ways to automate complex workflows? I hope so, but much remains to be seen about how developers will employ Extensions, and if Apple will open up the technology to scripting.

The future of automation

With so many improvements I've only see one errant assumption made by a few people: With JXA, Apple is finally replacing AppleScript, some say. Wrong.

There are many reasons why AppleScript will continue in the future, but a single point is enough to make it clear. Note all of the improvements to AppleScript in Yosemite described above. Why bother if AppleScript was being replaced? Case closed.

Perhaps the more interesting thing to watch is whether JXA will see widespread adoption. I can see many users developing solutions with JXA in Script Editor. And a few going on to develop full-fledged applications in Xcode. But AppleScript developers have many great tools for development that go beyond using a basic editor while avoiding the challenges of Xcode: Late Night Software's Script Debugger, Satimage's Smile, and ASObjC Explorer are all useful development environments with different features. I'm interested to see what third-party editing and development tools will emerge for JXA, but often a strong user base must emerge first.

Regardless, with new features available in Yosemite, the future of Mac OS X automation is strong, and AppleScript will remain a big part of that.

-Ray Robertson
ray@automatedworkflows.com

Stepping in…

Apple has made a great decision in hiring Ben Waldie.

As another consultant in the automation world, I've long admired Ben’s work at Automated Workflows. He is far more than just an expert developer. He has been a great advocate for AppleScript, Automator, and other Mac-based automation technologies. Through presentations, articles, books and app store products, Ben has shown what great things can be done with Mac automation.

I also happen to know that Ben and his wife Jen are just really nice people. I’m sure great things await the Waldie family in California. In accepting the new job, I know Ben had concerns about making sure his clients and products would continue to be supported.

That's where I step in. My main goal is to provide the same great custom-developed solutions and prompt service to existing clients. I also look forward to continuing to maintain and enhance the company's excellent products, as well as taking a larger role in serving as an advocate for automation technologies.

Filling Ben’s shoes would be a difficult task for anybody. Fortunately, we share the same commitment to quality service and much of the same technical expertise. I've been working with AppleScript and other Mac automation technologies for over twenty years, and have also worked with other languages and applications. I’ve even done some iOS programming, creating an early iPad app which was recognized as New & Noteworthy by Apple.

If any tasks are outside my area of expertise, I have a network of skilled developers and consultants. A long-time associate is Shane Stanley, who many recognize as an expert in this field. Shane wrote the book on AppleScript Objective-C programming, and more recently has branched into Objective-C development with his own application, ASObjC Explorer.

As a trainer, I organized and co-taught AppleScript Pro Sessions, a five-day in-depth training event. I've led seminars for Adobe and Apple, including a very successful European tour focused on automating InDesign, Photoshop and Illustrator with AppleScript. I enjoy teaching and sharing videos with helpful tips and techniques.

Like Ben, I've been able to create some very sophisticated custom solutions for a wide range of purposes, helping individuals, small businesses, and Fortune 500 companies. I look forward to continuing this role through Automated Workflows. I've told students and clients that automation is often only limited by the imagination. I have years of experience in coming up with creative solutions to some difficult workflows.

Contact me today about saving time and money through automation, and let’s get to work!

-Ray Robertson
ray@automatedworkflows.com

 

 

Automation Changes in Mavericks – Official Tech Links

Lots of AppleScript and Automator changes were introduced with OS X 10.9 Mavericks. Here are links to official Apple technical resources that discuss some of them...

For a general overview of the automation changes in Mavericks, visit macosxautomation.com (not hosted by Apple Inc.).

2013 Penn State MacAdmins Conference > Automation Sessions

macadmins2013-logo-wide-940x298

I'm presenting two sessions at the Penn State MacAdmins conference next week:

  • Mac OS X Automation WorkshopThursday May 23, 2013 - 9:15am - 12:00pm - With AppleScript, Automator, and Services in Mac OS X, there’s more reason than ever before to begin automating time consuming and repetitive tasks. In this session, we’ll explore the potential of each of these automation technologies, discuss their benefits, and see how you can use them to boost your productivity and efficiency. Join us as we dive right in, begin creating Automator workflows, building services, and writing some simple AppleScripts. Take time to finally learn how to take advantage of these unique technologies in a relaxed “learn-by-doing” class.
  • Giving Your AppleScripts a Face LiftFriday May 24, 2013 10:45am - 12:00pm - You’ve been using AppleScript Editor on your Mac for years. You’ve developed dozens of useful scripts. It’s time to take those scripts to the next level by migrating them to AppleScriptObjC (Cocoa-AppleScript). In this session, we will expore the potential of this powerful technology. See first-hand how you can use Xcode to develop native Cocoa applications using AppleScript, complete with interfaces that allow you to capture data and provide detailed user feedback. In addition, learn how to add greater power to your AppleScript-based applications by integrating directly with Cocoa.

If you're attending, be sure and find me to say "Hi."

MacTech Article > Migrating AppleScript Studio Apps to AppleScriptObjC (Cocoa-AppleScript)

For years, AppleScript Studio provided scripters with a framework, through Xcode and Interface Builder, for implementing Cocoa interfaces in AppleScript-based apps. When it comes to AppleScript, end users are often accustomed to faceless apps that simply run when launched and quit when finished, with minimal feedback along the way. AppleScript Studio gave developers the power to implement feature-rich and user-friendly interfaces, which allowed users to configure script behavior, displayed progress during processing, and gave scripts the look and feel of virtually any other OS X app.

In August of 2009, Apple released Snow Leopard (OS X 10.6). At the same time, AppleScript Studio was deprecated and its official replacement, AppleScriptObjC, also known as Cocoa-AppleScript, was announced. AppleScriptObjC provides all of the benefits of AppleScript Studio, but with numerous additional benefits such as the ability to integrate scripts with any Cocoa framework in OS X.

Today, in Mountain Lion (OS X 10.8), Xcode no longer supports AppleScript Studio. Xcode includes project templates for creating AppleScriptObjC apps, but all references to AppleScript Studio are long gone. For long-time AppleScript Studio developers, this raises some core questions about supporting and migrating existing apps.

[Read the full article in MacTech magazine's March 2013 issue, available in print and in the MacTech iPad Newsstand app]

 

Peachpit Article > Building a Simple Image Processor with AppleScriptObjC (Cocoa-AppleScript)

My earlier article "Building a Basic AppleScriptObjC (Cocoa-AppleScript) Application with Xcode" explained how AppleScriptObjC and Xcode can be used to build robust interface-based applications for the Mac. While that article demonstrated this principle through the creation of a very simple Hello World application, the techniques provided can serve as the basis for building more advanced applications, for real-world scenarios. In this article, we'll build on those techniques to create a functional application that can perform some basic image manipulations, including flipping, rotating, and scaling a chosen image.

[Read more on the Peachpit.com...]

MacTech Article > Introduction to AppleScriptObjC (Cocoa-AppleScript)

AppleScriptObjC, also known as Cocoa-AppleScript, is a framework in OS X. It was initially released with OS X 10.6, and serves as the official replacement for AppleScript Studio, which Apple deprecated at the time. AppleScriptObjC is used by scripters to write rich, fully featured Cocoa apps in AppleScript. Think of AppleScriptObjC as the “Pro” version of AppleScript. For building simple scripts, AppleScript alone works great. For building advanced and complex scripts, perhaps with advanced interfaces, you want to think about moving to AppleScriptObjC.

If you’re a hardcore AppleScript developer or regular MacTech reader, then you’ve probably heard of AppleScriptObjC. You may have worked your way through a tutorial, and maybe even created a very simple app. If you haven’t used AppleScriptObjC yet, then you may have used Xcode in the past to develop AppleScript Studio apps. This month’s column starts with the basics. It provides a very introductory look at AppleScriptObjC. While we won’t build an actual app just yet, we’ll explore some of AppleScriptObjC’s core concepts and syntax.

[Read the full article in MacTech magazine's Fall 2012 Special issue, available in print and in the MacTech iPad Newsstand app]

MacTech Conference 2012 > Deploying an AppleScript Server

I'll be speaking about AppleScript servers at the upcoming 2012 MacTech Conference.  Hope to see you there.

-Ben Waldie

 

Deploying an AppleScript Server

AppleScript automation capabilities have existed on the Mac for years, and are widely used throughout the Mac enterprise market. Like many businesses, you may be using scripts to streamline your user workflows and improve productivity and efficiency.

In this session, you'll learn how to take scripting to the next level by deploying a dedicated AppleScript server. Find out how your users can hand off files and other data to the server for processing, allowing them to focus their attention on other important tasks. Explore ways of implementing schedule-based scripts, which can run at night or during other downtime. Get tips for migrating existing scripts to function in an unattended environment.

Any Mac professional who wants to increase efficiency, improve quality, and take workflow automation to the limit will not want to miss this session.

Attendees will learn:

  • What an AppleScript server is, and what it can do
  • Tips for implementing your own AppleScript server
  • Tips for implementing folder watching scripts
  • Tips for implementing scheduled scripts
  • Tips for migrating existing scripts for use on an unattended machine

The MacTech Conference runs from October 17-19, 2012 in Los Angeles.  It's a 3-day, immersive, technical conference specifically designed for Apple developers, IT Pros, and Enterprise.

[Learn more or register on the MacTech Conference website...]

Peachpit Article > Building a Basic AppleScriptObjC (Cocoa-AppleScript) Application with Xcode

In OS X Mountain Lion, AppleScript continues to be a powerhouse tool for controlling applications on the Mac. Whether you need to automate the creation of a few folders in the Finder, or generate a several-hundred-page product catalog in Adobe InDesign, AppleScript is waiting to lend a hand. Despite AppleScript's learning curve, Mac users everywhere are using it on a daily basis, and it saves time and money that might otherwise be wasted.

 AppleScripts aren't known for having slick interfaces. Perhaps most often, these scripts are written as simple applications, using the AppleScript Editor (found in/Applications/Utilities). When you double-click the application, it launches, performs some series of hidden tasks, and then quits. Developing script applications that work like this is quick and easy if you have the know-how, but if you're planning to distribute your script to other people, this format isn't always ideal. For one thing, aside from displaying simple dialog messages, you have no real way to let users know what your script is doing. Furthermore, unless users are AppleScript-savvy, there's no way for them to adjust the behavior of your script.

AppleScriptObjC (also called Cocoa-AppleScript) is an advanced method of developing AppleScript-based native Cocoa applications. With AppleScriptObjC, you can develop rich user interfaces and interact with them directly from your scripts. [Read more on the Peachpit.com...]

Sandboxing a Cocoa-AppleScript (AppleScriptObjC) Application

If you're a Mac developer, then you are probably aware that Apple will soon be requiring all applications submitted to the Mac App Store be sandboxed.  A sandboxed AppleScript-based application is kind of an oxymoron. Sandboxing denotes that an application will run in its own isolated environment, for security reasons.  Meaning that it doesn't have access to other applications on your Mac.  However, this goes against the nature of AppleScript, which is designed as an inter-application scripting language.  By writing AppleScripts, you can intertwine your various applications together to form complex workflows and automate time consuming things you would otherwise need to do manually.

So, how can you, an AppleScript developer, deal with sandboxing and get your app into the Mac App Store?  You can request temporary entitlements (translation: may not be supported in the future) for the apps and processes with which your app interacts.  Here are the general steps, which will vary depending on the actual function of your app:

1. Use Xcode to create your Cocoa-AppleScript app (AppleScriptObjC app)

2. In the Project Navigator, select your project

3. In the Project Editor, select your app's target

4. In the Summary tab, configure the following settings:

click to enlarge

- Enable Entitlements - Select this checkbox to turn entitlements on for your app

- App Sandbox - Select this checkbox to turn sandboxing on for your app

- File System - If you plan to use file/folder user interaction commands, such as "choose file", "choose folder", and "choose file name", then set this dropdown to "Read/Write Access".  Do the same if you plan to use commands such as "open for access" and "write".

5. In the Project Navigator, select the .entitlements file that should have been created automatically

6. Add an entry for "com.apple.security.temporary-exception.apple-events".  If you will have multiple entitlements, set this to be an array. Otherwise, set it to a string.  Add UTI entries for each application your app needs to target. For example, for the Finder, add "com.apple.finder". For iTunes, add "com.apple.itunes". If you don't add a temporary Apple Events entitlement and the necessary UTIs, then your app will produce errors when attempting to target external applications.

click to enlarge

7. If your app will write to a directory in the user's home folder, add an entry for "com.apple.security.temporary-exception.files.home-relative-path.read-write".  Set this to be an array, and add paths to any folders you will write to, beginning each with a slash. I.e. /Desktop/ represents the user's Desktop.

That should do it.  Build and run your project, and check Xcode's debug console for problems.

Download an example of a sandboxed Cocoa-AppleScript Xcode project here.

Official documentation for sandboxing an app can be found on Apple's developer website.

Note that sandboxing doesn't affect strictly AppleScript applications.  Other applications could potentially be affected, as well, including Automator* and numerous popular third-party applications.  Well, to be fair, these applications could still work.  They just couldn't be submitted to the Mac App Store once Apple's sandboxing requirement goes into effect, at least not without employing temporary entitlements.

For more on the growing controversy regarding sandboxing and inter-application communication, check out:

* In theory, Automator actions contained within a sandboxed application should not need to be sandboxed themselves.  This is because they would technically fall under the scope of the application that loads and runs them - in this case - Automator.  So, their capabilities should be governed by Automator's sandbox, which, due to the nature of Automator, should allow them to run unimpeded.