When “Write Once Run Anywhere” is done right it can produce applications that are “better” than native apps by targeting the highest common denominator.
Some would claim that native is the best approach, but that looks at existing WORA tools/communities, which mostly target cost saving. In fact, even native Android/iOS tools produce rather bad results without deep platform familiarity. Native is very difficult to properly maintain in the real world and this is easily noticeable by inspecting the difficulties we have with the ports of Codename One, this problem is getting worse rather better as platforms evolve and fragment. E.g. Some devices crash when you take more than one photo in a row, some devices have complex issues with http headers, and many have issues when editing text fields in the “wrong position”.
There are workarounds for everything, but you need to do extensive testing to become aware of the problem in the first place. WORA solutions bring all the workarounds and the “ugly” code into their porting layer, allowing developers to focus on their business logic. This is similar to Spring/Java EE approaches that addressed complexities of application server fragmentation.
If you review most user feedback on mobile applications you will quickly notice that a company that releases applications often and fixes issues gets consistent 5 star reviews. The ability to provide a stable app across platforms is a much tougher nut to crack than most developers assume, bugs are remarkably portable even between programming languages. Being able to scale your development team to give fast response times to user requirements is a huge deal. Being able to use Google Play as a beta site for the more conservative (and slower to approve) iTunes is a remarkable benefit for any developer.
Codename One is relatively young, so we don’t have a blockbuster, multi-million downloads app that contains a large enough representative segment (we do have some huge customers and great apps so its a matter of time). However WAZE (recently acquired by Google for over 1b USD) was constructed with a WORA solution, has multi-million downloads and 4.5+ star reviews on iOS/Android. I’m not crazy about their UI (as a matter of personal taste) but I think it proves that a HUGE majority of users want a functional, stable, and fast app. The word native and its various interpretations are only a part of the developer lexicon and don’t matter as much to actual users.
Using the native platform has a huge conflict of interest problem, e.g. Google is very keen on developers building Android applications. However, it has slowly migrated new API’s into the Market app, which only enables them for Google sanctioned devices. This makes sense since vendors have been very slow at migrating to newer Android OS versions. However, this also means that non-Google devices such as the Kindle (and future Amazon phone etc.) wouldn’t work with those API’s. Thus, we have a situation where the platform vendor wants us to develop to his platform alone while, as developers, we want to have as many users as possible. Yes, iOS users provide better monetization but that might change in the future and as developers we have an interest in agility.
As a side-note, Google itself uses a relatively simple WORA solution when targeting iOS named J2ObjC its a great solution for porting libraries from Java to Objective-C.
In the past, the conflict of interest between the platform developer and the tool developer pushed many developers from Microsoft tools to Borland tools and later on to Java/Swing. I believe we will see similar trends as mobile platforms migrate towards the enterprise and we are already seeing such development with PhoneGap despite all its faults.
The Native Is Easy Myth
Often when I bring these things up, I get the strong knee-jerk reaction from the fans of native claiming that native is the best approach. This completely ignores the long-term complexities of building/maintaining complex applications across platforms. For example, a well known Google developer asked in a recent Google IO who in the audience understood the activity lifecycle, he then made fun of the audience members who raised their hands claiming that despite all his years in Google he still doesn’t get the activity lifecycle (I built a few VM’s in my life and I can attest that this is indeed a complex subject with many edge cases).
iOS is not much better, the compiler/runtime doesn’t protect you from basic mistakes such as wrong function arguments (function, not message), memory access issues etc. You need to maintain around seven splash screens for a typical universal app, which you need to update with every change to the first view and don’t get me started on provisioning profiles…
The main issue isn’t writing the code, it’s maintaining it in the long term, scaling it for additional team members, and working in a corporate environment. As the mobile market matures from app startups, who have relatively small teams of hackers, and moves to the enterprise the need to scale the development becomes far greater. Enterprise developers need the ease of Swing, Visual Basic or Powerbuilder when it comes to mobile development.
They also usually prefer vendor independence when possible. Just like Java EE, SOA or ESB took over backend development we will see mobile services take over the client side. Developers who didn’t work in demanding Enterprise environments or worked in a very specific niche in an enterprise sometimes claim, “well they should hire better developers”. But that isn’t really the issue, projects such as these are maintained over years when developers hand them off from one person to the next as manpower/positions change. In such circumstances tools must be very simple to enable efficiency.
Speed & Flexibility
Performance is a big issue with WORA solutions, unfortunately we are sometimes judged by the performance of a specific application which might not always be under our control. The Pareto principle applies here: by improving a very small section of the code we can improve everything. Most of our rendering code is native and if you have mission critical code you can always write it natively to reach the performance level you would expect from any solution. Unlike HTML5, which is effectively throttled by how fast webkit can reflow, in a proper WORA solution you are throttled only by the performance of the native OS.
Since we can invoke native code we can pretty much do anything we want within an application e.g. integrate with the Dropbox API via OAuth while using a native intent to invoke Dropbox on Android. This is actually implemented by some applications to enable easy usage of files within a mobile app, which is a painful experience on all mobile platforms.
Final Thoughts
My goal here isn’t so much to convince native developers to abandon native programming, but rather to change the basic “WORA as a compromise” attitude where native is considered as the best approach.
I think this approach rose from sub par WORA solutions and implementations, such as the much maligned Facebook app. Despite the fact that I think embedding HTML5 (as is done in PhoneGap) isn’t a very good approach, I think that in the right hands it can produce a decent app. As a developer I try not to blame my tools but rather look at how the tool works and try to understand if its limitations are inherent or temporary. I think most of the issues we see in WORA tools are being resolved and we will see far more WORA apps on the market in the coming years.
