Ejecutar software de macOS en Linux sin Mac: el proyecto de código abierto Kakehashi supera las 200 utilidades

La regla no escrita de que el software de Apple solo puede ejecutarse en ordenadores Apple acaba de mostrar su primera grieta real. A principios de agosto de 2026, un proyecto de código abierto llamado Kakehashi («puente» en japonés) llegó a la portada de Hacker News, acumulando 156 puntos y 34 comentarios. Su premisa se resume en una sola frase: ejecutar software nativo de macOS directamente en un equipo ARM con Linux, sin instalar el sistema operativo de Apple ni recurrir a máquinas virtuales. Hasta la fecha, ha logrado hacer funcionar más de 200 herramientas de línea de comandos de macOS, e incluso el compresor 7-Zip opera con normalidad. Por primera vez, un esfuerzo técnico serio empieza a fisurar el bloqueo de software exclusivo de Apple.

Imagen: Hilo de lanzamiento de Kakehashi en Hacker News, donde el autor respondió a preguntas sobre el desarrollo. Fuente: news.ycombinator.com

Por qué esto parecía imposible

Para la mayoría de los usuarios, el software y el hardware de Apple son indisolubles: las aplicaciones diseñadas para Mac simplemente no se ejecutan en otras plataformas. Esto no es casualidad, sino el resultado de la estrategia deliberada del ecosistema cerrado de Apple.

El modelo de negocio de Apple vincula estrechamente la venta de hardware con la exclusividad del software. La licencia de uso (EULA) de macOS establece de forma explícita que el sistema operativo solo puede ejecutarse en hardware oficial de Apple. Intentar instalarlo en otro equipo supone una infracción de los términos. Sumado a las comisiones de la App Store y los servicios en la nube, cada Mac comprado funciona como la entrada a este jardín vallado. Durante décadas, utilizar software de macOS en hardware ajeno a Apple requería elegir entre dos alternativas complejas: configurar una pesada y lenta máquina virtual con el sistema completo, o recurrir a las inestables configuraciones Hackintosh.

Kakehashi propone una tercera vía: no trasladar el sistema operativo, sino adaptar la aplicación.

Cómo funciona: un traductor a nivel de sistema

Trasladar programas de macOS a Linux presenta una dificultad fundamental: ambos entornos utilizan interfaces de sistema totalmente distintas (ABI y llamadas al sistema). Anteriormente, la única forma de conectar ambos mundos era importar todo el entorno de usuario de macOS.

La clave del proyecto radica en un hallazgo estructural: los chips de la serie M de Apple y los procesadores de los equipos ARM con Linux comparten la misma arquitectura de instrucciones (ARM). Dado que la CPU ejecuta el mismo juego de instrucciones de forma nativa, el binario de la aplicación se ejecuta directamente en el procesador Linux sin necesidad de emular la CPU. El único punto que requiere traducción se produce cuando la aplicación solicita servicios al sistema operativo (leer archivos, acceder a la red o asignar memoria). Kakehashi actúa como un traductor en esa frontera: cuando una aplicación de macOS solicita abrir un archivo, Kakehashi intercepta la petición, la convierte en la llamada correspondiente de Linux y devuelve el resultado al programa.

Imagen: Los chips serie M de Apple y los dispositivos Linux ARM comparten la arquitectura ARM, reduciendo drásticamente el coste de ejecución binaria. Fuente: Wikimedia Commons

Este concepto se conoce formalmente como «capa de compatibilidad» (compatibility layer). Su predecesor más célebre es Wine, que permite ejecutar aplicaciones de Windows en Linux.

Un reto iniciado hace 30 años

En 1993 nació el proyecto de código abierto Wine con una meta igualmente ambiciosa: ejecutar software de Windows de forma nativa en Linux. La comunidad se mostró escéptica en sus inicios, ya que replicar las miles de API de Windows parecía una tarea inalcanzable. Sin embargo, tras tres décadas de desarrollo continuo, Wine pasó de ser un experimento limitado a una herramienta indispensable.

