I work for Codename One and while some of the problems mentioned apply to us and our product still needs refinement we don’t suffer from almost any of those problems.
- We are Java based so we are 100% native on Android. Performance on Android is identical to native. On iOS we translate bytecode to C so we are comparative in speed to Objective-C/Swift both of which aren’t very fast. On Windows we use ikvm which probably isn’t as fast as handcoding C# but I doubt this will be noticeable. To target web we use teavm which is super fast and has a recent ASM port, this might make our JS code faster than hand coded JS…
- We let you write native code and embed it in a portable way. A lot of our users used this to publish open source extensions that access native code while maintaining portability. I admit it isn’t as convenient as using a ready made library but it works well and inherently removes the problem of “limits” you might experience. There are no inherent limits in the solution.
- About slow coding/running cycles our simulator is WAYYYYY faster than Android’s native SDK and our build time is faster than Android & iOS native build times with hello world in their native SDK’s. You can use CI which you configure once and TDD to automate the whole thing and get a remarkably productive concurrent development process.
- I don’t know if other platforms don’t support multiple “flavors” I know we have customers that do that and I even wrote a blog post about this as it’s super easy in Codename One. I’d be shocked if it isn’t just as easy with our competitors as it’s pretty trivial to do
But lets get back to some of the other arguments:
- “Apple and Google have huge teams building their platforms” — this is very flawed reasoning… Native Android development shifted completely over the past 10 years from very low level coding to Play Services and quite a few nuances. The fact is that you are not Google’s customer. The operators are and they are building a huge and complex set of tools for operators (hence crappy emulator instead of fast simulator).
The complexity and legacy weight in the Android API is insane, they have to be compatible to some degree with Android 1.x since operator code still relies on that. Even if they drop support in play services and don’t have any apps/devices they still need to maintain binary compatibility due to dynamic linking (almost all WORA tools including ours are statically linked) so moving the HUGE product is slower despite the much larger team.
Apple just views you as a product it can sell to the end user who is the “actual” customer. Developers get treated as such and the ground is shifted constantly…
- “Native development is documented better” — I would argue documented “more” not better. Having used a lot of these online communities I can say the misinformation and outdated facts are far more widespread and the “correct way” is often really hard to find/verify in the MUCH larger API.
But to be fair I agree there are a lot of problems in cross platform tools including ours but here is where the advantages are huge:
- Maintenance — Writing an app takes next to nothing. Maintaining it and releasing updates is where 90% of developer time is spent. Apps should be updated at least once a month to maintain popularity and doing that across stores is a pain. Bugs and issues are often very portable and you end up fixing them 2–3 times despite writing in completely separate languages. WORA solves this.
- Branding — iOS & Android converged a lot in terms of look and feel when compared to the old iOS 6/Android 2.x days. The ability to have more common branding code is huge. You can still have a native look and feel.
- Abstraction —Having an abstraction is just good engineering practice and has always been. We didn’t use Win32 we used MFC. We didn’t use J2EE we used Spring etc.
This is no different. Working with low level often closed source API’s (e.g. Play Services) is a risk. Having an abstraction means the framework provider is responsible for support and takes ownership over low level platform inconsistencies. When something fails in Codename One you can get support for us both free and paid. If something fails in Android native coding you need to find a contractor who might know nothing. The advantage of using a common abstraction is that it is very likely that a failure or issue will be located by a different member of the community so the core abstraction is more stable. This goes deep, there are nuances with Androids low level OS fragmentation especially with the cheap Chinese phones but such issues exist all over the place. Even if you have a large team you would be challenged in finding some of the issues we already worked around.
In closing I totally accept there are real problems with some WORA solutions as they are today including our own. I disagree that they are inherent and argue that they already provide a superior experience to you as a developer and to your end users when used correctly/effectively.