Rodar um binário de macOS no Linux sempre pareceu coisa de ficção científica

Quem já tentou compilar um projeto iOS num runner Linux sabe a dor. Você abre o GitHub Actions, configura tudo bonitinho, e na hora de escolher o runner percebe: macOS custa US$ 0,062 por minuto. Linux ARM? US$ 0,005. Doze vezes mais barato. Só que não adianta, porque o Xcode, o clang da Apple e uma dúzia de ferramentas Darwin simplesmente não existem fora do ecossistema da maçã.

Até agora.

Um projeto chamado Kakehashi apareceu no Hacker News essa semana e fez muita gente levantar a sobrancelha. A proposta é direta: rodar binários nativos de macOS ARM64 no Linux aarch64, sem emulação de instrução, sem máquina virtual, sem gambiarras. Pensa num Wine, só que ao contrário: em vez de rodar .exe do Windows, ele roda Mach-O do macOS.

O que exatamente o Kakehashi faz

O Kakehashi é uma camada de tradução em userspace. Isso significa que ele não mexe no kernel do Linux, não precisa de módulos especiais e roda inteiramente no espaço do usuário. O fluxo funciona assim:

1. Ele carrega o executável Mach-O (o formato binário do macOS)
2. Mapeia uma libSystem freestanding (a biblioteca de sistema que todo programa macOS precisa)
3. Intercepta as chamadas de sistema BSD e traduz para equivalentes Linux
4. Executa o código nativo direto na CPU, já que ambos os lados são ARM64

Não existe emulação de instrução. O código do guest roda na velocidade do processador. O que o Kakehashi faz é ser o “tradutor simultâneo” entre o que o binário macOS pede e o que o kernel Linux oferece.

O conceito de “bottle”

Uma das sacadas mais interessantes é o sistema de bottle, que cria um filesystem isolado com estrutura macOS dentro do Linux. Pensa num chroot com cara de Mac: o binário “enxerga” /Volumes/linux/ que na verdade aponta para o filesystem real do host. Isso resolve um problema chato de compatibilidade de paths sem precisar recompilar nada.

Quem está por trás e como foi construído

O projeto é escrito em Rust e segue uma arquitetura modular:

Na discussão do Hacker News, alguém inevitavelmente perguntou: “isso não é o Darling?”. O criador do Kakehashi foi direto: o projeto não é derivado do Darling. A arquitetura é fundamentalmente diferente. Darling usa C/Objective-C e opera mais próximo do kernel. Kakehashi é Rust puro e fica 100% em userspace.

Outro ponto que gerou debate: o uso de LLMs no desenvolvimento. O criador descreveu a abordagem como “light-gray room”, não exatamente clean room no sentido jurídico estrito, mas sem cópia direta de código de projetos existentes. As IAs ajudaram, mas a arquitetura é original.

O que já funciona (e o que não funciona)

Vamos ser honestos: o projeto é experimental. Mas “experimental” aqui não significa “só compila e crasheia”. Já existem binários macOS reais rodando:

Funcionando:

• 7-Zip (7zz): compressão multi-threaded funciona. O benchmark com 8.000 arquivos (240 MiB) completa sem erros
• curl: requests HTTP e HTTPS passando
• Clang probes: testes de compilador da Apple executando
• Operações multi-threaded: sim, threads funcionam

No roadmap:

• curl completo (POST bodies, proxies, HTTP/3)
• Apple Security framework
• Git da Apple (Command Line Tools)
• Apps gráficos e codesign/notarization

Ou seja, estamos falando de ferramentas CLI. GUI ainda está longe. Mas pra quem quer rodar swift build ou xcodebuild num runner Linux, o caminho está sendo pavimentado.

A matemática que justifica o projeto

Aqui é onde o Kakehashi fica realmente interessante. Vamos aos números.

O benchmark de compressão do 7-Zip mostra que o binário macOS rodando via Kakehashi é 5,2 vezes mais lento que o mesmo programa compilado nativamente para Linux. Parece ruim, certo? Mas olha a conta:

Mesmo que a task demore 5x mais no Linux (por causa do overhead do Kakehashi), você ainda gasta menos do que pagaria por um runner macOS nativo. Um build de 15 minutos no macOS viraria 78 minutos no Linux via Kakehashi, custando US$ 0,39. Ainda 58% mais barato que o runner macOS.

E esse é o cenário pessimista, com o overhead atual. O projeto prioriza corretude primeiro, performance depois. Tem margem de otimização sobrando.

