180M App Installs

40K Developers

1M Cloud Builds

BuildWrite code in Java(tm) using Eclipse, NetBeans or IntelliJ/IDEA

DeployGenerate native binaries for all device types using the Codename One build cloud

What's so special about Codename One?

We are the only ones that provide...

Write Once Run Anywhere, no special hardware and 100% code reuse

Most other solutions don't offer write once run anywhere and usually require a Mac for iOS development or a Windows machine for Windows development! Codename One solves these problems by providing a unique cloud build system. We have Mac servers in the cloud running xcode where your binary JAR is statically translated to native C code and compiled with xcode using our open source VM. It's signed using an official Apple certificate and the binary is delivered back to you for installation on your phone or upload to the store. You retain full ownership of your application and your source code remains secure on your local machine, only the compiled bytecode reaches the build server. Pretty much every other solution needs some native code or at least native API usage to bind the lifecycle of the application.

Codename One is ridiculously portable. It is based on work started by our founders at Sun Microsystems back in 2006 and leverages decades of cross platform mobile development experience. In this video Shai Almog explains the basics of Codename One and its portability. You can also read some of the low level explanations in this stackoverflow answer. The gist of it is that Codename One translates code to native OS's. Since it's based on Java Codename One is native to Android. For iOS the bytecode is translated to C using our open source VM. For Windows UWP (Universal Windows Platform) we use iKVM which is a bytecode to .net translator. For JavaScript we use TeaVM which translates bytecode to JavaScript and even supports threads!

Easy to use with 100% portable Drag & Drop GUI builder

Easy to use cross platform tools are usually "weak" in terms of capabilities. Tools that are as powerful as Codename One is usually don't offer a portable GUI builder due to the difficulty of cross platform component layout and positioning. Our second generation GUI builder uses a unique approach for layout that is powerful, portable and intuitive.

You can control every pixel and draw anywhere

In Codename One you can override the paint method or styling of any component and just change the way they draw themselves and it will work! You can override the glass pane or layered pane behavior and draw over any region in the screen without a hassle or native issues. This is possible since Codename One is a lightweight framework, a unique architecture among mobile frameworks. But it takes that even further with heavyweight mixing. Check out this stackoverflow answer to understand the architecture/history of Codename One. You can also check out this video.

Full access to native OS using the native language (e.g. Obj-C, C# etc.)

You can and usually should write code that is 100% portable with Codename One. But you might reach a point where you need something from the native OS. For that we have native interfaces. Native Interfaces let you write native OS code if you need to, they let you package it in a library so your code can be completely abstracted. There are no limits on the type of code you can write with Codename One. Some other tools require usage of their language when working in native, so if you find a sample on Apples website you need to translate it to your language of choice first. With native interfaces you can just paste the code into the native interface and it will work when running on iOS or the respective platform.

Use native widgets and mix them with our components in the hierarchy (heavyweight/lightweight mixing)

One of the popular features of Codename One is native Google Maps support. It works by literally embedding the native Google maps widget into a Codename One application. You can place Codename One components on top of this map and interact with both... This is very powerful and as far as we know a unique ability of Codename One within the lightweight frameworks.

Open Source and Free for commercial use with enterprise grade commercial offering

Most tools have an open source project. Codename One originated as an open source project fork of a project started by our founders at Sun Microsystems. However, many open source projects of this type don't have a commercial backing or long term sustainable business model. A few exist simply to serve corporate goals of companies with a completely different business model... In those cases official paid support is impossible. The pairing of open source and a sustainable commercial offering is surprisingly rare in the cross platform niche. Furthermore, many of the open source options use things like nag screens or licenses that prohibit commercial use. With Codename One this isn't the case.

There are a lot of fixes and new features that I don't get to cover enough as I've been busy on several fronts. One of the new features is support for asynchronous media API's. These let us create a media object without waiting for it to complete. This is very useful if you have a complex UI and want to play a media file while doing other things.

The Tabs class is pretty powerful and flexible as I mentioned before. One thing it doesn't support is drag and drop to re-order the tabs. Here the flexibility of Codename One takes over and allows us to accomplish it.

Text editing is implemented natively in Codename One. This provides a huge benefit as it allows us to ignore a lot of complex topics such as virtual keyboard localization etc. If we had to implement all that logic the overhead of Codename One would have been huge...

The native low level camera API on Android is a disaster. It's often cited as one of the worst API's on Android. To make matters worse there are two separate API's Camera and Camera2 (yes really). You need to use Camera2 where it's available but that means no support for older devices. To solve this we picked the Android Camera Kit library when we started building our low level camera support. This proved to be a mistake.