To properly evaluate a platform we often look at our existing experiences and evaluate based on what we know. The set of options below present some of insights about how we match up to other cross platform solutions in the market today. But first lets start up with the Codename One benefits:
- Performance - HTML5 is slow to begin with but made slower on devices due to some architectural choices on iOS devices.
- Portability - while HTML5 on the server side can be ported with some effort, when embedded using PhoneGap like packaging adapting the UI for multiple DPI's becomes challenging. Web technologies were designed for HTTP delivery not for local execution. Codename One was built from scratch to work on all DPI's and provides the visual tools to do so.
- Power - mobile browsers are fragmented and constantly late with new features requiring a full OS upgrade for new features. Basics such as threads aren't at the moment of this writing supported by any device. Codename One provides most of the power and convenience desktop Java developers are used to.
- Stable target - since your code executes on the device browser you are very likely to have device only issues that can't be debugged properly. Codename One is statically linked to your application which means you will have a stable application with an identical version of Codename One on all devices! Since the code is handled by a single entity if you run into problems we can actually help you fix them!
- Native tools - in order to build an application for iOS you must have a Mac and for Windows phone (if supported) you need a windows machine. This is tedious and painful! Codename One uses a build server to remove that need and provides seamless simulator execution, debugging, profiling etc.
- Standard IDE - most such tools have their own IDE's with limited features. Codename One works with NetBeans/Eclipse, which are mature industry leading IDE's. Appcelerators Titanium IDE is particularly limited, highlighting its "code completion" abilities as a "new feature"...
- Portability - Appcelertor requires that you rewrite your UI (roughly 50% of the code) for every platform. Better solutions limit the developer to the lowest common denominator approach, this requires coding specifics for every platform. Codename One uses a unique lightweight architecture that enables it to offer high level features on all devices.
- Ease - most such tools don't offer features such as integrated GUI builders, themes, localization etc…
Other than that, the tool just deals with the iOS porting of business logic. Requires a Mac and requires that developers work with xcode. It doesn't include a full featured garbage collector (the OS X GC mentioned in their wiki was deprecated on OS X and ARC is not a GC) and isn't really a cross platform solution.
J2ObjC does not provide any sort of platform-independent UI toolkit, nor are there any plans to do so in the future. iOS UI code needs to be written in Objective-C or Objective-C++ using Apple's iOS SDK (Android UIs using Android's API, web app UIs using GWT, etc.).
- Optimized for phones/tablets, this includes support for gestures and complex key layouts
- Proper styles & themeing
- Resource file format/standard GUI builder
- Truly open source
- Static linking
It is remarkably hard to port a scene-graph implementation consistently to every platform and then integrate it with the native platform widgets as we are sure the guys at Oracle have found out. Making this sort of implementation performant is even harder as the guys from Adobe found out.
While Swing had a lot of traction (30% of the GUI development market at its peak) JavaFX never reached any measurable market penetration. Its only major users are Swing shops that have no future migration path other than JavaFX. Oracle itself fired most of its developer advocates and JavaFX related teams, it doesn't use JavaFX for any of its core products, e.g. MAF has no relation to JavaFX.
Up until recently there was no JavaFX on mobile devices and arguably there still isn't, a team at Oracle open sourced a half baked JavaFX for iOS implementation that suffers greatly from the limitations mentioned above. This was picked by some developers and shipped as a product for mobile application development. We consider such efforts to be callous & irresponsible to the developers who look at them as a serious solution, it breeds confusion within the community that's already fragmented:
- Java FX is HUGE and remarkably complex - can a bunch of hackers maintain/support something as big as this? Even Oracle with all its resources has a ridiculous amount of bugs within the desktop version of JavaFX.
- Oracle already vetted JavaFX's potential on mobile and came to the realization that its not a practical solution for the mobile ecosystem due to its complexity. E.g. JavaFX requires its own kerning on top of OpenGL ES, this is nearly impossible to do properly because of the complexities of subpixel anti-aliasing on mobile screens.
- To further cemenet the point Oracle has so little faith in the future of FX that it killed the Scene Builder project.
- JavaFX was designed for desktops where manipulation of native widgets is possible and documented. Native widgets are ESSENTIAL on mobile, you can't do input without a native widget. Video, HTML rendering etc. must all be done natively... That's REALLY hard to do in a portable way that won't crash the VM.
- JavaFX applications are HUGE because they need a HUGE VM. This translates to slow download, slow performance and slow builds.
Codename One is much smaller in terms of code size but has a much larger active developer community, because projects are translated to native OS projects they should be buildable and maintainable even without Codename One's support.
The tool is marketed as a free tool which is misleading since its free for development but not for distribution. The cost is per application and is in the range of 50,000USD!
MAF suffers from all the problems of PhoneGap/HTML (mentioned in the first section) and it adds to that all the complexity of working with a Java backend without removing those other complexities.
To make matters worse, since the VM is embedded into the code you are limited to an interpreted mode which means slow performance on top of the existing HTML5 overhead!
Xamarin is an ambitious tool allowing C# developers to write mobile phone applications, its a very impressive tool but it is not a WORA (Write Once Run Anywhere) tool. Xamarin requires that developers write platform specific code and as a result maintain platform specific code and platform specific skills, its proponents see that as an advantage (it is more native) but it has quite a few faults as a result.
Xamarin uses C# as its base programming language, this is a matter of developer taste. However, it has one major drawback to Java: it is only "native" to Windows Phone where is Java is the native language of Android. So on most of the devices in the field it would require a 3rd party VM to be installed. Xamarin proponents try to spin this as an advantage claiming that their VM is faster than the native Dalvik VM on Android. However Dalvik is optimized for size/security & multi-tasking so its unclear how accurate these claims are in reality. Furthermore, since that time Android introduced ART (Android Runtime) which is a faster & more efficient. Xamarin can't gain from such technological advantages.
Codename One differs from Xamarin in the following ways:
- Doesn't need a Mac for iOS development - recent versions of Xamarin allow you to use a Mac hosted on the network but this doesn't solve the issue for a mobile worker.
- WORA (Write Once Run Anywhere) - Xamarin has some portability libraries mostly for IO etc. but it isn't designed to be a WORA solution. Developers need to learn platform native API's and behaviors for every platform.
- Java - Xamarin is a C# solution. This is a matter of developer preferences although Java has the advantage of being the language of Android.
- GUI Builder - Since Xamarin isn't a WORA solution the GUI isn't portable, thus localization, branding and all resources need to be adapted to every platform.
- IDE - Xamarin has its own IDE or Visual Studio from Microsoft. Codename One works with all major Java IDE's NetBeans, Eclipse & IDEA.
- Open Source - Xamarin has a free version with very limiting stipulations and isn't open source. Codename One's free version is far more generous. Codename One is open source!
We see the following issues with RoboVM compared to Codename One:
- Requires a Mac
- Isn't a WORA solution (Partially so for Gaming. Also see the JavaFX section for more).
- Gaming focused - Approximately 95% of RoboVM's traction is due to the excellent libGDX gaming library.
- Closed source
- Fragile - RoboVM uses an unsupported path to native. LLVM is used internally by Apple but isn't documented as a way to port apps and Apple has made HUGE changes to the process several times over the past 2 years making RoboVM's maintenance expensive/risky. Codename One translated code to C/Objective-C which is an officially supported language from Apple, you can also download the resulting project and use it in Apples native tools unchanged.
- React native isn't a WORA solution - it uses native widgets and even has its own lightweight implementation of a controller since the concept of controllers is not universal
- React native has on device performance issues because basic UI concepts aren't interchangeable between native widgets. This isn't a problem for Codename One where all components are lightweight
- React Native requires a Mac for iOS development and a complex toolchain for every platform
- React abstracts everything behind callbacks reducing code size but making the behavior and flow more opaque
- React Native isn't as porable, you can't reuse the code for a web embedded app or a desktop app
- React native isn't more terse than Codename One with Java 8