En la actualidad, Wine sustenta plataformas de gran escala: la consola portátil Steam Deck de Valve utiliza una versión derivada (Proton) para que cientos de miles de jugadores ejecuten títulos de Windows en un dispositivo portátil Linux. Lo que comenzó como un proyecto considerado imposible se convirtió en la base de un producto de hardware comercial.

Kakehashi no es el primer intento de tender un puente al software de macOS. El proyecto Darling buscó un objetivo similar, aunque su avance fue más lento. El creador de Kakehashi aclaró en Hacker News que no se trata de una bifurcación (fork) de Darling, sino de una implementación independiente escrita desde cero en Rust que opera por completo en espacio de usuario con requisitos de privilegios mínimos. Asimismo, el autor mencionó el uso de herramientas de IA durante el desarrollo, lo que generó debate en los comentarios, respondiendo que todo el código es abierto y accesible para auditoría pública.

¿Es determinante ser 5.2 veces más lento?

Las pruebas de rendimiento publicadas destacan la ejecución del compresor 7-Zip: en una prueba con 8.000 archivos y 240 MB de datos, 7-Zip completó la tarea de forma correcta, aunque su velocidad fue 5.2 veces más lenta que la versión nativa de Linux (118 segundos frente a 22.5 segundos). Por otra parte, más de 200 variaciones del comando curl superaron los tests automatizados, y las funciones básicas de la herramienta Git incluida en Xcode funcionaron correctamente.

Una penalización de 5.2 veces puede parecer elevada, pero representa un comportamiento previsible en las etapas iniciales de una capa de compatibilidad. El cuello de botella principal proviene del intercambio de contexto al interceptar las llamadas al sistema. Cuando una tarea involucra miles de archivos pequeños, la frecuencia de traducción aumenta la latencia. En operaciones con archivos grandes y pocas llamadas al sistema, la diferencia se reduce notablemente a un rango de 1.1 a 1.2 veces. Wine experimentó penalizaciones mayores en sus primeras versiones. El desarrollador ya ha trazado una hoja de ruta para optimizar el rendimiento, fijando como siguientes objetivos el soporte de la cadena de herramientas completa de Xcode y la gestora de paquetes Homebrew para macOS.

En las discusiones se señaló también un desafío constante: Apple modifica interfaces internas en casi cada actualización mayor de macOS, lo que obliga a las capas de compatibilidad a realizar un trabajo continuo de adaptación frente a un sistema cerrado.

El impacto de esta brecha en el ecosistema

A nivel general, este desarrollo refleja el contraste entre los ecosistemas abiertos y cerrados. Mientras la filosofía del código abierto defiende que el software debe ejecutarse libremente en cualquier hardware compatible, la estrategia de Apple sostiene que la experiencia de usuario se optimiza dentro de su propio entorno controlado. Kakehashi demuestra que las barreras de software pueden ser superadas mediante las abstracciones adecuadas.

Si en el futuro las herramientas creativas exclusivas de macOS (edición de vídeo, diseño o producción musical) logran ejecutarse en hardware ARM accesible, la ventaja competitiva basada únicamente en el hardware sufrirá variaciones. La trayectoria de Wine demuestra que la disponibilidad de aplicaciones en múltiples plataformas no destruyó el software original, sino que amplió la adopción de dichas aplicaciones.

El alcance final de Kakehashi dependerá de su evolución frente a la diferencia de rendimiento, las actualizaciones del sistema y los aspectos de licencias. No obstante, la historia del software demuestra que las transformaciones de gran alcance suelen comenzar con pequeñas brechas técnicas.

Enlaces de referencia:

• Repositorio de GitHub de Kakehashi (wie-project): Página del proyecto, README, documentación de arquitectura y hoja de ruta
• Hilo de discusión en HN (item?id=49145937): Detalles del autor sobre 7-Zip, curl, Xcode Git y la relación con Darling
• Documentación histórica oficial de Wine: Descripción del proyecto en WineHQ («Wine Is Not an Emulator»)
• Entrada de Wikipedia sobre Wine: Historia de desarrollo desde 1993 hasta la integración en Steam Deck