Enhanced Application Object Model

Application objects in AppleScript have some new features designed to reduce the need for awkward or obscure workarounds. In other words, the capabilities are not new, but they are now directly supported and easier to use.

Is an application running?

While the scripting support in the System Events application is capable of determining whether or not an application is running, doing so is an involved process of getting the application indentifers of the currently running processes, and then scanning that list for specific applications. In Mac OS&nbps; Leopard Application Objects now have a running property that can give you the answer directly, without invoking System Events. For example, the following script pauses iTunes, but will not launch iTunes if it is not already running:

Click to open example in the Script Editor applicationUsing the running application property to determine if an application is active:
 

tell application "iTunes"
 if it is running then
 pause
 end if
end tell

The running property does not need to appear inside a tell block; the above script could also be written like this:

Click to open example in the Script Editor applicationThe running application property can be used to limit the execution of scripts to run only when applications are open or only when application are not open:
 

if application "iTunes" is running then
 tell application "iTunes" to pause
end if

Get an application’s version

Most applications have a version property of their own, but using it requires that the application be running, and sometimes you specifically want to avoid that. The new built-in version property will return the application version as text without launching the application or sending it an event. There is also a corresponding built-in name property; the value is usable as the name of an application to tell.

Target applications by signature or bundle identifier

Sometimes you may want to target an application with a script but you’re not sure how the application is named. In Leopard, it is now possible to simply address an application object by id, where the id is either the four-character signature code or the bundle identifier. For example, application "Mail", application id "emal", and application id "com.apple.Mail" all refer to Mail.app, and will all work as the target of a tell block.

If you’re not sure of what an application’s bundle indentifier is, you can use the id property to get it:

Click to open example in the Script Editor applicationA script demonstrating how to get the value of the id property of an application, and how to use an application's id to address the application:
 

get id of application "TextEdit"
--> "com.apple.TextEdit"

tell application id "com.apple.TextEdit"
 make new document
end tell

Note that getting the value of the id property does not require that the application be running. Locating applications by id is superior to locating them by name, since users can change the application name. However, this is usually only an issue for scripts distributed to others.

Changes in Application and Script Behavior

There are two changes to application behavior to make them easier to deal with:

  • Applications launch hidden
     
    AppleScript has always launched applications if it is necessary to send them a command. However, by default they would launch in front, possibly obscuring whatever the script was attempting to show. AppleScript now launches applications hidden by default. They will not be visible unless the script explicitly says otherwise using launch, activate, or set frontmost to true.
     
  • Applications are located and re-located dynamically
     
    Application object specifiers, including those in tell blocks, are evaluated every time the script runs. This alleviates problems with scripts getting “stuck” to a particular copy of an application.

Compatibility

Uses of the built-in application properties will fall back to sending an event to the application in older versions of AppleScript, but the application may not handle them the same, or handle them at all. (Most applications will handle name, version, and frontmost; id and running are uncommon.) The other new features above require AppleScript 2.0.