Cocoa-Way – un compositor Wayland para ejecutar apps de Linux de forma nativa en macOS

 (github.com/J-x-Z)
2 puntos por GN⁺ 2026-03-30 | 1 comentarios | Compartir por WhatsApp
  • Compositor Wayland que permite ejecutar aplicaciones de Linux en macOS sin máquina virtual, usando renderizado basado en Metal/OpenGL para integrarse de forma natural con el entorno de ventanas de macOS
  • Comunicación directa del protocolo Wayland mediante sockets Unix para minimizar la pérdida de rendimiento, con soporte para optimización de pantallas HiDPI y decoraciones del lado del servidor
  • Escrito en Rust, ofrece baja latencia y alta eficiencia mediante renderizado con aceleración por hardware
  • Con SSH y waypipe-darwin, es posible mostrar apps de un host Linux como ventanas en macOS
  • Publicado bajo licencia GPLv3, con una hoja de ruta en marcha que incluye extensiones de backend para Windows y Android

Descripción general

  • Cocoa-Way es un compositor Wayland que permite ejecutar aplicaciones de Linux en macOS como si fueran nativas
  • Se integra de forma natural con el escritorio de macOS mediante renderizado Metal/OpenGL y soporta conexión directa del protocolo Wayland a través de sockets, sin máquina virtual
  • Incluye optimización para pantallas HiDPI, decoraciones del lado del servidor y renderizado con aceleración por hardware
  • Está escrito en Rust y se distribuye bajo licencia GPLv3

Funciones principales

  • Integración nativa con macOS: renderizado basado en Metal/OpenGL para mantener compatibilidad total con la gestión de ventanas y efectos visuales de macOS
  • Zero VM Overhead: minimiza la pérdida de rendimiento con comunicación directa del protocolo Wayland mediante sockets Unix, sin virtualización
  • Soporte HiDPI: ofrece escalado y precisión de píxeles adaptados a pantallas Retina
  • Mayor nivel de acabado de la UI: incluye decoraciones del lado del servidor como sombras e indicadores de enfoque
  • Aceleración por hardware: implementa baja latencia y alto rendimiento con un pipeline eficiente de renderizado OpenGL

Cómo instalar

  • Instalación con Homebrew (recomendado)

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

  • Descarga de binarios

    • Se pueden descargar archivos .dmg o .zip desde la página de Releases en GitHub

  • Compilar desde el código fuente

Inicio rápido

  • Componente requerido: es necesario instalar waypipe-darwin
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • Ejecutar el compositor 
    cocoa-way
  • Conectar una app de Linux 
    ./run_waypipe.sh ssh user@linux-host firefox
  • Muestra apps Wayland del host Linux como ventanas en macOS a través de SSH

Arquitectura

  • En el lado de macOS existen el compositor Cocoa-Way y el cliente waypipe
  • En el lado de la VM o contenedor Linux existen el servidor waypipe y la app de Linux
  • App de Linux → protocolo Wayland → servidor waypipe → SSH/socket → cliente waypipe → Cocoa-Way → Metal/OpenGL → pantalla de macOS
  • Toda la ruta está conectada directamente sin virtualización, lo que ofrece baja latencia y alta eficiencia

Comparación

Solución Latencia HiDPI Integración nativa Complejidad de configuración
Cocoa-Way ⚡ baja ✅ soporte completo ✅ ventana nativa 🟢 fácil
XQuartz 🐢 alta ⚠️ soporte parcial ⚠️ peculiaridades de X11 🟡 media
VNC 🐢 alta ❌ sin soporte ❌ solo pantalla completa 🟡 media
VM GUI 🐢 alta ⚠️ soporte parcial ❌ ventana separada 🔴 compleja

Hoja de ruta

  • ✅ Backend macOS (Metal/OpenGL)
  • ✅ Integración con Waypipe
  • ✅ Escalado HiDPI
  • 🚧 Backend para Windows (win-way)
  • 📱 Backend Android NDK (planeado)
  • ⏳ Soporte multimonitor
  • ⏳ Sincronización del portapapeles

Antecedentes de investigación

  • Como parte del proyecto de investigación “Turbo-Charged Protocol Virtualization”, explora la virtualización Wayland multiplataforma de costo cero aprovechando la monomorfización de traits en Rust y la conversión de píxeles basada en SIMD

Resolución de problemas

  • Si aparece el error de SSH “remote port forwarding failed”, la causa puede ser un archivo de socket residual en el host remoto
    • El script run_waypipe.sh lo maneja automáticamente con la opción -o StreamLocalBindUnlink=yes
    • Si se ejecuta manualmente: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

Contribuciones

  • Se recomienda abrir un issue y discutirlo antes de añadir o modificar funciones
  • Se agradecen contribuciones mediante Pull Request

