Why Codename One
Native apps from Java, without a browser or scripting bridge.
Codename One runs Java on Android's native runtime and translates Java bytecode to C for a native iOS build. You keep one UI and application codebase, use the Java ecosystem, and ship without royalties or a platform vendor setting the framework agenda.
Architecture at a glance
Compare what your application actually ships.
The language, runtime, UI layer, test cycle, and vendor incentives affect the product long after the first screen works.
| Decision | Codename One | Platform UI | Flutter | Web |
|---|---|---|---|---|
| Primary ecosystem | Java, Maven, JVM libraries, and mainstream Java IDEs | Swift/Xcode plus Kotlin or Java/Android Studio | Dart, pub packages, and Flutter tooling | HTML, CSS, JavaScript, and browser tooling |
| Android execution | Java bytecode runs on Android's ART runtime and calls Android APIs directly | Kotlin or Java runs on ART with direct Android APIs | AOT-compiled Dart code runs with the Flutter engine | JavaScript inside a browser or WebView |
| iOS execution | ParparVM translates Java bytecode to C, then Xcode compiles the native binary | Swift or Objective-C compiled by Xcode | AOT-compiled Dart code runs with the Flutter engine | JavaScript in WebKit, or a native wrapper around it |
| Shared UI | One UI implementation across mobile, desktop, web, watch, TV, and vehicle targets | Separate Swift and Kotlin UI implementations | Shared across Flutter-supported targets | Shared across browsers; native wrappers add platform work |
| Theming | CSS themes shared across targets, with platform-specific selectors when needed | Separate SwiftUI/UIKit and Compose/View styling | Theme and widget code written in Dart | CSS interpreted by the browser |
| Local development | One JavaSE simulator with device skins, component inspection, networking tools, tests, and MCP control | Platform simulator and emulator toolchains | Flutter tooling plus platform simulators for native behavior | Browser developer tools |
| CI testing | Shared logic, UI, and screenshot tests can run on the JVM or headless JavaScript before native builds | Separate iOS and Android test jobs | Dart tests plus native jobs for platform behavior | Headless browser tests; wrappers need native jobs |
| Runtime packaging | Android application bytecode runs on ART. On iOS, ParparVM translates Java bytecode to C before Xcode compiles the native binary. The Codename One UI toolkit is bundled with the app | Uses each OS runtime and UI toolkit | Release builds bundle AOT-compiled Dart code with the Flutter engine and its Dart runtime support | Runs inside a browser engine or WebView |
| Native OS components | Native interfaces plus PeerComponent for real maps, browsers, cameras, and other platform views | Direct access to every platform component | Platform channels and Platform Views | Browser APIs or wrapper plugins |
| License and direction | Independent, open source, GPLv2 with Classpath Exception, no royalties | Controlled separately by Apple and Google | Open source and directed by Google | Standards and engines controlled by browser vendors |
The Codename One advantage
One strict Java codebase, one simulator, one set of tests.
- Keep Java's library ecosystem, Maven builds, and mainstream profiling and debugging tools.
- Theme the shared UI with CSS instead of rebuilding styling in each platform language.
- Run most UI and logic work in the universal JavaSE simulator without waiting for a native build.
- Move fast CI work onto ordinary JVM or headless browser runners, then reserve native builders for native verification.
- Reuse Android's built-in ART runtime. The Codename One UI toolkit ships with the application; it does not add a browser or a second language runtime on Android.
- Embed real OS views when you need them, and call native SDKs synchronously when the platform permits it.
- Ship any number of commercial applications without royalties or per-app fees.
- Work with an independent framework company whose revenue depends on customers shipping across vendors.
Platform UI
Two vendor toolkits and two UI implementations.
- You get immediate access to each vendor's newest APIs.
- You also maintain separate Swift and Kotlin screens, tests, behavior, and release work.
- Apple or Google can restyle platform-owned controls after your application ships.
Flutter
A Dart codebase built around the Flutter engine.
- Release builds include AOT-compiled Dart code, the Flutter engine, and Flutter runtime support. On Android, Codename One application bytecode runs on ART.
- Moving from Java to Flutter means adopting Dart, pub packages, and a Google-directed framework instead of retaining JVM libraries, Maven, and Java tooling.
- Native integration crosses asynchronous platform channels or embeds Platform Views. Codename One uses native interfaces and
PeerComponent, including synchronous native calls where the platform permits them.
Web
A URL-first application inside the browser.
- The web is a strong deployment target when a URL and browser APIs match the product.
- App-store packaging adds a WebView wrapper and native integration layer.
- Codename One includes a JavaScript port when the same Java application also needs web reach.
Control the whole development loop
Codename One removes duplicated work before the store build.
Java is native on Android
Your application code runs as Java bytecode on Android's own ART runtime. Codename One adds a portable UI and API layer; it does not hide Android behind JavaScript.
Java tooling stays useful
Use Maven, IntelliJ IDEA, NetBeans, Eclipse, VS Code, JUnit, profilers, and the wider JVM library ecosystem. The mobile project remains a Java project.
CSS controls the UI
One CSS theme covers the shared component hierarchy. Platform selectors and constants let you diverge deliberately without creating another screen implementation.
Test before native CI
The JavaSE simulator runs the same shared UI and business logic locally. JVM and headless JavaScript jobs catch routine failures before scarce macOS or device infrastructure is involved.
Native integration is explicit
Native interfaces expose platform SDKs. PeerComponent embeds heavyweight OS views such as maps and browsers inside the shared UI.
No royalties or vendor agenda
The framework is open source and independent. Commercial applications have no royalty or per-app fee, and the business succeeds when customers keep shipping across Apple, Google, desktop, and web targets.
Verify it in your codebase
Build the screen that makes other frameworks expensive.
Use a screen with real layout, CSS, business logic, and one native view. Run it in the simulator, add a JVM test, then submit iOS and Android builds from the same project.
- 1Generate the Java project.
- 2Build and theme one representative screen.
- 3Add the native view your product needs.
- 4Run local tests, then build for both stores.
Keep the codebase
Create a Java project and test the architecture yourself.
The framework is open source and royalty free. The free cloud tier includes 100 free cloud build credits each month.