O desenvolvimento cross-platform mobile tem um dilema antigo: ou você aprende a linguagem de cada plataforma, ou adota um framework intermediário que abstrai ambas e aceita os trade-offs. O Skip propõe algo diferente. Em vez de criar uma camada nova por cima de tudo, ele pega o que o desenvolvedor iOS já conhece (Swift e SwiftUI) e transpila para Kotlin e Jetpack Compose. O resultado é um app genuinamente nativo em ambas as plataformas, sem runtime extra, sem interpretador, sem garbage collector no iOS.
Em 21 de janeiro de 2026, a versão 1.7 abriu o código completo do motor de transpilação — o skipstone — e eliminou toda exigência de licença paga. Para quem trabalha com Swift no dia a dia e sempre quis publicar em Android sem reescrever tudo, essa mudança tira a principal barreira de adoção.
O que é o Skip
Skip é um transpilador de Swift para Kotlin. Ele lê código Swift usando o SwiftSyntax (a biblioteca de parsing open source da Apple), monta uma árvore sintática detalhada e traduz essa árvore para Kotlin equivalente. Para a camada de UI, o SwiftUI é mapeado para Jetpack Compose, o toolkit declarativo do Android.
O projeto existe desde 2023. Nos primeiros dois anos operou como produto pago: empresas acima de um certo faturamento precisavam de licença para usar. Desenvolvedores indie e apps gratuitos tinham acesso livre. Esse modelo gerava uma preocupação legítima na comunidade: "e se a empresa fecha? e se é adquirida e desligada?" A resposta veio com a abertura total do código.
Hoje o Skip está no GitHub sob a organização skiptools, com mais de 1.400 commits e 711 releases acumulados. A documentação vive em skip.dev.
Como funciona a transpilação
O pipeline tem quatro etapas:
- O SwiftSyntax faz o parse do código Swift em uma árvore sintática granular
- O transpilador analisa essa árvore e gera uma árvore equivalente em Kotlin
- O Kotlin gerado é empacotado junto com o projeto Android
- Um único codebase Swift produz dois apps nativos, um em SwiftUI e outro em Jetpack Compose
O nível de fidelidade é alto. O transpilador preserva comentários e formatação do código original. O Kotlin resultante, segundo a documentação do Skip, "é frequentemente indistinguível de código escrito à mão."
Na prática, o mapeamento de UI é onde mora a complexidade. O ViewBuilder do SwiftUI (baseado em ResultBuilders) não tem equivalente direto em Kotlin. O Skip converte declarações ViewBuilder em chamadas de funções Compose aninhadas. O resultado é funcional, mas mecanicamente gerado. As diferenças arquiteturais entre SwiftUI e Compose ficam evidentes no código Kotlin.
Para APIs de plataforma, o Skip mantém bibliotecas open source que espelham frameworks da Apple (Foundation, Observation, SwiftUI) no Android via Swift Package Manager. Isso permite que pacotes Swift cross-platform existentes funcionem sem modificação.
O que o Skip 1.7 trouxe
A versão 1.7, lançada em 21 de janeiro de 2026, fez três coisas:
- Abriu o código do skipstone, o motor que cuida de criação de projeto, plugins de Xcode e SwiftPM, transpilação de código, bundling de recursos e localização, criação de bridge JNI, empacotamento de app e exportação de projeto
- Removeu toda exigência de licença, sem trial, sem chave, sem assinatura
- Mudou o modelo de financiamento para GitHub Sponsors e patrocínio corporativo
A decisão de abrir o skipstone é o ponto mais significativo. Antes, mesmo que as bibliotecas de suporte fossem open source, o motor de transpilação era fechado. Um desenvolvedor não conseguia auditar o que acontecia entre o Swift de entrada e o Kotlin de saída. Agora pode.
Skip na prática
Um componente SwiftUI no Skip se parece exatamente com SwiftUI convencional:
import SwiftUI
struct CounterView: View {
@State private var count = 0
var body: some View {
VStack(spacing: 16) {
Text("Contagem: \(count)")
.font(.title)
Button("Incrementar") {
count += 1
}
}
.padding()
}
}Esse código compila nativamente no iOS via Xcode. No Android, o Skip transpila para Kotlin com Jetpack Compose. O resultado é um componente nativo em cada plataforma, não uma webview, não um canvas customizado.
Os testes também são compartilhados. O SkipUnit mapeia APIs do XCTest para JUnit, o que permite rodar a mesma suite de testes em ambas as plataformas via GitHub Actions.
O fluxo de desenvolvimento usa o Xcode como IDE principal. Plugins SwiftPM invocam a transpilação automaticamente a cada build. Módulos que não mudaram são pulados, o que mantém o tempo de compilação razoável.
Onde o Skip se encaixa no ecossistema cross-platform
O cenário mobile cross-platform em 2026 tem quatro opções relevantes, cada uma com uma proposta diferente.
Flutter comanda cerca de 46% do mercado entre desenvolvedores mobile. Renderiza UI com seu próprio motor gráfico (Impeller, sucessor do Skia), e o resultado é consistência pixel-perfect entre plataformas. A linguagem é Dart.
React Native usa componentes nativos e melhorou com a New Architecture e o Hermes V1. Ideal para times com experiência forte em JavaScript e TypeScript.
Kotlin Multiplatform (KMP) compartilha lógica de negócios entre plataformas, mas deixa a UI nativa para cada uma. Mais que dobrou em adoção entre 2024 e 2025, saindo de 7% para 18% no JetBrains Developer Ecosystem Survey. Netflix, Google Workspace e Cash App usam em produção.
Skip ocupa um nicho que ninguém mais ocupa: desenvolvedores que já sabem Swift e SwiftUI e querem alcançar Android sem aprender outra linguagem ou framework. Não compete com Flutter ou React Native na amplitude. Compete na profundidade de integração com o ecossistema Apple.
A diferença prática: no Flutter, você aprende Dart e os widgets do Flutter. No React Native, você trabalha com JavaScript e a bridge nativa. No KMP, você escreve Kotlin e pode manter UI nativa. No Skip, você escreve SwiftUI do jeito que já escreve, e o transpilador cuida do resto.
Limitações e quando evitar
O Skip é transparente sobre onde não funciona bem.
Projetos existentes com muitas dependências iOS-only são problemáticos. A migração "não é trivial", segundo a própria documentação. A maioria dos apps iOS maduros usa bibliotecas que não têm equivalente Android, e o Skip não inventa um.
O framework funciona melhor em projetos novos ou apps com poucas dependências externas. Quem já tem um codebase iOS grande com CocoaPods, UIKit legado e SDKs proprietários vai ter trabalho.
O Skip depende do Xcode como IDE. Desenvolvedores Android que não usam Mac simplesmente não conseguem entrar nesse fluxo. Isso limita a adoção a times que já operam no ecossistema Apple.
Tem também a questão de maturidade do ecossistema. O Flutter tem milhares de packages no pub.dev. O React Native tem o npm inteiro como backstop. O Skip interopera com "milhares de pacotes Swift cross-platform", segundo a documentação. Mas a realidade é que muitos pacotes Swift populares usam APIs iOS-only que não transpilam.
Conclusão
O Skip não vai substituir Flutter nem React Native. Não é esse o objetivo. Ele resolve um problema específico para um público específico: desenvolvedores iOS que sabem Swift e SwiftUI, trabalham em apps pequenos a médios e querem publicar em Android sem manter dois codebases.
A abertura do skipstone com a versão 1.7 remove a incerteza sobre a sustentabilidade do projeto. Qualquer desenvolvedor pode inspecionar, contribuir e até forkar o motor de transpilação se necessário. O modelo de financiamento via GitHub Sponsors não é garantia de receita eterna, mas é mais transparente que uma licença fechada.
Para quem se encaixa nesse perfil, time iOS-first com app novo ou com poucas dependências, vale gastar uma tarde configurando um projeto de teste. O código está em github.com/skiptools e a documentação em skip.dev.