■和暦の「令和」対応
macOSでは10.14.5にアップデートしないと「令和」表示にならないもよう。ただし、和暦は日常的には（個人的に）ほとんど使っていないので影響はあるんだかないんだかわかりません。
■Notarized Service
macOS 10.14.5より、Kernel Extension/アプリケーションについては、distribute（Mac App Store経由の配布を意図しているものと思われる）にはNotarize（公証）サービスをパスすることが要求されるようになりました。
コード署名：ビルド時、およびアプリケーション書き出し時にApple開発アカウントの署名（開発者IDによる署名）を行う
Sandbox：Mac App Storeに提出するアプリケーションにおいて、Sandbox環境を前提としたランタイム環境で実行する（Xcodeのみ）
Notarize（公証）：実行バイナリの内容にコンピュータに対して害をなすような処理内容が含まれていないか、AppleのNotarizedサービスを呼び出すことで自動的に検証・証明される
コード署名以上、Mac App Storeへのアプリ審査以下、という説明をされていますが、Sandboxが前提とかいうのは無茶な気がします。
macOS 10.15上でも、さらにNotarize（公証）サービスと連携した機能が提供されることでしょう。
現時点において、自分が自分のMac上でAppleScriptで作成したアプリケーションについて、公証サービスを通しておく必要はありません。ただし、Webを通じて不特定多数に対してアプレット/アプリケーションを配布するとか、仕事で実行バイナリを納品するような場合には必要になるかもしれません。少なくとも、Mac App Store上でAppleScriptによって記述したアプリケーションを配布する場合には必要になってきます。
ただ、あのAppleの公証サービスが本当にコンピュータに有害な処理を検出できるのか？ 誤って有害ではない処理を有害判定するのではないか、という疑問はついて回ります（かのmacOS 10.13をリリースさせたTim Cook体制のやることなんて信用できない）。Sandboxで禁止されている処理ぐらいは、かんたんに回避して実行できましたし。
誤って「有害な処理を行なっている」と判定されたアプリケーションの異議申し立てや、誤って有害判定されたDevelopper IDをAppleが機械的に無効化したり、Bannするような間抜けな事態の発生が予想できすぎです（Developper向けのMailing Listが落ちて、連絡しても１か月放置するような会社にそんなものを運用する能力があるのでしょうか？）。
自分でビルドしてコード署名してNotarizedしたFrameworkぐらいは自分のホームディレクトリ下に置いて呼び出したいところです。macOS 10.14のSIPによる制限は非常にかったるくて生産性が下がります。あるいは、スクリプトエディタからもっとシステムよりのFrameworksフォルダに入れたフレームワークを呼び出せるようにするとか。
なお、Shane Stanley@Late Night Softwareが、このNotarizeサービスにアプリケーションを認証するツールを用意し、配布しています（なんとスクリプタブル！）。この、考えただけで憂鬱になるNotarizeサービスにアプリケーションを通す作業も、自動で行うことで不快感が軽減されるかもしれません。
SD NOTARY: NOTARIZING MADE EASY
