O CrossFly é um framework open source (Apache 2.0) em que você escreve UI e lógica em Java puro e ele renderiza na GPU via LibGDX/OpenGL, compilando para binários nativos de Desktop (Windows, macOS e Linux), Android e iOS — mais uma build WebGL que roda em qualquer navegador moderno — Chrome, Firefox, Safari e outros. Combine com o CrossFly Sync para dados offline-first.
O MAUI é a evolução open source (MIT) do Xamarin, da Microsoft, em que você escreve C#/XAML e ele mapeia para controles nativos via handlers, mirando Android, iOS, macOS (Mac Catalyst) e Windows (WinUI 3). É LTS com o .NET 10.
As diferenças que realmente importam
Onde o modelo de controles nativos ajuda — e onde desenhar a própria UI vence.
O mesmo XAML renderiza diferente por plataforma
Porque o MAUI mapeia para controles nativos, o mesmo layout pode parecer e se comportar diferente entre iOS e Android — padding, bordas, peculiaridades de WebView, controles que quebram num SO e não no outro. Não é um bug passageiro: a própria comunidade do MAUI está construindo um backend de renderização própria baseado em Avalonia justamente para entregar uma aparência consistente entre plataformas.
Essa meta de renderer próprio é a arquitetura fundadora do CrossFly. O CrossFly desenha a própria UI na GPU, então há exatamente uma implementação para acertar e ela se comporta igual em toda tela — sem surpresas por plataforma.
UI moderna muitas vezes significa um fornecedor pago de controles
O conjunto de controles nativo do MAUI é enxuto; para data grids, gráficos, agendas e editores ricos, os times rotineiramente licenciam Syncfusion, Telerik ou DevExpress — a própria Microsoft fez parceria com a Syncfusion para preencher controles. Isso é um custo de licença e uma matriz de versões em cima do seu app.
O CrossFly renderiza o próprio conjunto de widgets de forma uniforme, então componentes avançados não ficam presos atrás de um contrato de fornecedor terceiro nem de uma dependência extra para manter em sincronia.
Uma casa Java precisa mudar de plataforma
O MAUI é C#/XAML no .NET. Não há forma direta de chamar o seu código Java ou Kotlin; a interop no Android passa por JNI e projetos de binding gerados. Suas bibliotecas JVM, JARs internos e habilidades de backend não migram sem trabalho de binding.
O CrossFly é Java. Sua linguagem, bibliotecas, ferramental de build, pool de contratação e stack de backend migram direto — nada para re-plataformar, nenhum binding para manter.
Desktop é forte no Windows, ausente no Linux
O desktop Windows do MAUI (WinUI 3) é excelente, mas o macOS é só Mac Catalyst (uma camada de app de iPad, um subconjunto do AppKit) e o desktop Linux não é suportado de forma alguma. Builds de iOS/macOS também prendem você a um Mac e ao Visual Studio — e o VS 2026 removeu o atalho Hot Restart sem Mac.
O CrossFly cobre desktop amplamente — Windows, macOS e Linux — a partir do mesmo código Java de Android, iOS e web (Chrome, Firefox, Safari e outros navegadores), o que importa para empresas cujos desenvolvedores e servidores rodam Linux.
Onde o CrossFly se destaca
Onde o .NET MAUI é genuinamente forte
CrossFly vs .NET MAUI em resumo
| Dimensão | CrossFly | .NET MAUI |
|---|---|---|
| Linguagem | Java | C# / XAML |
| Renderização | GPU via LibGDX/OpenGL (uma implementação) | Controles nativos via handlers (por SO) |
| Consistência entre plataformas | Idêntica por design | Varia por plataforma |
| UI avançada | Embutida no framework | Muitas vezes fornecedor pago (Syncfusion/Telerik/DevExpress) |
| Reuso de Java/backend | Direto (é Java) | Via bindings JNI |
| Plataformas | Desktop (Win/mac/Linux), Android, iOS, web (qualquer navegador) | Android, iOS, macOS (Catalyst), Windows |
| Desktop Linux | Sim | Não |
| Roda no navegador | Sim — Chrome, Firefox, Safari… | Não — a web exige um projeto Blazor à parte |
| Offline-first | CrossFly Sync (bidirecional) | Bibliotecas de terceiros |
| Toolchain | Build JVM padrão | Visual Studio + Mac para iOS/macOS |
| Licença | Open source (Apache 2.0, Core) | Open source (MIT) |