どのリンクにも、あるべき場所がある。Burlyがそこへ届けます。

「このリンクをあのプロファイルで開く」は、API呼び出し1回で済みそうに聞こえます。しかしMacでは、ブラウザの系統ごとに異なる3つの問題があり、どれも機能としては文書化されていません。

Safariにはプロファイルを起動する方法がありません。 「これをWorkプロファイルで開く」ためのコマンドラインフラグも、URLスキームも、AppleScriptの命令もありません。確実な方法は、人が操作するのと同じ手順だけです。BurlyはmacOSのアクセシビリティAPIを使ってSafari自身の新規Workウインドウメニュー項目を押し、そのウインドウが開くのを待ってからリンクを渡します。System Events経由でSafariを操作するほうが簡単そうに見えましたが、別の「オートメーション」の許可が必要で、その取得が不安定なためうまくいきませんでした。さらにmacOS 15では、Appleがこれらのメニュー項目をサブメニューに移したため、1階層下まで探す必要があります。Burlyはこれらの項目をタイトルではなく、Safariが翻訳しない識別子で見つけるので、macOSがどの言語でも動作します。Safariのプロファイル振り分けに「アクセシビリティ」の許可が必要なのも、このためです。

Chromeが求めるのは、表示されるプロファイル名ではなくフォルダ名です。 Chromium系ブラウザは、プロファイルメニューに表示される「仕事」のような名前ではなく、Profile 1のようなディレクトリ名でプロファイルを開きます。Burlyは各ブラウザ自身のプロファイル一覧をディスクから読み取って両者を対応づけ、そのファイルを監視しているので、Chromeで追加したプロファイルは更新操作なしでピッカーに表示されます。

押されているキーは、リンクが届いた瞬間に読み取る必要があります。 修飾キーによるバイパスは、macOSがリンクを渡した時点でどのキーが押されているかを確認することで機能します。クリックのたびにゼロから起動するアプリでは、素早いOptionクリックを取りこぼすことがよくあります。Burlyが毎回起動し直すのではなく、メニューバーに常駐している理由のひとつです。

クリックするすべてのリンクの前に立つアプリは、簡単に信頼できるものであるべきです。Burlyのすべてのリリースは、Apple Developer IDで署名され、Appleによって公証されています。そのため、macOSが初回起動前にチェックし、Gatekeeperが警告なしで開きます。アップデートはSparkleで配信され、それぞれがインストール前に暗号署名で検証されるので、アプリが自分自身を置き換えられるのは、私が署名したビルドだけです。

振り分けはすべてMac上で完結します。Burlyにはアカウントも、リンクを見るサーバーもなく、漏れる閲覧履歴もありません。