Cocoa-Way – Linuxアプリをシームレスに実行するためのネイティブmacOS Waylandコンポジタ

2026年3月28日原文(github.com)

概要

Cocoa-Way は、macOS上でLinuxアプリを ネイティブ描画 するためのWaylandコンポジタ VM不要 でUnixソケット経由の高速通信を実現 HiDPI対応 や サーバーサイド装飾 など洗練されたUI Homebrew やバイナリで簡単インストール Turbo-Charged Protocol Virtualization 研究の一環

Cocoa-Way：LinuxアプリをmacOSでネイティブ動作

macOS Metal/OpenGL対応 による高品質な描画とシームレスなデスクトップ統合
VM不要、WaylandプロトコルをUnixソケット経由で直接やり取り
Retinaディスプレイ最適化、HiDPIスケーリング対応
サーバーサイド装飾、影やフォーカスインジケーターによる洗練UI
OpenGLハードウェアアクセラレーション で高速描画
Homebrew推奨インストール、簡単なコマンドで導入可能
バイナリ配布 （.dmg/.zip）やソースビルドにも対応
- 依存パッケージ：libxkbcommon、pixman、pkg-config
- GitHubからクローンしてcargo build --releaseでビルド

クイックスタート

必須：waypipe-darwinのインストール
- brew tap J-x-Z/tap && brew install waypipe-darwin
コンポジタ起動 ：cocoa-way
Linuxアプリ接続 ：./run_waypipe.sh ssh user@linux-host firefox

アーキテクチャ

macOS側
- Cocoa-Way（Waylandコンポジタ）
- waypipeクライアント
Linux側（VM/Container）
- waypipeサーバー
- Linuxアプリ（Firefoxなど）
通信経路
- Linuxアプリ⇔Waylandプロトコル⇔waypipeサーバー⇔SSH/Socket⇔waypipeクライアント⇔Waylandプロトコル⇔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 で自動処理
- 手動実行時も同様のオプション付与で解決

コントリビューション・ライセンス

コントリビューション歓迎、大きな変更はIssueで事前相談推奨
ライセンス：GPL-3.0 （c）2024-2025 J-x-Z

Hackerたちの意見

すごく興味深いね。これってOrbstack内でWaydroidを使ってAndroidみたいなのを動かせるのかな？そうなったら、実質的にmacOS上でAndroidが動くことになるし、できる気がするんだけど。

無知を許してほしいけど、ネイティブのMacOSビルドがないグラフィカルなLinuxアプリって、みんな何を試してるの？俺の経験では、LinuxのGUIは一般的にQtかGTKで書かれてるから、どっちもマルチプラットフォームだし。存在するのは疑わないけど、人気のある例を思いつくのが難しいな。

└

Mac OSのダサい（俺の意見だけど）インターフェースの代わりにKDE Plasmaを使いたいんだ。

└

人気のアプリ？あんまり多くはないかも。でも、集積回路設計の分野ではLinux専用のアプリがたくさんあるよ。いくつかをMacのコンテナで動かそうとしたけど、XQuartzは最悪だった。もしWaylandに移行したら、これらのアプリをMacでうまく動かせるかもしれない。一方で、いくつかはARMビルドが始まってるから（特定のクラウド環境でシミュレーションを動かすために）、いつかネイティブのMac GUIビルドも実現するかもしれないね。

└

これは必ずしもLinuxだけのものじゃなくて、コンテナ化したいものなんだ。（そしてそれは本質的にLinux上で動いてる。）

└

このソフトウェアには多くのユースケースがあると思う。例えば、セキュリティや隔離、テストの目的で、Mac上で直接グラフィカルアプリを動かしたくない場合があるよね。このソフトがRDPやCRDよりもレイテンシが低いなら、リモートのグラフィカルワークステーションにアクセスするのにすごく便利だと思う（例えば、データセンターのパワフルなマシンで重いソフトを動かす代わりに、スリムなノートパソコンのリソースを使わずに済む）。

└

これは私にとって非常に興味深いです。理由は二つあります。1. Siriのタイルウィンドウ管理のために開発環境を整えたいと思っているんですが、良くも悪くも他のすべてのことに関してはAppleのエコシステムにどっぷり浸かっているので、これが本当に良い方法になりそうです（マルチモニターサポートが入ったらさらに良いかも）。2. Linuxビルドをサポートしているアプリがいくつかあるのに、macOSのサポートがないものもあります（例えば、IridiumのNiagara Workbenchアプリはビル管理システムの設定に使われます）。AppleがQuartzのサポートを終了してから、これがちょっと面倒になっています。

└

単にLinuxアプリを動かすだけでなく、これを使ってLinuxサーバー上でグラフィカルアプリケーションをリモートで実行することもできます。X11フォワーディングみたいな感じですね。

└

macOSでInkscapeやGIMPをソースからビルドしてみてください。GTKアプリが実際にどれだけ「マルチプラットフォーム」か感じられると思いますか？Macビルドが存在しても、奇妙にスキンされていたり、誰かが古いフォークに対してMacパッチを持っていなければならないので、遅れることが多いです。これは長期的な話です。コンポジターパスはボランティアによるポートの混乱を回避し、Linuxビルドを直接実行するので、あまりメンテナンスされていないニッチなGUIツールや開発アプリにはずっと魅力的です。macOSは言うまでもなく。

└

EmacsはLinuxのVMでずっと速くて快適に動くよ。クライアントごとにVMを持ってるし。

└

それは使い方じゃないよ。使い方は、リモートのLinuxホストからアプリをローカルウィンドウとして実行すること。特定のウィンドウのための高性能なVNCって感じかな。例えば、そのマシンでVS Codeを立ち上げて、Macのウィンドウとして表示することができる。もっと現実的な例だと、研究室のクラスターでGUI（例えば、Matlab）にアクセスする人たちがいるよね。x11の最も近いセットアップは、xpraを使ったx11フォワーディングになると思う。

└

macOSでのネイティブGTKアプリは、VMやParallelsで動かすよりも壊れてることが多い気がする。以前、macOSでGitgを使ってたけど、全然良い体験じゃなかった。

Hacker Newsで議論の続きを見る

ハクソク