With the wide selection of cross-platform development tool (CPTs) available in the market, how should a developer select a development tool? The exact selection criteria will vary depending on the project and the individual developers involved. However, it’s valuable to look at the criteria other developers have used to select development tool and, even more importantly, the reasons they’ve stopped using them. Fortunately, we have this data from our cross-platform tools survey earlier in the year.

Access to additional platforms is the #1 selection criterion

The most important CPT selection criterion is the breadth of platforms that the tool supports, cited by nearly 60% of respondents. Runtimes and source code translation tools have the broadest platform reach. Sencha and jQuery Mobile score top marks for platform reach – based on our developer survey – thanks to the ubiquity of JavaScript frameworks. RunRev’s Livecode which is deployable to web and desktop (though only iOS and Android on mobile) comes next. These were followed closely by Marmalade, MoSync and PhoneGap, which reflects their broad mobile platform coverage. It’s also worth noting Unity, which supports an impressive range of desktop and game console platforms. Meanwhile Netbiscuits, as with other solutions leveraging web apps and PhoneGap, is very well rounded in terms of its mobile platform support.

Developer selection criteria are heavily skewed towards the breadth of platforms supported by each tool. This was the picture at the onset of 2012, although it becomes less important as iOS and Android continue to dominate the market and most tools then cover all the major platforms.

Use existing skills

The ability to use existing skills is the second most frequently cited reason for tool selection. It goes without saying that developers see CPTs as a way to reach additional platforms without learning new programming skills, be that a new authoring language or a new development environment. This is an important selection criteria but can be dangerous if the tool is not matched to the needs of the project. It’s likely that many of the developers abandoning cross-platform tools had this aspect too high in their selection criteria. However, lack of skill re-use was also a common complaint amongst those abandoning CPTs suggesting that the learning curve is often underestimated too.

Today’s cross-platform tools address an impressive range of authoring languages. Seasoned developers can use low level programming languages like C, C++ (e.g., Aqua Platform, MoSync, Expanz or Edgelib), or higher level languages such as Java (e.g., XMLVM, In-The-Box) and C# (e.g., Xamarin’s MonoTouch, Axiom 3D, Unity and iFactr). Developers with scripting level skills can use LiveCode – or Lua as used in Corona and DragonRad. Web developers familiar with HTML and JavaScript can use a variety of tools, for example leveraging UI frameworks like iUI, or games frameworks like Lime and Impact. They can access device hardware APIs and wrap apps using solutions like PhoneGap Build or Sencha Touch. Designers and non-programmers also have a variety of cross-platform tools at their disposal, including App factories like Tiggzi, GameSalad or iBuildApp.

Low cost, rapid development process and an easy learning curve

These criteria come in at third, fourth and fifth place in top selection criteria for CPTs. The primary purpose of cross-platform tools is to reduce the incremental cost (effort and money) spent in catering to a new platform, so this finding should come as no surprise. At the same time, it is difficult for a developer to compare and contrast tools in terms of the development speed, the learning curve, or the total cost of ownership without first developing an application on it. Experimentation is therefore used as the main means to select a cross-platform tool – which also explains the volatility and continual tool “hop-on-hop-off” that we‘ve seen among cross-platform developers.

A rapid development and seamless debug process does pay dividends with developers. Qt’s satisfied developers again praised the framework, which scored top marks in the development and debugging experience in comparison to other tools vendors. RunRev’s LiveCode visual development environment and compile-free development process also seem to be paying off in developer satisfaction. On the low side of developer satisfaction ratings with development and debugging is Appcelerator. This, despite the acquisition of Aptana, a popular Eclipse based IDE including code assist and an integrated debugger.

Cost is of course a major differentiator among cross-platform tools. Tools that scored the highest developer satisfaction were often freely available under an open source license – notably jQuery Mobile, Qt, Sencha, PhoneGap and MoSync. These are all released as open source projects and set the bar high with free versions available on varying licensing terms – from permissive (PhoneGap under Apache license) to weak copyleft (Qt under LGPL) to strong copyleft (MoSync under GPL).

