How cross-platform tools can end the OS wars

The Android vs. iOS vs. Windows Phone platform battle has been the talk of the industry for the last year. But the market share battle between handset platforms might not be as critical for the industry as many believe.

A popular view in the industry is that the market is inevitably moving towards an Apple-Google duopoly. Apple’s app store has more than 400,000 apps. Android is growing quickly from a base of more than 250,000 apps and is predicted to catch up with Apple later this year. Nearly 80 percent of all apps in app stores are controlled by these two market giants according to Distimo. Figures for Q1 2011 from Gartner show that the market share in the smartphone market for iOS and Android combined is 53 percent and rising.

But the duopoly may be challenged by the mobile web and cross-platform tools. HTML5 empowers all other platforms to offer apps through the browser. VisionMobile’s recent Developer Economics report shows that the mobile web (of which HTML5 is a subset) is already the third most popular platform in terms of developer mindshare after Android and iOS.

At the same time, HTML5 is overhyped and the belief that HTML5 will replace almost all native apps is in need of a reality check. Native apps will still offer richer functionality, better performance, and higher security compared to HTML5-based apps. A study by quirksmode.org has shown that every mobile WebKit implementation is slightly different, which could cause a problem for HTML5-based apps. In a recent whitepaper, Netbiscuits measured smartphone support for 18 features in HTML5 and showed that leading smartphones only offer partial (or no) support for a significant number of these features. Implementation is also fragmented. What works on iPhone will probably not work on RIM or Samsung handsets and vice versa. Or to quote Forrester’s take on the HTML5 vs. native debate: “The ‘Apps vs. Internet’ Debate Will Continue…to be irrelevant.”, “it’s not a question of ‘either/or’ when it comes to a choice between apps vs. the mobile Web, but both.”

The Landscape Of Cross-Platform Development Tools

The new types of cross-platform tools are more interesting than plain HTML5 because they can deliver higher performance and functionality than browser based HTML5. These tools produce apps as output and fall roughly into two categories:

1) Web apps/hybrid apps. These apps exploit the web engine (“web browser”) and are typically written in HTML/CSS/JavaScript.

2) Native apps. These apps are compiled into machine code and often written in C++ or similar languages.

Cross-platform tools are a nascent market with a flurry of startup activity over the last few years. The following diagram illustrates different trade-offs between complexity and performance in the cross-platform tools market.

Market segments for mobile cross-platform tools

Traditional websites: In the lower left corner is the traditional website, limited in performance but providing access to all platforms with no added complexity. Plain HTML5 could be included here once all browsers support the standard.

Web apps/hybrid apps: Adjacent in the diagram are HTML5 web apps that can be downloaded to the browser’s cache and run offline. They will offer better performance and only slightly higher complexity. One step up in the diagram is a market segment of cross-platform tools running simulated native. These tools deliver better performance but the complexity is also higher if the tool has to support multiple platforms. Here we find tools that produce web apps built on HTML5/CCS3 and JavaScript, with some added native elements, typically inside a native wrapper. These cross-platform tools often add native extensions that provide access to some low level native functionality. An example of a player in this market segment is PhoneGap, which is often used in tandem with the Sencha Touch framework. Other tools that run on top of PhoneGap are WorkLight and appMobi.

A closely related market segment is hybrid tools, where the HTML5/JavaScript input is translated into actual native source code. An example of a hybrid tool vendor is Appcelerator’s Titanium.

Other types of solutions which fall under the main heading of web/hybrid apps are based on Java, Lua, ActionScript or less common languages. The diagram shows how the heavily-fragmented Java ME offers inferior performance in spite of high complexity. The cross-platform tools Corona SDK and DragonRAD are based on Lua. Rhodes is based on HTML/Ruby while OpenPlug uses ActionScript (Flash) as source language. Kony uses drag-n-drop for building enterprise web apps. There is no reliable information about the performance/complexity trade-off for most of these solutions, so their exact position in the diagram above should be viewed as illustrative. In general, tools in which the resulting code is compiled or recompiled to native ARM machine code will have a higher performance.

