CrossFly 是一个开源框架（Apache 2.0），你用纯 Java 编写 UI 和逻辑，它通过 LibGDX/OpenGL 在 GPU 上渲染，并编译为桌面端（Windows、macOS 和 Linux）、Android 和 iOS 的原生二进制文件，以及可在 Chrome、Firefox、Safari 等任何现代浏览器中运行的 WebGL 构建。搭配 CrossFly Sync 即可实现离线优先的数据。
MAUI 是 Microsoft 对 Xamarin 的开源（MIT）演进，你编写 C#/XAML，它通过处理器映射到原生控件，面向 Android、iOS、macOS（Mac Catalyst）和 Windows（WinUI 3）。它随 .NET 10 进入 LTS。
真正重要的差异
原生控件模型帮上忙的地方——以及自己绘制 UI 胜出的地方。
同一份 XAML 在各平台渲染不同
由于 MAUI 映射到原生控件，同一套布局在 iOS 和 Android 上可能外观和行为都不同——内边距、边框、WebView 的怪癖，以及在一个操作系统上崩、在另一个上不崩的控件。这不是一时的 bug：MAUI 自己的社区正在构建一个基于 Avalonia 的自定义渲染后端，明确就是为了在各平台交付一致的外观。
那个自定义渲染器的目标，正是 CrossFly 的立身架构。CrossFly 在 GPU 上绘制自己的 UI，因此恰好只有一份实现要做对，而且它在每一块屏幕上表现一致——没有按平台出现的意外。
现代 UI 往往意味着一个付费控件厂商
MAUI 内置的控件集很精简；对于数据网格、图表、日程和富文本编辑器，团队经常要授权 Syncfusion、Telerik 或 DevExpress——Microsoft 自己就与 Syncfusion 合作来补齐控件。这在你的应用之上叠加了一笔授权成本和一张版本矩阵。
CrossFly 统一渲染自己的控件集，因此高级组件不必受制于第三方厂商合同，也不必再维护一个要保持同步的额外依赖。
一家 Java 团队不得不迁移平台
MAUI 是 .NET 上的 C#/XAML。没有直接的办法调用你的 Java 或 Kotlin 代码；Android 互操作要经由 JNI 和生成的绑定项目。你现有的 JVM 库、内部 JAR 和后端技能，没有绑定工作就无法带过来。
CrossFly 就是 Java。你的语言、库、构建工具链、招聘储备和后端技术栈都直接带过来——没有平台要迁移，没有绑定要维护。
桌面在 Windows 上强，Linux 上缺席
MAUI 的 Windows 桌面（WinUI 3）很出色，但 macOS 只有 Mac Catalyst（一个 iPad 应用层，AppKit 的一个子集），Linux 桌面则根本不支持。iOS/macOS 构建还把你拴在一台 Mac 和 Visual Studio 上——而 VS 2026 移除了免 Mac 的 Hot Restart 捷径。
CrossFly 广泛覆盖桌面——Windows、macOS 和 Linux——来自与 Android、iOS 和网页（Chrome、Firefox、Safari 等浏览器）相同的 Java 代码库，这对于开发者和服务器都跑 Linux 的企业很重要。
CrossFly 领先之处
.NET MAUI 真正强大之处
CrossFly 对比 .NET MAUI 一览
| 维度 | CrossFly | .NET MAUI |
|---|---|---|
| 语言 | Java | C# / XAML |
| 渲染 | 通过 LibGDX/OpenGL 在 GPU 上（一套实现） | 通过处理器使用原生控件（每个操作系统一套） |
| 跨平台一致性 | 设计上就完全一致 | 因平台而异 |
| 高级 UI | 内置于框架 | 常需付费厂商（Syncfusion/Telerik/DevExpress） |
| Java／后端复用 | 直接（它就是 Java） | 通过 JNI 绑定 |
| 平台 | 桌面（Win/mac/Linux）、Android、iOS、网页（任意浏览器） | Android、iOS、macOS（Catalyst）、Windows |
| Linux 桌面 | 支持 | 不支持 |
| 在浏览器中运行 | 支持——Chrome、Firefox、Safari 等 | 不支持——网页需另建 Blazor 项目 |
| 离线优先 | CrossFly Sync（双向） | 第三方库 |
| 工具链 | 标准 JVM 构建 | Visual Studio + Mac（用于 iOS/macOS） |
| 许可 | 开源（Apache 2.0，Core） | 开源（MIT） |