I don’t doubt that they exist, I’m just struggling to think of a popular example.
1. I'd really like to run my development environment for things under Siri for its tiling window management but for better or worse I'm deeply embedded in the Apple ecosystem for everything else, this looks like it could be a really nice way of doing it (possibly once multi monitor support is in).
2. There are still a few applications which have supported Linux builds but no support for macOS (Iridium's Niagara Workbench application for configuration of building management systems springs to mind here). Since Apple ended support for Quartz this has been a bit of a pain to deal with.
It would then essentially run android on macos as well, I do feel like it should be possible.
I did a similar thing with X11, but I didn't like so much.
Bit by bit, Apple is loosing it's Desktop position. It all starts at the developers. At soon, every person will be a "developer".
For example, you may not want to run some graphical applications directly on your Mac for security, isolation or testing purposes.
If this software turns out to be lower latency than RDP and CRD, I could also see it being very useful for accessing a remote graphical workstation (e.g.: running heavy software on an beefy machine in a data center instead of taking up resources on my skinny laptop).
This is for the long tail. The compositor path dodges a pile of volunteer-port churn and runs the Linux build directly, which is a lot more appealing for niche GUI tools and dev apps that barely get maintained on Linux, never mind macOS.
Anything I want sandboxed or “grouped”.
Work on a project -> open the relevant container.
Similar to parallels window integration mode.
It’s all from shortcomings to have a hierarchical view on your data and applications.
Goal: isolation. Security-wise, and focus-wise
Here some history on how the command key came to be https://www.folklore.org/Swedish_Campground.html https://en.wikipedia.org/wiki/Command_key
But in the field of integrated circuit design there’s lots of apps that are Linux-only. I’ve tried to run some of them in containers on Mac. But XQuartz is awful.
If they ever transitioned to Wayland perhaps this would let us run these apps on Mac in a nice way.
On the other hand some of them have started getting ARM builds (for running simulations on certain cloud environments) so maybe native Mac GUI builds could happen someday soon.
TBH, I would love to install GNU or BSD on my M4 Max Mac Studio. What I really wanted is a modern UNIX workstation. My Studio’s price/performance was the best available, so that’s what I bought. Now, I am happy with that purchase except for the constant diminution in software quality from Apple.
In fact one of the front page articles today is literally calling macOS “ugly” in the title.
but it feels a bit of peer-pressure/cool-factor, people used to like how Mac OS look but after Tahoe, I feel like most people don't.
To be honest, I am on mac right now but I really like Niri/Hyprland and to a degree KDE as well. I definitely feel like those were immensely more customizable and I miss that customizability, even if some people might use that customizability to make it look like MacOS default.
The dependency list is also...something: https://github.com/J-x-Z/cocoa-way/tree/main/vendor
And also this chart is super weird:
Solution Latency HiDPI Native Integration Setup Complexity
Cocoa-Way Low Yes Native windows Easy
XQuartz High Partial X11 quirks Medium
VNC High No Full screen Medium
VM GUI High Partial Separate window Complex
A standard VM will always be the easiest to set up by far. And latency should be the same across all 4. I mean after all it's a VM running on your local machine. Honestly I don't even know what it means when it says "Latency".I also looked at some of the code and it's using OpenGL 3.3 Core which is... super old. But it makes sense in the context of this being LLM-generated since most of its training data is probably OpenGL 3.3 Core code....
Overall this project is very strange. It makes me feel more confident in my skills, AI isn't all that great. It's all hype. You can get to the frontpage of HN. And if you're Peter Steinberger you can get acquired by OpenAI for a billion dollars. But that's about it. The code isn't getting any better.
This reminds me of that C-compiler-in-Rust publicity stunt by Anthropic. There's no substance. It's just a headline.
Native macOS Wayland compositor for running Linux apps seamlessly
True protocol portability: Cocoa-Way rendering Linux apps from OrbStack via Unix sockets.
| Feature | Description |
|---|---|
| 🍎 Native macOS | Metal/OpenGL rendering, seamless desktop integration |
| 🚀 Zero VM Overhead | Direct Wayland protocol via socket, no virtualization |
| 📺 HiDPI Ready | Optimized for Retina displays with proper scaling |
| 🎨 Polished UI | Server-side decorations with shadows and focus indicators |
| ⚡ Hardware Accelerated | Efficient OpenGL rendering pipeline |
brew tap J-x-Z/tap
brew install cocoa-way waypipe-darwin
Download the latest .dmg or .zip from Releases.
# Install dependencies
brew install libxkbcommon pixman pkg-config
# Clone and build
git clone https://github.com/J-x-Z/cocoa-way.git
cd cocoa-way
cargo build --release
⚠️ Required: You must install waypipe-darwin to connect Linux apps.
brew tap J-x-Z/tap && brew install waypipe-darwin
Start the compositor:
cocoa-way
Connect Linux apps via SSH:
./run_waypipe.sh ssh user@linux-host firefox
graph LR
subgraph macOS
CW[Cocoa-Way<br/>Compositor]
WP1[waypipe<br/>client]
end
subgraph Linux VM/Container
WP2[waypipe<br/>server]
APP[Linux App<br/>Firefox, etc]
end
APP -->|Wayland Protocol| WP2
WP2 <-->|SSH/Socket| WP1
WP1 -->|Wayland Protocol| CW
CW -->|Metal/OpenGL| Display[macOS Display]
| Solution | Latency | HiDPI | Native Integration | Setup Complexity |
|---|---|---|---|---|
| Cocoa-Way | ⚡ Low | ✅ | ✅ Native windows | 🟢 Easy |
| XQuartz | 🐢 High | ⚠️ Partial | ⚠️ X11 quirks | 🟡 Medium |
| VNC | 🐢 High | ❌ | ❌ Full screen | 🟡 Medium |
| VM GUI | 🐢 High | ⚠️ Partial | ❌ Separate window | 🔴 Complex |
This project is part of the "Turbo-Charged Protocol Virtualization" research initiative exploring zero-cost cross-platform Wayland via Rust trait monomorphization + SIMD-accelerated pixel conversion.
A stale socket file exists on the remote host. Our run_waypipe.sh script handles this automatically with -o StreamLocalBindUnlink=yes.
If running manually:
waypipe ssh -o StreamLocalBindUnlink=yes user@host ...
Contributions welcome! Please open an issue first to discuss major changes.
GPL-3.0 - Copyright (c) 2024-2025 J-x-Z