atask that took a team of twenty up to a month for a single
An AppleScript script automates the entire process. The
scriptreads the priceanddescriptive textfromthe FileMaker
Pro database and inserts it into appropriate QuarkXPress
ﬁelds. The script applies special formatting: it deletes the
decimal point in the prices and superscripts the cents (e.g.
.To make the text ﬁt precisely in the width of the en-
closing box, the script computes a fractional expansion fac-
tor for the text by dividing the width of the box by the width
of the text (this task was previously done with a calculator).
It adjusts colors and sets the ﬁrst line of the description in
boldface type. Finally, it adds special markers like “Buy 2
get 1 free”and “Sale price $17
”where speciﬁed by the
Once this process is automated, one person can produce
the entire catalog in under a day, a tiny fraction of the time
taken by the manual process. It also reduced errors during
copying and formatting.Of course, creatingandmaintaining
the scripts takes time, but the overall time is signiﬁcantly
reduced over the long run.
6.3 Scripting Tools
AppleScript included a simple and elegant script editor cre-
ated by Jens Alfke, who had graduated from Caltech and
worked with Kurt Piersol at Xerox Parc on Smallktalk-80
applications. Jens was one of the key developers on the Ap-
pleScript team; he focused on tools,consistencyof the APIs
andusability of the overall system.
Soon after AppleScript was released, more powerful
script development environments were created outside Ap-
ple. They addressed one of the major weaknesses of Apple-
Script:lackofsupportfor debugging. One developeroutside
Apple who took on this challenge is Cal Simone, who has
also been an unofﬁcial evangelist for AppleScript since its
inception. Cal createdScripter,whichallows usersto single-
step through a script. It works by breaking a script up into
individual lines that are compiled and executed separately.
statements are preserved around each
line as it is executed.Scripter also allows inspection of local
variables and execution of immediate commands within the
context of the suspended script.ScriptDebuggeruses a dif-
ferent technique:itadds aspecialApple Eventbetweeneach
line of a script. The Apple Event is caught by the debugger
and the processing of the script is suspended. The current
values of variables can then be inspected. To continue the
script,the debugger simply returns from the event.
AppleScript also enables creation of sophisticated inter-
face builders. The interface elements post messages when
auser interacts with them. The user arranges the elements
into windows, menus, and dialogs. Scripts may be attached
to any object in the interface to intercept the messages be-
ing sent by the interface elements and provide sophisticated
behavior and linking between the elements. Early applica-
tion builders included Frontmost
,a window and dialog
builder, and AgentBuilder
,which specialized in commu-
nication front-ends. Version 2.2 of HyperCard, released in
1992, included support for OSA, so that AppleScript orany
OSA language could be used in place of HyperTalk.
Two major application builders have emerged recently.
FaceSpan, originallyreleased in1994,has grown into a full-
featured application development tool. FaceSpan includes
an integrated script debugger. Apple released AppleScript
Studio in 2002 as part of its XCode development platform.
Acomplete application can be developed with a wide range
of standard user interface elements to which scripts can be
attached. AppleScript Studio won Macworld Best of Show
Awards at the 2001 Seybold Conference in San Francisco.
In 2005 Apple released Automator, a tool for creating
sequences of actions that deﬁne workﬂows. Automator se-
quences are not stored or executed as AppleScripts, but can
contain AppleScripts as primitive actions. The most inter-
estingthing about Automator is thateach action has aninput
and an output, much like a command in a Unix pipe. The
resulting model is quite intuitive and easy to use for simple
Although Apple Events are normally handled by appli-
cations, it is also possible to installsystemeventhandlers.
When an Apple Event is delivered to an application, the ap-
plicationmayhandlethe event orindicate thatitwasnothan-
dled.When an application does nothandle an event,the Ap-
ple Event manager searches for a system event handler. Sys-
tem event handlers are packaged inscriptextensions (also
known as OSAX) and are installed on the system via Script-
ing Additions that are loaded when the system starts up.
6.4 Scriptable Applications
Eventually, a wide range of scriptable applications became
available: there are currently 160 scriptable applications
listed on the Apple web site and the AppleScript source-
book . Every kind of application is present, including
word processors, databases, ﬁle compression utilities, and
development tools. Many of the most popular applications
are scriptable, including Microsoft Ofﬁce, Adobe Photo-
shop, Quark Expression, FileMaker, and Illustrator. In ad-
dition, most components of the Mac OS are scriptable,
including the Finder, QuickTime Player, Address Book,
iTunes, Mail, Safari Browser, AppleWorks, DVD Player,
Help Viewer, iCal, iChat, iSync, iPhoto,and control panels.
Other systems also beneﬁtted fromthe infrastructure cre-
ated by AppleScript. The Macintosh AV
tion system uses AppleScript, so any scriptable application
can be driven using speech.
After version 1.1, the evolution of AppleScript was driven
primarily by changes in the Macintosh OS. Since Apple-
Scriptwasﬁrst released,the operatingsystemhas undergone
twomajorshifts,ﬁrst whenApple moved fromthe Motorola
68000 to the PowerPC chip, and then when it moved from
the Classic Macintosh OS to the Unix-based OS X. Few
changes were made to the language itself, while scriptable
applications and operating system components experienced
rapid expansion and evolution. A detailed history with dis-
cussion of new features, bugs, and ﬁxes can be found in the
AppleScript Sourcebook ,which we summarize here.
The ﬁrst upgrade to AppleScript, version 1.1.2, was cre-
ated for Macintosh OS 8.0, introduced in July 1997. De-
spite the rigorous source code conﬁguration process (see
Section 5), Apple could not ﬁgure out how to compile the
system and contracted with Warren Harris to help with the
job. A number of bugs were ﬁxed and some small enhance-
mentswere madetoconformto MacintoshOS8.0standards.
Atthe same time several systemapplications and extensions
were changedin ways that couldbreak old scripts.The most
important improvement was a new scriptable Finder, which
eliminated the need for a Finderscripting extension.
In 1997 AppleScript was at the top of the list of features
to eliminate in order to save money. Cal Simone, mentioned
in Section 6.3, successfully rallied customers to rescue Ap-
In October 1998 Apple released AppleScript 1.3 with
UNICODE support recompiled as a native PowerPC exten-
sion; however, the Apple Events Manager was still emulated
as Motorola 68000 code. The dialect feature was no longer
supported; English became the single standard dialect. This
version came much closer to realizing the vision of uni-
form access to all system resources from scripts. At least
ple Video Player and Users & Groups,were now scriptable.
New scriptable applications appeared as well,including Mi-
crosoft Internet Explorer and Outlook Express.
The PowerPC version of AppleScript received an Eddy
Award from MacWorld as “Technology of the Year” for
1998 and was also demonstrated in Steve Jobs’ Seybold
1998 address. In 2006, MacWorld placed AppleScript as
#17 on its list of the 30 most signiﬁcant Mac products ever.
AppleScript was a long-term investment in fundamental in-
frastructure that took many years to pay dividends.
The most signiﬁcant language changes involved the
statement. For example, the
class used to identify
remote applications was extended to accept URLs (see Sec-
tion 3.2), allowing AppleScript control of remote applica-
tions via TCP/IP.
When Mac OSXwas releasedinMarch 2001,it included
AppleScript 1.6. In porting applications and system compo-
nents to OSX,Apple sometimes sacriﬁcedscriptingsupport.
Asa result,therewas asigniﬁcant reductioninthenumberof
scriptable applications after the release of OS X.Full script-
ability is being restored slowly inlaterreleases.
In October2006,Google reported anestimated 8,570,000
hits forthe word “AppleScript”.
AppleScript was developed by a small group with a short
schedule, a tight budget and a big job. There was neither
time nor money to fully research design choices.
to remotecommunicationinhigh-latencyenvironments .
Object references are symbolic paths, or queries, that iden-
tify one ormore objects in anapplication.Whena command
is applied to an object reference, both the command and the
object reference are sent (as an Apple Event containing an
object speciﬁer) to the application hosting the target object.
The application interprets the object speciﬁer and then per-
forms the action on the speciﬁed objects.
In summary, AppleScript views an application as a form
of object-oriented database. The application publishes a
specialized terminology containing verbs and nouns that
describe the logical structure and behavior of its objects.
Names in the terminology are composed using a standard
query language to create programs that are executed by the
remote application. The execution model does not involve
remote object references and proxies as in CORBA. Rather
than send each ﬁeld access and method individually to the
remote application and creating proxies to represent inter-
mediate values, AppleScript sends the entire command to
the remote application for execution. From a pure object-
orientedviewpoint,the entire application is the only real ob-
ject; the “objects”within it are identiﬁed only by symbolic
After completing AppleScript, I learned about COM
and was impressed with its approach to distributed object-
oriented programming. Its consistent use of interfaces en-
ables interoperability between different systems and lan-
guages.Although interface negotiationis complex,invoking
amethod through an interface is highly optimized. This ap-
proach allows ﬁne-grained objects that are tightly coupled
through shared binary interfaces. For many years I believed
that COM and CORBA would beat the AppleScript com-
munication model in the long run.However, recent develop-
ments have made me realize that this may not be the case.
AppleScript uses a large-granularity messaging model
that has many similarities to the web service standards that
began to emerge in 1999 . Both are loosely coupled and
descriptors are similar to XML in that they describe arbi-
trary labeled tree structures without ﬁxed semantics. Apple-
Script terminologies are similar to web service description
language (WSDL) ﬁles. It is perhaps not an accident that
Dave Winer, who worked extensively with AppleScript and
Apple Events, is also one of the original developers of web
service models. There may be useful lessons to be learned
for web services, given that AppleScript represents a sig-
niﬁcant body of experience with large-granularity messag-
ing. One difference is that AppleScript includes a standard
query model for identifying remote objects. A similar ap-
proach could be useful for web services.As Iwrite in 2006,
Isuspect that COM and CORBA will be overwhelmed by
web services, although the outcome is farfrom certain now.
AppleScript is also similar to traditional database inter-
faces like ODBC . In AppleScript the query model is
integrated directly into the language, rather than being exe-
cuted as strings as in ODBC. A similar approach has been
adopted by Microsoft for describing queries in .NET lan-
User tests revealed that casual users don’t easily under-
stand the ideaof references, or having multiple references to
the same value. It is easier to understand a model in which
Thefeedbackfromusertestsinearly 1993was too late in the
development cycle to address this issue with anything more
than a cosmetic change, to use
Writing scriptable applications is difﬁcult. Just as user
interface design requires judgment and training, creating a
good scripting interface requires a lot of knowledge and
careful design. It is too difﬁcult for application developers
to create terminologies that work well in the naturalistic
grammar. They must pay careful attention to the linguistic
properties of the names they choose.
The experiment in designing a language that resembled
natural languages (English and Japanese) was not success-
ful. It was assumed that scripts should be presented in “nat-
ural language”so that average people could read and write
them. This lead to the invention of multi-token keywords
and the ability to disambiguate tokens without spaces for
Japanese Kanji. In the end the syntactic variations and ﬂex-
ibility did more to confuse programmers than to help them
out. It is not clear whether it is easier for novice users to
work with a scripting language that resembles natural lan-
guage,withallits specialcases and idiosyncrasies.Themain
problem is that AppleScript only appears to be a natural
language: in fact, it is an artiﬁcial language, like any other
programming language.Recording was successful, but even
small changes tothe scriptmayintroduce subtlesyntacticer-
rors that bafﬂe users. It is easyto read AppleScript,but quite
hard to write it.
When writing programs or scripts, users prefer a more
conventional programming language structure. Later ver-
sions of AppleScript dropped support for dialects. In hind-
sight, we believe that AppleScript should have adopted the
Professional Dialect that was developed but nevershipped.
Finally, readability was no substitute for an effective se-
curity mechanism. Most people just run scripts—they don’t
read or write them.
AppleScript is widely used today and is a core technol-
ogy of Mac OS X. Many applications, including Quark Ex-
press, Microsoft Ofﬁce, and FileMaker, support scripting.
Small scripts are used to automate repetitive tasks. Larger
scripts have been developed for database publishing, docu-
ment preparation, and even web applications.
There are many interesting lessons to be learned from
AppleScript. On a technical level, its model of pluggable
embedded scripting languages has become commonplace.
The communication mechanism of Apple Events, which is
certainly inferior to RPC mechanisms for single-machine or
in-process interactions, may turn out to be a good model
for large-granularity communication models such as web
services. Many of the current problems in AppleScript can
be traced to the use of syntax based on natural language;
however,theabilitytocreate pluggable dialects mayprovide
asolution in the future, by creating a new syntax based on
conventional programming languages.
Thanks to Jens Alfke, Paul Berkowitz, Bill Cheeseman,
Chris Espinosa, Michael Farr, Steve Goldband Tom Ham-
mer, David Hoerl, Alexander Kellett, Wayne Malkin, Matt
Neuburg, Chuck Piercey, Hamish Sanderson, and Stephen
Weyl, for discussions about this paper. Special thanks to
Andrew Black and Kathleen Fisher for their guidance, en-
couragement, ﬂexibility, and careful reading of my work in
 Alfred V. Aho and Jeffrey D. Ullman. . Principles of
and information processing). Addison-WesleyLongman
Publishing Co.,Inc., Boston, MA, USA, 1977.
 AppleComputerInc.AppleScriptLanguageGuide. Addison-
 Gavin Bierman, Erik Meijer, and Wolfram Schulte. The
essence of data access in c
 Don Box, David EhneBuske, Gopal Kakivaya, Andrew
Layman, Noah Mendelsohn, Henrik Frystyk Nielson, Satish
Thatte, and DaveWiner. Simple object access protocol 1.1.
 Gilad Bracha and William Cook. Mixin-based inheritance.
Systems, Languagesand Applications,pages303–311,1990.
 Peter Canning, William Cook, Walt Hill, John Mitchell,
and Walter Olthoff. F-bounded polymorphism for object-
oriented programming. InProc.ofConf.onFunctional
Programming Languagesand Computer Architecture,pages
 Peter Canning, William Cook, Walt Hill, and Walter Olthoff.
Interfaces for strongly-typed object-oriented programming.
Systems, Languagesand Applications,pages457–467,1989.
 Bill Cheeseman. Applescript sourcebook.
Documents you may be interested
Documents you may be interested