Para equipes que fazem centenas de builds iOS por mês, essa diferença é dinheiro real. Estamos falando de milhares de dólares por mês em economia potencial.

Darling, Wine e o ecossistema de tradução

Pra entender onde o Kakehashi se encaixa, vale olhar o mapa das camadas de compatibilidade que existem:

Wine é o avô de todos. Traduz chamadas de API do Windows para Linux desde 1993. Depois de mais de 30 anos, consegue rodar jogos AAA, aplicações corporativas e até o Microsoft Office com performance quase nativa em muitos casos. O Proton (do Steam Deck) é uma versão turbinada do Wine.

Darling tenta ser o “Wine do macOS” desde 2012. Usa C e Objective-C, opera mais próximo do kernel e tem um preview release de fevereiro de 2026 (versão 0.1.20260222). O progresso existe, mas é lento. Roda alguns apps gráficos básicos, mas está longe da maturidade do Wine.

Kakehashi tem uma proposta diferente das duas. Não quer rodar Photoshop no Linux. O foco é CI/CD: compilar, testar e empacotar software macOS em runners Linux baratos. É um escopo muito mais restrito, o que paradoxalmente aumenta as chances de sucesso. Em vez de tentar reimplementar todo o macOS, precisa apenas das APIs que ferramentas de build usam.

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│     Wine     │    │   Darling    │    │  Kakehashi   │
│  Win → Linux │    │  Mac → Linux │    │  Mac → Linux │
│  x86/x86_64  │    │  x86_64/ARM  │    │   ARM only   │
│  GUI + CLI   │    │  GUI + CLI   │    │   CLI only   │
│  30+ anos    │    │  14 anos     │    │   novo       │
│  C/C++       │    │  C/ObjC      │    │   Rust       │
└──────────────┘    └──────────────┘    └──────────────┘

O caso de uso real: CI/CD para iOS sem Mac

Imagina o cenário: você tem um time de 20 devs iOS. Cada push dispara uma pipeline que compila o app, roda os testes unitários, gera o .ipa e sobe pra TestFlight. Cada build leva 20 minutos. São 50 pushes por dia.

Com runners macOS no GitHub Actions:

• 50 builds × 20 min × US$ 0,062/min = US$ 62 por dia
• US$ 1.860 por mês. Só de CI.

Com Kakehashi num runner Linux ARM (mesmo assumindo 5x overhead):

• 50 builds × 100 min × US$ 0,005/min = US$ 25 por dia
• US$ 750 por mês. Economia de 60%.

E isso sem contar o benefício de disponibilidade. Runners macOS no GitHub são limitados. Em horário de pico, você espera na fila. Runners Linux ARM estão sobrando.

Claro, hoje o Kakehashi não roda xcodebuild completo. Mas o roadmap inclui suporte ao Git da Apple e ferramentas de build. Se chegar lá, o impacto financeiro pra empresas com times iOS grandes vai ser brutal.

Como testar o Kakehashi hoje

Se você tem uma máquina Linux ARM64 (um Raspberry Pi 5, uma instância Graviton na AWS, um Mac com UTM rodando Linux), dá pra testar agora:

# Requisitos: Rust 1.88+, Linux aarch64
git clone https://github.com/wie-project/kakehashi.git
cd kakehashi

# Build
cargo build --release

# Instalar ferramentas macOS no bottle
./target/release/kh install 7zz

# Rodar o 7-Zip da Apple no Linux
./target/release/kh run 7zz a archive.7z /path/to/files

O projeto suporta page sizes de 4 KiB e 16 KiB, então funciona tanto em instâncias cloud quanto em boards ARM como o Raspberry Pi.

Para quem usa Docker no Mac (via Colima), também funciona. A documentação cobre esse cenário especificamente.

Os desafios técnicos que ninguém fala

Traduzir syscalls parece simples na teoria. Na prática, macOS e Linux divergem em dezenas de detalhes sutis:

Sinais e threads: macOS usa Mach ports para comunicação entre threads. Linux usa futexes. Traduzir um pro outro sem race conditions é um pesadelo de concorrência.

Filesystem semântica: macOS é case-insensitive por padrão (HFS+/APFS). Linux é case-sensitive (ext4). Um binário macOS que abre “README.md” e “readme.md” esperando o mesmo arquivo vai quebrar no Linux sem uma camada de abstração.

