Cocoa-Way – macOSでLinuxアプリをネイティブに実行するWaylandコンポジタ

 (github.com/J-x-Z)
2 ポイント 投稿者 GN⁺ 2026-03-30 | 1件のコメント | WhatsAppで共有
  • macOSでLinuxアプリケーションを仮想マシンなしで実行できるようにするWaylandコンポジタで、Metal/OpenGLベースのレンダリングを使用してmacOSのウィンドウ環境に自然に統合される
  • Unixソケットを介した直接的なWaylandプロトコル通信により性能低下を最小限に抑え、HiDPIディスプレイ最適化とサーバーサイドデコレーションをサポート
  • Rustで記述されており、ハードウェアアクセラレーションレンダリングを通じて低遅延と高効率を提供
  • SSHとwaypipe-darwinを利用してLinuxホストのアプリをmacOSのウィンドウとして表示できる
  • GPLv3ライセンスで公開されており、WindowsおよびAndroidバックエンド拡張を含むロードマップが進行中

概要

  • Cocoa-Wayは、macOSでLinuxアプリケーションをネイティブ環境のように実行できるようにするWaylandコンポジタ
  • Metal/OpenGLレンダリングを通じてmacOSデスクトップに自然に統合され、仮想マシンなしでソケットを介した直接的なWaylandプロトコル接続をサポート
  • HiDPIディスプレイ最適化、サーバーサイドデコレーション、ハードウェアアクセラレーションレンダリング機能を搭載
  • Rustで記述され、GPLv3ライセンスで配布

主な機能

  • ネイティブmacOS統合: Metal/OpenGLベースのレンダリングにより、macOSのウィンドウ管理や視覚効果との完全な互換性を維持
  • Zero VM Overhead: 仮想化なしでUnixソケットを介した直接的なWaylandプロトコル通信を行い、性能低下を最小化
  • HiDPI対応: Retinaディスプレイに合わせたスケーリングとピクセル精度を提供
  • UI完成度の向上: シャドウ、フォーカスインジケーターなどのサーバーサイドデコレーション機能を搭載
  • ハードウェアアクセラレーション: 効率的なOpenGLレンダリングパイプラインにより、低遅延と高性能を実現

インストール方法

  • Homebrewでインストール（推奨）

    • brew tap J-x-Z/tap
    • brew install cocoa-way waypipe-darwin

  • バイナリのダウンロード

    • GitHub Releasesページから.dmgまたは.zipファイルをダウンロード可能
    広告

  • ソースからビルド

クイックスタート

  • 必須コンポーネント: waypipe-darwinのインストールが必要
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • コンポジタを起動 
    cocoa-way
  • Linuxアプリを接続 
    ./run_waypipe.sh ssh user@linux-host firefox
    広告
  • SSHを通じてLinuxホストのWaylandアプリをmacOSのウィンドウとして表示

アーキテクチャ

  • macOS側にはCocoa-Wayコンポジタとwaypipeクライアントが存在
  • Linux VMまたはコンテナ側にはwaypipeサーバーとLinuxアプリが存在
  • Linuxアプリ → Waylandプロトコル → waypipeサーバー → SSH/ソケット → waypipeクライアント → Cocoa-Way → Metal/OpenGL → macOSディスプレイ
  • 全体の経路が仮想化なしで直接接続されるため、低遅延と高効率を実現

比較

ソリューション 遅延 HiDPI ネイティブ統合 設定の複雑さ
Cocoa-Way ⚡ 低い ✅ 完全対応 ✅ ネイティブウィンドウ 🟢 簡単
XQuartz 🐢 高い ⚠️ 部分対応 ⚠️ X11特有の制約あり 🟡 中程度
VNC 🐢 高い ❌ 非対応 ❌ 全画面専用 🟡 中程度
VM GUI 🐢 高い ⚠️ 部分対応 ❌ 別ウィンドウ 🔴 複雑

ロードマップ

  • ✅ macOSバックエンド (Metal/OpenGL)
  • ✅ Waypipe統合
  • ✅ HiDPIスケーリング
  • 🚧 Windowsバックエンド (win-way)
  • 📱 Android NDKバックエンド（計画中）
  • ⏳ マルチモニター対応
  • ⏳ クリップボード同期

研究背景

  • 「Turbo-Charged Protocol Virtualization」研究プロジェクトの一環として、 Rustトレイトのモノモーフィック化とSIMDベースのピクセル変換を活用したゼロコストのクロスプラットフォームWayland仮想化を探究
広告

問題解決

  • **SSHエラー「remote port forwarding failed」**が発生する場合、リモートホストに残ったソケットファイルが原因
    • run_waypipe.shスクリプトは-o StreamLocalBindUnlink=yesオプションで自動処理
    • 手動実行時: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

貢献

  • 機能追加や変更の前にIssueを登録して議論することを推奨
  • Pull Requestによる貢献を歓迎

ライセンス

  • GPL-3.0
  • 著作権 © 2024–2025 J-x-Z

関連記事