Rich UI capabilities and access to device APIs

These are the only other two selection criteria to be selected by over 10% of respondents, normalised across top tools. Real native UI capabilities are offered by a small set of CPTs currently, with many vendors like Appcelerator, MoSync and Marmalade pushing their offerings towards this direction. As platform UIs become more distinctive the ability to create a native UI becomes more important for many types of app, there is little tolerance amongst platform power users who are most prolific and vocal in their reviews for a “ported” user experience. Frameworks that attempt to mimic a native UI are exposed when the platform provider makes significant changes. As such this approach is not recommended, if an application is not using actual native UI components it should create a distinctive look of its own.

Developer selection criteria vary widely across development tool

Marmalade scored significantly higher than other tools for selection on performance criteria (36% of respondents), as did Qt (32%). Being well suited for games development was unsurprisingly a priority selection criterion for Unity (52%) and Corona (45%). In line with its simplified language and development environment, RunRev LiveCode stood out for selection on the basis of the rapid development process, with 69% of developers selecting this as criteria. Similarly, in line with the company’s positioning, Xamarin (MonoTouch/Droid) stood out with 80% of developers selecting that as a primary platform that allows them to use their existing (C# and .NET) skills. Value – being low cost or free – was a key selection criteria for MoSync (68%), Sencha Touch (60%), PhoneGap (59%) and Appcelerator (56%).

Why Developers Abandon Cross-Platform Tools

Steve Jobs once gave one of the most damning and damaging indictments to cross-platform tools in his infamous “Thoughts on Flash”. Written in April 2010, those words and the legacy of the Apple-Adobe dispute will continue to resonate in the minds of developers considering cross-platform tools.

“We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross-platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence, developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Flash is a cross-platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross-platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.”

In his open letter, Jobs criticised cross-platform tools for lack of performance and sluggishness in adopting the latest platform features. Indeed, the same issues highlighted in Jobs’ letter were cited by developers as some of the most important reasons for dropping a tool. Performance was the top reason for dropped a tool, cited by 29% of respondents. After performance, the most important reasons cited for dropping a tool were breadth of platforms supported, steep learning curve, restricted UI capabilities, and no support for existing development skills. These match almost identically with the reasons for tool selection, meaning that these factors catalyze both entry and exit to a cross-platform tool.

When should CPTs be avoided?

It’s instructive to look not just at the exit factors (the reasons for dropping a tool) but the also the entry barriers. There were two main reasons cited by developers for not yet using a cross-platform tool. First, the fact that developers already had access to native development skills, and therefore did not need a CPT in order to target a new platform. Second, that CPTs are always a step behind the native platform in terms of features and capabilities. Both factors point to how the biggest barrier to mass adoption of cross-platform development tool is feature parity with the native platforms. This of course will always be a speed race, as Apple, Google, Microsoft and the other native platform vendors will be motivated to continually evolve their APIs, both for competitive reasons and because cross-platform development is not in their interests – it’s not possible to have a differentiating app offering if all apps run everywhere.

Other developers who have yet to adopt cross-platform development tool cited the lack of maturity, limited access to device APIs and poor performance as reasons for stalling their adoption. Cost is surprisingly not amongst the top-5 of reasons stopping developers from using cross-platform development tool. The up-front costs are a limiting factor in adoption for 22% of developers, with maintenance costs being less visible and cited by 13% of non-adopter respondents.

However, it should be noted that this is purely the cost of the development tool. Development and maintenance cost saving should always be the primary driver for CPT adoption. If it’s practical and affordable to develop native clients for all platforms this will always produce the best result. This can be seen in the strategies of many technology giants, even those like Facebook who initially resisted this approach. In practice this is way beyond the budget of most companies so CPTs are here to stay.