CrossFly is an open-source (Apache 2.0) framework where you write UI and logic in plain Java and it renders on the GPU via LibGDX/OpenGL, compiling to native binaries for Desktop (Windows, macOS and Linux), Android and iOS — plus a WebGL build that runs in any modern browser — Chrome, Firefox, Safari and others. Pair it with CrossFly Sync for offline-first data.
Kotlin Multiplatform (KMP) is JetBrains' open-source (Apache 2.0) technology for sharing code — logic, networking, data — across Android, iOS, desktop and web, while UI stays native per platform. Compose Multiplatform is its optional shared-UI toolkit (Skia-rendered), stable on iOS since May 2025.
The differences that actually matter
Two JVM cousins, two very different bets on language, UI and tooling.
It's Kotlin-first, not Java
KMP's shared code is Kotlin. Kotlin has great Java interop on the JVM, but Kotlin/Native (iOS) and Kotlin/Wasm are Kotlin toolchains — not “run your existing Java.” A pure-Java enterprise team has to commit to Kotlin as its shared language.
CrossFly keeps you in Java end to end. There's no team-wide language migration — your Java developers, libraries and idioms carry straight into the app on every platform.
The iOS interop layer is lossy
On iOS, Kotlin talks to Swift only through a generated Objective-C bridge. That translation is where the sharp edges live: nullable ints get boxed, sealed classes lose exhaustive switch, Kotlin Flow becomes clunky callbacks, generics collapse to Any?. JetBrains' idiomatic fix, Swift Export, isn't ready yet.
CrossFly has one rendering and logic path drawn on the GPU — there's no Kotlin→Obj-C→Swift boundary to cross, so none of those interop losses appear in the first place.
Shared UI on iOS is young
If you want to share the UI too, that's Compose Multiplatform — which reached stable on iOS only in May 2025, with text-field accessibility landing even later, and web/Wasm still in beta. It's Skia-rendered (not native widgets), so on iOS it looks like Material, not Cupertino.
CrossFly's draw-your-own-UI model is the whole framework, not a recently-stabilised layer — one consistent UI across desktop and mobile from day one. (If you need per-platform native look, KMP's native-UI option is a real strength — see the fair-play column.)
The build matrix is the tax
KMP means Gradle-multiplatform — which JetBrains itself calls “overwhelming” — plus brittle CocoaPods integration, an iOS plugin that only works on macOS, and slow Kotlin/Native compiles. Expect real setup and iteration friction, especially on the iOS side.
CrossFly's single-language, single-toolchain model keeps the build story far simpler — fewer moving parts between you and a running app on all three platforms.
Where CrossFly pulls ahead
Where Kotlin Multiplatform is genuinely strong
CrossFly vs Kotlin Multiplatform at a glance
| Dimension | CrossFly | Kotlin Multiplatform |
|---|---|---|
| Language | Java | Kotlin |
| Runtime | Native binaries (JVM heritage) | Native binaries (Kotlin/Native, JVM heritage) |
| What's shared | UI + logic, one codebase | Logic by default; UI native or via Compose MP |
| UI model | One GPU-drawn UI everywhere | Native per platform, or Compose MP (Skia) |
| iOS UI maturity | Core framework | Compose MP iOS stable since May 2025 |
| iOS interop | One path, no ObjC bridge | Kotlin↔Objective-C bridge (Swift via generated layer) |
| Build/tooling | Single JVM toolchain | Gradle-multiplatform + CocoaPods; iOS plugin macOS-only |
| Offline-first | CrossFly Sync (bidirectional) | Assemble from libraries |
| Desktop | First-class (Win/mac/Linux) | Mature via Compose for Desktop |
| License | Open source (Apache 2.0, Core) | Open source (Apache 2.0) |