最初の10.15betaを使って３分で発覚した「aliasをposix pathに変換すると末尾がおかしくなるバグ」が修正されて一安心であるものの、Release時にさまざまなバグが再発する昨今のmacOS。

OSリリースの仕組みが会社組織的にうまく稼働していないことを感じます。とくに、CoreOSチーム。macOS 10.12でNSNotFoundの定義値を間違えたのは、間違いなくCoreOSチームなので。さらに、macOS 10.13の時にはBetaでうまく動いていたものがRelase時に動かなくなって言葉を失いました。

その後、macOS 10.13はOSごとまともに動いていなかったので（不具合に遭遇しない日はなかったので）、その反動でmacOS 10.14の自分的な評価がやたらといい今日このごろです。macOS 10.13みたいに「LAN上のファイル共有機能がいきなり効かなくなる」「日本語入力時に変換ウィンドウが消えなくなる」といった激しいバグには遭遇していません。ただ、10.13で壊滅的だったMail.appまわりのバグはいまだに信用できないので、10.14でもメールのやりとりはしないようにしています。
→ 最終バージョンの10.14.6の段階でメイン環境を移行し、目立った問題には遭遇していません

64bit Only環境の後ろ向きなメリット

各ビルドごとにmacOS 10.15 Betaのリリースノートがまとめて掲載されていますが、全体的に変更点が多くて驚かされます。

正直、macOS 10.15でこれだけOS内部のサービスやらフレームワークをいじくってしまうと、サードパーティ側がそれに追いつくのに相当の時間がかかるものと思われます。こんな大々的な変更を伴うアップデートを毎年行うべきものなのか疑問です。

ただ、64bitバイナリのみサポートするOSに移行するメリットが見えてきました。ユーザーにとって処理能力が上がるとかバッテリー寿命が伸びるとか、そうした目に見えやすいメリットではありません。

32bit版のバイナリを許容するということは、Apple側も32bit版バイナリとか32bitバイナリしか作れない古めの開発環境（互換開発環境とか？）に対応する必要があるわけで、32bitバイナリを検証し続けるほどのマンパワーがないんでしょうね。具体的にいえばCarbon系なんですが。

これまで、32bitバイナリ実行の検証に費やしていたパワーを、機能追加などに振り分けることにしたい、ということなのだと理解しました。ちなみに、2019年６月末でAppleのCarbon Dev MLが廃止になりました。MLのダウン時にはさんざん報告してもまともに対処しないくせに、こういう動きだけ素早いのはどうかと思います。

＃　AppleScriptの処理系はmacOS 10.7の時に64bit化されているため、64bit専用のOSになっても問題はありません。たまに間違った知識を吹聴している人がいるので念のため

BridgePlus.frameworkが（まだ）呼べない

実際に、Frameworkのバイナリ形式が変更になった（らしい）ので、macOS 10.15向けには野良Frameworkなどはビルドし直さないとダメなようです。いわく、32bitバイナリがあると文句を言われるのどうの。

目下、AppleScript関連でこの影響を最も受けているのがShane StanleyのBridgePlusライブラリ。内蔵のFrameworkをload frameworkコマンドで呼び出すと文句を言われます。

Shane次第ですが、おそらくこれはmacOS 10.15のリリースまでに解消されることでしょう（多分）。普通にXcode＋10.14上でビルドしたしょーもないFrameworkが10.15上で動作（GundamのMS画像をCreateMLで学習させてZeonかEFSF所属かを判定させるFramework）しているので、それほど心配はしていません。

→ その後、Shaneからメールが来て「ちょっとこれ試してみて」と、xattrの削除を提案され、実際にやってみたらBridgePlusが動くようになりました。BridgePlusが動かなかったらけっこうきついので、一安心です

macOS 10.15 Beta5の変更点

macOS 10.15Beta5のRelease Notesに書かれている、重大な変更点が１つあります（処理系に手が加わっていないのにOS側のアップデートでいろいろ機能制限が出る今日このごろ）。

ネットワーク経由のAppleEvent実行、つまり現状ではLAN上のMac同士で、AppleScriptの常駐型のアプレットを起動して、ハンドラを一方から、あるいは相互に呼び合うことができます。いわゆるリモートAppleEventです。ここに手が加わりました。

この場合、呼ぶ側（Client）も呼ばれる側（Server）も、同じアカウントでログインしている必要がある、という変更です。この際に、「同じアカウント」というのがUser IDなのか、User名なのか、iCloud IDなのかが不明です。複数のmacOS 10.15betaマシンを用意しているわけではないのですが、物理的に可能で意味がありそうなのは同一のiCloud IDでしょうか（未検証）。

その後、macOS 10.14.6のマシン環境からRemote AppleEventsでLAN上のmacOS 10.15beta上で起動中のAppleScript Applet（常駐型）に向けてハンドラの呼び出しを行ってみたところ、同じユーザー名のアカウント同士で呼ぶことができました（使用中のiCloud IDも同じなので、何が基準なのか厳密にテストできていないんですけれども）。

どのユーザーアカウントからのリモートAppleEvent接続でもアプリケーション（AppleScriptアプレット）が応答可能にするためには、受付側（Server）のMacでTerminalから設定コマンドを打ち込めとのこと。

defaults write /Library/Preferences/com.apple.AEServer RestrictAccessToUserSession -bool false

その後、システム環境設定の「共有」でリモートAppleEventsを禁止＞許可と設定すると、他のユーザーセッションからでも制御（ハンドラ呼び出し）を受け付けるようです（未検証）。

リリースノートを一通り読んで、変更点がやたらと多いのと「罠」が多い（VPN接続時にAirDropが使用停止になる仕様など）ので、こなれるまで10.15は「待ち」だと感じています。最近のmacOSはRelese時の出来が一番ひどいので、１年かけて公式デバッグを行っているようなもの。しばらくmacOS 10.14を使い続けるのがベストでしょう。