Native apps: The second main category is native apps. In cross-platform tools for native apps, developers often work with a codebase in C/C++ or C# which is then semi-automatically ported to the target platform and device. Performance is significantly higher with native code, but so is the complexity. Players in this sector include Airplay, Qt and MoSync. The Airplay SDK (now Marmalade) originates in 3D gaming but can also be used as a general C++ cross-platform tool. Qt is a cross-platform UI framework that also can be used for native C++ porting. Qt primarily supports Nokia’s legacy platforms. MoSync is a cross-platform tool for general purpose C++ development, integrated with the Eclipse IDE and also available under an open source (GPL) license.

Cross-Platform Beyond Java – Native Extensions

The traditional approach to cross-platform development has been a lowest common denominator one – much like that taken by Java, Flash Lite and mobile HTML. This approach sacrifices performance, UI pizzazz and access to specific device features.

A workaround is to add native extensions. These can provide additional SDK/NDK libraries for the IDE and also give access to low level hardware functionality. Access to low-level hardware functionality can be managed by a device database that controls which conditional code will be executed on a given device.

Several of the cross-platform vendors have built such device databases with various levels of detail. A device database contains information on screen size, input modality and exact OS version, extending to detailed hardware configurations and known bugs with workarounds.

Using native extensions, it is possible to overcome the inherent limitations that plagued Java. Instead of “write once, run everywhere”, developers can spend 90 percent of their time developing a common codebase and 10 percent adding native tweaks and extensions for each platform and device. For software purists, the 90/10 solution might not seem very elegant, but it is a way forward that can handle the incredible complexity with thousands of devices running more than five OS platforms. In this way, app developers can manage one codebase and port it to target devices without losing functionality. In principle, using a (C++) cross-platform engine with extensions should be able to offer similar functionality with minimal performance penalty as compared to direct development for the target device. There will be significant economies of scale when the common codebase is tweaked for 100s of devices.

The Disruptive Potential Of Cross-Platform

There are few signs that platform fragmentation will disappear. It’s not just Android, iOS and Windows Phone 7, which are backed by corporate giants with deep pockets, but also smaller players like QNX (RIM), WebOS (HP), MeeGo (Intel, China Mobile) and Bada (Samsung). Add to that legacy platforms, which will be around for at least a few years: Windows Mobile, Blackberry OS, Symbian, BREW, Java ME and Flash. If we also include the main desktop platforms (Windows, Mac OS, Ubuntu), gaming consoles, set-top boxes, cars, and other gadgets, the number of platforms becomes unmanageable.

App developers whose clients need to reach the entire market, face the formidable task of supporting all platforms and devices. If they can use a cross-platform engine the productivity gains will be dramatic compared to paying for separate in-house dev teams for each platform.

Early adopters of cross-platform will most likely be large consumer businesses who need to target the mass market such as media companies, games houses, entertainment companies, banks, and any brand developing B2C apps. Similarly, government agencies are often required to provide non-discriminatory access to their services and cross-platform tools will enable them to do just that. Another group of early adopters of cross-platform tools is CIOs of larger corporations. They face increasing demand from senior staff who want to use their favorite smartphone for secure access of internal company data. Once these early adopters have driven down the prices and sorted out stability issues we should expect to see a fast uptake of cross-platform tools in the mainstream app development market.

Assuming more developers move to cross-platform tools, the power distribution in the mobile sector will be challenged. The difference in the number of available apps between dominant and up-n-coming platforms will be reduced. This will allow smaller platforms to compete on a level playing field.

Web apps and HTML5 should make the largest dent in the market power of traditional platforms. But the final nail in the coffin will come when C++ cross-platform engines can offer almost the same performance and functionality as coding directly on the target platform. This is possible if the cross-platform engines can fully integrate native platform and device extensions. In that case, developers of native apps might reconsider Android, iOS and WP7 and choose to code to a cross-platform IDE, not to the platform. In this scenario, the cross-platform IDEs would become players of equal or even greater importance than the native platforms. At the very least, today’s OS platform wars will move to a totally different level.