Automator and the Developer

Automator is an Apple application that lets users automate repetitive procedures performed on a computer. With Automator, users can quickly construct arbitrarily complex sequences of configurable tasks that they can set in motion with a click of a button. And they do not need to write a single line of code to do so.

All kinds of OS X users, including system administrators and developers, can derive huge benefits from Automator. It enables them to accomplish in a few seconds a complex or tedious procedure that manually might take many minutes. Developers can contribute to what Automator offers users in two ways: by making their applications scriptable and by creating loadable bundles specifically designed for Automator.

Constructing Workflows With Automator

As a developer, you can best appreciate how to integrate your software products with Automator by understanding how users might use the application, which is located in /Applications. Figure 1 shows a typical Automator workflow.

Figure 1  A typical Automator workflow
A typical Automator workflowA typical Automator workflow

A workflow in Automator consists of a sequence of discrete tasks called actions. An Automator action is a kind of functional building block. An Automator workflow hooks the actions together so that—in most cases—the output of one action is the input of the subsequent action. Clicking the run button in the upper-right corner of the window causes Automator to invoke each action of the workflow in turn, passing it (usually) the output of the previous action.

To create a workflow, users choose each action they want from the browser on the left side of the application window and drag it into the layout view in the right side of the window. They can search for specific actions by application, category, or keyword. Once dropped, an action presents a view which, in almost all cases, contains text fields, buttons, and other user-interface elements for configuring the action. In addition to configuring each action, users can move actions around in the workflow to put them in the desired sequence. They can then save the workflow as a document that can be run again and again in Automator.

Actions can be virtually anything that you can do on an OS X system (version 10.4 and later). You can have an action that copies files, an action that crops an image, an action that burns a DVD, or an action that builds a project in Xcode. Actions can either interact with applications or draw on system resources to get their work done. By stringing actions together in a meaningful sequence—that is, in a workflow—a user can accomplish complex and highly customized procedures with a click of a button. Apple provides dozens of actions for use in Automator (OS X version 10.4 and later).

Workflow Scenarios

A general description of Automator and its actions and workflows goes only so far to convey the power and flexibility of the application. To better appreciate what users can do with Automator—and how your actions can play a part in it—consider the following workflow scenarios:

Developing for Automator

Given an automation tool as powerful and flexible as Automator, it’s clear that any action you develop for it benefits both you and the user, especially if that action accesses what your application has to offer. Users have an additional path to the features and services that make your products unique, and this in turn enhances the visibility and reputation of your products.

You don’t even have to be a programmer (in the traditional sense) to develop actions for Automator. You can write an action in AppleScript as well as in Objective-C (and AppleScript actions have full access to such things as Standard Additions). You can also mix AppleScript scripts and Objective-C code when you develop an action; the script can invoke Objective-C methods implemented for the action. AppleScript has the advantage of being easier to learn, but it requires that applications that are the targets of commands be scriptable. As an object-oriented superset of ANSI C, Objective-C is a full-fledged programming language, which makes it harder to master than AppleScript but allows you to take full advantage of the Cocoa Objective-C frameworks—as well as all C-based frameworks.

If have experience in UNIX environments, you can also write shell scripts, Perl scripts, or Python scripts to drive the behavior of actions. These kinds of actions are known as shell script actions. The scripts in these actions can also work together with AppleScript scripts and Objective-C classes in an action project.

In light of these language alternatives, there are three general types of Automator actions:

From a developer’s perspective, actions have a common programmatic interface and a common set of properties. The programmatic interface is defined by four classes: AMAction, AMBundleAction, AMAppleScriptAction, and AMShellScriptAction (discussed in How Automator Works). Action properties, which are specified in an action bundle’s information property list (Info.plist), define characteristics such as:

See Automator Action Property Reference for further information on Automator action properties.

The Apple integrated development environment, Xcode, provides support for Automator action developers. There are Xcode project types for AppleScript, Objective-C, and shell script actions. Included in these project types are all required files and templates. For example, the default nib file (main.nib) contains an initial user interface, an instance of NSObjectController for establishing bindings, and File’s Owner already set up to be your action object. For more on the Automator action project types see Developing an Action.

If you install actions as part of your product, be sure to install them in /Library/Automator (if they are to be available to all users of a system) or in ~/Library/Automator (if they are to be available only to the current user). /System/Library/Automator is reserved for Apple-developed actions. You can also install actions in the bundle of the application that uses them. Automator also looks for actions in application bundles. If you provide actions, you may want to advertise them to your users so they can look forward to using them in new workflows.

Automator Actions as Universal Binaries

A universal binary is executable code that can run on either PowerPC-based or Intel-based Macintosh computers. To move a PowerPC-only project to a universal-binary project may require work involving such programming details as endianness, alignment, and calling conventions. The amount of work generally depends on the level of the source code; lower-level source code (for example, the kernel) requires more work than higher-level code (for example, an application based on Carbon).

The need to make an Automator action a universal binary depends on the language used:

For information on making universal binaries, see Universal Binary Programming Guidelines, Second Edition.