Dyld vs ld-linux: o dynamic linker do macOS (dyld) tem comportamento diferente do ld-linux.so. Ordem de carregamento de bibliotecas, resolução de símbolos, weak linking: tudo funciona de um jeito sutilmente diferente.

Security framework: qualquer coisa que toca Keychain, certificados SSL da Apple ou codesign precisa de uma reimplementação completa. O curl do Kakehashi funciona com HTTPS justamente porque ele usa uma implementação alternativa de TLS, não o SecureTransport da Apple.

Esses são problemas que o Wine levou décadas para resolver no ecossistema Windows. O Kakehashi está só começando a enfrentá-los no lado macOS.

A reação da comunidade

No Hacker News, a recepção foi majoritariamente positiva. Devs iOS manifestaram interesse imediato, especialmente pra CI/CD. Um comentário mencionou a possibilidade de rodar Audio Units (plugins de áudio) do macOS no Linux, similar ao que o Yabridge faz com VSTs do Windows.

A preocupação mais recorrente: sustentabilidade. Projetos de tradução de sistema operacional são notoriamente difíceis de manter. O Darling existe há 14 anos e ainda está em “preview”. O Wine só chegou onde está por causa de investimento comercial (Valve, CodeWeavers). Quem vai financiar o Kakehashi?

Por enquanto, é um projeto de uma pessoa (ou time pequeno). Se ganhar tração suficiente para atrair contribuidores ou um sponsor corporativo, tem potencial real. Se não, corre o risco de virar mais um repo abandonado no GitHub.

O elefante na sala: a Apple não vai gostar

Vamos falar do óbvio. A Apple controla todo o ecossistema de desenvolvimento iOS. O Xcode só roda no macOS. O simulador iOS só roda no macOS. A assinatura de código exige um Mac ou um serviço pago da Apple.

Isso não é acidente. É estratégia. Cada dev iOS é um comprador potencial de Mac. Cada Mac vendido alimenta o ecossistema.

Se o Kakehashi (ou qualquer projeto similar) conseguir rodar ferramentas de build da Apple no Linux, a Apple provavelmente vai reagir. Pode ser com mudanças no formato Mach-O, novas verificações de runtime, ou simplesmente ameaças legais. O histórico com Hackintosh mostra que a Apple não brinca quando alguém tenta separar o software do hardware.

Por outro lado, empresas como a Microsoft já oferecem compilação iOS via cloud (com Macs reais por trás). Se o Kakehashi viabilizar uma alternativa open source que não dependa de hardware Apple, a pressão legal vai depender de quanto dinheiro a Apple está perdendo.

O que esperar nos próximos meses

O roadmap do Kakehashi é agressivo mas realista:

1. Curto prazo: melhorar performance do runtime (reduzir o overhead de 5,2x), expandir cobertura de syscalls
2. Médio prazo: suportar Git da Apple e Command Line Tools, permitir swift build básico
3. Longo prazo: Xcode CLI tools, simulador iOS headless, codesign

Se o projeto entregar nos dois primeiros pontos, já vira uma ferramenta útil pra pipelines de CI/CD. O terceiro ponto é o “moonshot” que pode mudar a indústria.

Enquanto isso, vale acompanhar o repo no GitHub e, se você tem uma máquina ARM rodando Linux, testar. Projetos open source vivem de feedback, e o Kakehashi está numa fase onde cada bug report e cada contribuição fazem diferença.

Para quem vale a pena ficar de olho

Se você trabalha com desenvolvimento iOS ou macOS e gasta dinheiro com CI/CD, o Kakehashi é um projeto para acompanhar de perto. Mesmo que hoje ele não substitua seus runners macOS, a trajetória é promissora.

Se você é um desenvolvedor Rust interessado em sistemas de baixo nível, contribuir pro Kakehashi é uma oportunidade rara. Projetos de tradução de SO são fascinantes do ponto de vista técnico: você aprende sobre ABIs, formatos de executável, syscalls, threading, memory mapping. É o tipo de projeto que transforma um dev bom em um dev excepcional.

E se você é um gestor de engenharia cansado de pagar US$ 2 mil por mês em runners macOS: guarda esse link. Daqui a 12 meses, a conversa pode ser outra.

O Wine levou 10 anos pra ficar usável e 20 pra ficar bom. O Kakehashi está no dia 1. Mas o fato de já rodar 7-Zip, curl e clang de verdade, com threads, num Linux ARM, sem kernel patches: isso não é pouca coisa.

Fonte de inspiração: Kakehashi no GitHub e discussão no Hacker News