1件のコメント

 
GN⁺ 2026-03-30
Hacker Newsのコメント

  • 正直なところ気になることがある。Linux GUIアプリで、macOS向けのネイティブビルドが存在しないものって何があるんだろう。たいていはQtやGTKベースでマルチプラットフォームだし、ぱっと思い浮かぶ人気アプリがない

    • 本題はそこではない。これは リモートのLinuxホスト上のアプリをローカルのウィンドウとして実行するためのものだ。たとえば、MacでVS Codeをリモートサーバーのウィンドウとして表示したり、研究室のクラスタ上のMatlab GUIにアクセスしたりする用途。X11なら xpra で似たことができる
    • 人気アプリは多くないが、集積回路設計分野にはLinux専用アプリがたくさんある。Macでコンテナ経由で動かしてみたが、XQuartzがあまりにひどかった。Waylandに移行すればかなり良くなるかもしれない。ARMビルドが出始めているものもあるので、いずれネイティブなMac GUIも可能になるかもしれない
    • 個人的に興味深い理由は2つある。1つ目は、Siri向け開発環境をタイル型ウィンドウ管理で使いたいが、Appleのエコシステムに縛られているので、こういう方式はかなり良い代替案になりそうだということ。2つ目は、IridiumのNiagara WorkbenchのようにLinuxしか対応していないアプリがあり、Quartzのサポート終了後は不便だったことだ
    • 自分は単純に KDE Plasma を使いたい。macOSのインターフェースは正直あまり好きではない
    • 単にLinuxアプリを動かすだけでなく、リモートのLinuxサーバーのグラフィカルアプリをローカルで実行する用途にも使える

  • 完璧だ。これでコンテナ内でGUIアプリを動かせるようになる。以前X11で似たようなことを試したが気に入らなかった。だんだん Appleのデスクトップでの存在感 が弱くなっている気がする。結局、誰もが「開発者」になる時代が来るのではないかと思う

    • Appleのデスクトップ市場での立場が弱くなっているとは言うが、実際には昔からLinuxよりシェアは高かった。大きな変化はなさそうだ
    • 自分はプロジェクトごとに 隔離されたコンテナ環境 を開いて使いたい。ParallelsのWindows統合モードのように、セキュリティと集中のためにアプリをグループ化するのが目的だ

  • このプロジェクトは少し 怪しい。READMEは絵文字だらけで実装の説明もない。Metalバックエンドがあると言っているが、実際には存在しないようだ。依存関係のリストもおかしい

    • まったく使う価値がない。どの ハイパーバイザー を使っているのかも明かしていない。QEMUなのかDockerなのかもわからない。表も変だ。VMがいちばん設定しやすいはずなのに、ここでは逆に書かれている。コードもOpenGL 3.3 Coreを使っていて古すぎる。おそらく LLMが生成したコード である可能性が高い。最近のAIコードは過大評価されていると感じる。見た目だけは立派だが中身がない。以前AnthropicがRust製のCコンパイラの宣伝用に出したプロジェクトを思い出す

  • こういうものは Android向け にも必要だ。termux-x11は出発点にはなるが、termuxがWaylandをサポートするか、AndroidのLinux VMからWaylandソケットを公開できれば、残るのは滑らかなレンダリングのためのネイティブコンポジターだけだ

  • もしmacOSがGUIなしの Darwinシェルモード で起動できたなら、KDEやCOSMICのようなデスクトップ環境にbrewパッケージマネージャーを載せた、すばらしいUNIXになっていただろうと思うと惜しい

    • それなら、そもそもmacOSを使う理由があるのかと思う。インターフェースを除けば、DarwinはFreeBSDやGNUと大差ない
    • Macのカーネルは性能も低く、パッケージ管理もnixより劣っている
    • Intel Mac時代にはシングルユーザーモードがあったが、その時でもフレームバッファの制御はできなかった

  • これが可能なら、macOSベースの WaylandクライアントがEGLサーフェスを生成 できるのかも気になる

  • もしかしてOrbstackの中でWaydroidを使って Android環境を実行 できるだろうか。理論上はいけそうだ

  • macOSを Windows/Linux風のキーボードショートカット に変えられれば、ずっとストレスが減ると思う

    • それは間違った考えだ。macOSのショートカットはターミナル作業に最適化されている。システムショートカットが別のキーを使うので、controlコードと衝突しない
    • 設定でcmdとctrlキーを入れ替えることもできるし、Karabiner-Elementsで完全にカスタマイズすることもできる。自分も最初は混乱したが、1週間あれば慣れる。今ではむしろWindowsのショートカットのほうが使いづらい。Commandキーの歴史 も面白い
    • ターミナルでctrl+shiftを使わなければならないのは本当にひどい。macOSのショートカット体系 のほうがずっと良いと思う
    • 個人的には、ほとんどのショートカットにSuperキーを使うほうが良いと思う。Windowsではスタートメニュー専用で無駄になっている
    • 実際、Karabiner-Elementsでcmd、option、controlキーをそれぞれctrl、alt、superのようにマッピングして使っている。macOSの標準設定だけでもある程度は可能だが、左右のキーを別々に変えるならKarabinerが必要になる。意外にも Apple製品にしてはかなり柔軟な設定 だ

  • このプロジェクトが GNUstep に少しでも関心を呼び起こせるのか気になる