Automatorのワークフロー記述の一部としてAppleScriptを使用することもできる。Automator上のアクション「AppleScriptを実行」がスクリプトエディタに近い機能（ログ表示、結果表示）を持つが、他のAppleScript対応アプリケーションのAppleScript用語辞書をブラウズしたり、途中で実行を停止させるなどの機能はない。
スクリプトエディタ上で記述して、アプリケーションとして保存、あるいはアプリケーションとして書き出したものである。この形態のものをアプレットと呼ぶ。アプレット実行時にはアプレット用のランタイム環境が用意されている。この環境で実行すると、on idleによるタイマー割り込み、ファイルやフォルダをドラッグ＆ドロップ受信する機能、ハンドラの実行後に終了しない、プログレスバーの表示機能（Mac OS X v10.10より）などの機能が利用できる。ファイル/フォルダのドラッグ＆ドロップを受け付けるアプレットをドロップレットと呼んで区別する（アイコンが異なる）が、ランタイム環境は同じである。アプレット実行時にログ表示などの機能は利用できないため、この実行形態のままではバグの確認や修正が困難である。アプレットとして書き出す前にスクリプトエディタ上で内容に問題がないことを確認する必要がある。
スクリプトエディタ上に記述して、スクリプトエディタ上で実行する形態である。この際の実行環境はスクリプトエディタであり、途中でAppleScriptの実行を停止させたり、ログ表示させた内容を確認したりできる（ログ表示させると実行速度がいちじるしく低下する）。セキュリティ上の制約がもっとも少ない実行環境でもあり、他の実行環境では動かせないコードもこの環境で動くケースが多い。
AppleScriptは中間コードに翻訳されて逐次実行されるが、以下のようなさまざまな保存・実行環境（ランタイム環境）を持つため、実行環境によって動作が微妙に異なり、想定していた通りに動かない場合がある。また、実行中のログ表示が行えるのはスクリプトエディタでオープンしてスクリプトエディタで実行させた場合、およびXcode上で作成してデバッグビルドを行なっている場合の２つのケースにかぎられる。フォルダアクションで実行中のAppleScript書類をスクリプトエディタでオープンさせたからといって、フォルダアクションで実行中のAppleScriptのログがスクリプトエディタ上にログ表示されることはない。
Mac OS X v10.9以降で、AppleScript自体をライブラリ化して再利用できるようになった。さらに、このライブラリにはAppleScript用語辞書を持たせることが可能なため、AppleScriptの命令語をAppleScriptで記述したライブラリによって拡張することが可能である。
Mac OS X v10.10以降では、Apple純正およびサードパーティー製CocoaフレームワークをAppleScriptから直接呼び出すことが可能となっている。また、コンタクト（住所録）やカレンダーの情報をフレームワーク経由で検索・操作できるようになった。iTunes Libraryの検索もiTunes.app経由やiTunes Music Library.xmlを検索するよりも高速に行える。
iOS上でAppleScriptが動くわけでも、iOSのアプリケーションを直接コントロールできるわけでもないが、iCloudを経由して間接的にデータの変更を行える。たとえば、macOS上のリマインダーを更新するとiOS上のリマインダーも更新される。これを利用して、iOS側に大量のデータを登録したい場合にMac上でAppleScriptなどによってデータを追加するといった方法が可能である。また、iPhoneとひもづけされたMacからAppleScriptを用いて電話をかけたりSMSメッセージを送信したりもできる。iOSシミュレータ上で動くiOSアプリケーションもGUI Scriptingにより操作や情報の取得などが可能である。そのため、AppleScriptからシミュレータ上のiOSアプリを操作し、操作テストを実施して段階ごとに画面キャプチャを記録することも行われている。
SOAP、XML-RPCを呼び出すための命令が標準で装備されている（call soap、call xmlrpc）。Cocoaの機能を用いてRESTful APIを呼び出すことも可能である。これらのサービスが存在しないサイトに対しても、Safariのdo JavaScriptコマンド経由で操作したり、GUI Scriptingで強制的に操作することで、Webサービスにログインして必要な情報を取得するなどの処理が可能である。
macOS標準装備の「リモートApple events」の機構を用いて、TCP/IPネットワーク（主にLAN）内の他のMac上のアプリケーションをコントロールできるようになっている。ただし、セキュリティ確保のためmacOS標準装備のアプリケーションの多くは、この機能が禁止されているほか、OSのデフォルト設定ではリモートApple eventsはオフになっている。1台のMacでは処理が追いつかない場合、この機構を用いて複数台のMacに仕事を割り振り分散処理を行うことができる。また、Mac上で稼働する仮想環境上でmacOSを動作させ、仮想環境との間での分散処理も可能である。
科学捜査など望むべくもない時代において、事件の犯人を知る手段は限られていた。とにもかくにも「一件落着」させる現実的方法の需要があった。それぞれの立場で神判を必要としている人々がいたのである。神判はキリスト教にとっては、有力な布教のツールであった。もとは当地の風習と折り合うために容認したものであったが、聖職者が神判を主宰することで、神判は身内の儀式ではなく社会的拘束力を持つ裁判手続となりえた。神判で有罪か否かを判定してみせることで、キリスト教の神の正しさ・優位性を人々に示すことができた。王や諸侯といった世俗支配者は、神判を便利な道具として活用していた。神判を行う場所や立ち会いを規定することは、王の権力を分かりやすく見せつける一種のプロパガンダ効果があった。それどころか、政敵に嫌疑をかけて神判を強制することすら行われた。民衆のレベルでは、中世当時に合理的思考はほとんど浸透しておらず、世界のできごとや自然現象はすべて神の意志によるものと考えられていた。近代的な意味での真実など求められてはいなかったのである。神判のような儀式で罪の有無を決することは、当時の人々にとって、まことに正しきことであり、何より神判は証拠や雪冤宣誓などよりずっと盛り上がるイベントであった。神判以外に有罪無罪を決するには雪冤宣誓がしばしば利用されたが、この宣誓に対しては根強い不満があった。特に貴族階級が集団でフェーデの名のもとに盗賊まがいの乱暴狼藉を働き、その彼らが仲間内で雪冤宣誓の人数を揃えれば無罪となる。当時の人々もこれは容認するところではなく、神判は雪冤宣誓への不満を解消する良い方法なのであった。