Licencia

  • GPL-3.0
  • Copyright © 2024–2025 J-x-Z

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-30
Opiniones de Hacker News

  • La verdad tengo una duda. ¿Qué apps GUI de Linux no tienen un build nativo para macOS? La mayoría están basadas en Qt o GTK, así que son multiplataforma, y no se me ocurre ninguna app popular en este momento

    • Ese no es el punto. Esto sirve para ejecutar apps de un host Linux remoto como ventanas locales. Por ejemplo, abrir VS Code en la Mac como una ventana de un servidor remoto, o acceder a la GUI de Matlab de un clúster de laboratorio. En X11 se puede hacer algo parecido con xpra
    • No hay muchas apps populares, pero en el campo del diseño de circuitos integrados hay muchas apps solo para Linux. Probé ejecutarlas en contenedores en Mac, pero XQuartz fue malísimo. Si se migra a Wayland, podría ser mucho mejor. Algunas incluso ya están teniendo builds para ARM, así que quizá algún día también haya GUI nativa para Mac
    • Personalmente me parece interesante por dos razones. Primero, quiero usar un entorno de desarrollo para Siri con gestión de ventanas en mosaico, pero estoy atado al ecosistema de Apple, así que esto parece una alternativa decente. Segundo, hay apps como Niagara Workbench de Iridium que solo funcionan en Linux, y desde que terminó el soporte de Quartz eso se volvió incómodo
    • Yo simplemente quiero usar KDE Plasma. La interfaz de macOS, honestamente, me parece mala
    • No solo sirve para ejecutar apps de Linux, también puede usarse para ejecutar localmente apps gráficas de un servidor Linux remoto

  • Perfecto. Ahora ya se podrán correr apps GUI dentro de contenedores. Antes probé algo parecido con X11, pero no me gustó. Cada vez siento más que la posición de Apple en el escritorio se está debilitando. Al final parece que vamos hacia una era en la que todo el mundo será “desarrollador”

    • Se dice que Apple se está debilitando en el mercado de escritorio, pero en realidad siempre ha tenido más cuota que Linux. No creo que vaya a cambiar mucho
    • Yo quiero abrir entornos de contenedor aislados por proyecto. Algo como el modo de integración de ventanas de Parallels, pero con el objetivo de agrupar apps por seguridad y para mantener el enfoque

  • Este proyecto se ve un poco sospechoso. El README está lleno de emojis y no explica nada de la implementación. Dice que hay un backend Metal, pero parece que en realidad no existe. La lista de dependencias también se ve rara

    • No vale nada la pena. Ni siquiera dice qué hipervisor usa. No se sabe si es QEMU o Docker. La tabla también está rara: una VM normalmente es lo más fácil de configurar, pero aquí lo pone al revés. Además, el código usa OpenGL 3.3 Core, que ya está demasiado viejo. Es muy probable que sea código generado por un LLM. Últimamente siento que el código de IA está sobrevalorado: se ve bonito por fuera, pero no tiene sustancia. Me recuerda a un proyecto promocional de Anthropic de un compilador de C hecho en Rust

  • También hace falta algo así para Android. termux-x11 es un punto de partida, pero si termux soportara Wayland o si la VM Linux de Android pudiera exponer un socket de Wayland, lo único que faltaría sería un compositor nativo para renderizado fluido

  • Si macOS pudiera arrancar en un modo shell de Darwin sin GUI, sería un UNIX increíble con un entorno de escritorio como KDE o COSMIC y el gestor de paquetes brew encima

    • En ese caso, uno se preguntaría para qué usar macOS. Si le quitas la interfaz, Darwin no se diferencia mucho de FreeBSD o GNU
    • El kernel de Mac rinde peor y su gestión de paquetes también es inferior a nix
    • En la época de las Mac Intel existía el modo de usuario único, pero ni siquiera entonces se podía controlar el framebuffer

  • Si esto es posible, me pregunto si un cliente Wayland para macOS también podría crear superficies EGL

  • ¿Será posible ejecutar un entorno Android usando Waydroid dentro de Orbstack? En teoría parecería posible

  • Si se pudiera cambiar macOS a atajos de teclado de Windows/Linux, sería mucho menos frustrante

    • Esa es una forma equivocada de verlo. Los atajos de macOS están optimizados para trabajo de terminal. Los atajos del sistema usan otras teclas para no chocar con los códigos de control
    • En la configuración puedes intercambiar las teclas cmd y ctrl, o personalizar todo por completo con Karabiner-Elements. A mí también me confundió al principio, pero en una semana te acostumbras. Ahora hasta me resultan incómodos los atajos de Windows. La historia de la tecla Command también es interesante
    • Tener que usar ctrl+shift en la terminal es realmente horrible. Creo que el esquema de atajos de macOS es mucho mejor
    • Personalmente creo que es mejor usar la tecla Super para la mayoría de los atajos. En Windows está desperdiciada porque prácticamente solo sirve para el menú Inicio
    • De hecho, uso Karabiner-Elements para mapear cmd, option y control como ctrl, alt y super, respectivamente. Con la configuración nativa de macOS ya se puede hacer bastante, pero si quieres cambiar distinto las teclas izquierda y derecha, necesitas Karabiner. Sorprendentemente, es una configuración bastante flexible para ser un producto de Apple

  • Me pregunto si este proyecto podrá despertar aunque sea un poco de interés en GNUstep