In our 2012 analysis of the cross-platform development tools (CPT) sector, we have identified five distinct technology approaches being used:
- JavaScript frameworks
- App factories
- Web-to-native wrappers
- Runtimes
- Source code translators
Each technology targets a slightly different developer audience – from non-developers to seasoned programmers – and addresses different application use cases. These technology approaches are not mutually exclusive; many tools use a combination of technologies. For example some runtime-based CPT solutions are adding a webview component, which enables them to create hybrid web app wrappers.
JavaScript Frameworks
JavaScript frameworks are code libraries designed to speed up complex web development tasks like managing touch-screen interactions, building cross-browser user interfaces, or managing games sprites. Example vendors are jQuery Mobile, Sencha Touch, Cocos2D, DHTMLX Touch, Zepto JS, Impact.js, iUI and Wink. JavaScript frameworks target web developers looking to achieve cross-platform browser compatibility whilst creating touch UIs, delivering native look and feel, or building complex game functionality.
App Factories
App factories are code-free, visual design tools for quickly building simple mobile applications. They consist of a development environment (installable or cloud-based) that uses template-based, drag and drop or wizard-based capabilities to generate the app code. At their simplest, app factories can be used to create RSS-based news readers or no-frills branded apps. At the next level up they provide a basic drag and drop designer. At their most advanced they provide a code-free, component-based design approach that includes device and cloud integration.
App factories allow non-developers to “create their own app”. Some app factories allow developers to view and tweak the code generated by the tool. Others include a range of post-download services including analytics, push notifications and ad management. Examples include AppMkr, AppsGeyser, Wix Mobile, Tiggr, Mobile Nation HQ, Mobjectify, Red Foundry and Spot Specific.
Web-to-Native Wrappers
Web-to-native wrappers are solutions to deliver native apps using web HTML5, CSS and JavaScript. The web code is packaged with libraries that bridge web code to native functionality – all inside a native app shell. Apps are written in web languages, and access a webView (a “chromeless” browser component) already on the device, plus JavaScript API extensions that let the app use platform capabilities beyond those normally exposed by the browser:
- notifications
- accelerometer
- compass
- connectivity
- geolocation
- filesystem.
The prime example of web-to-native wrappers is PhoneGap, as well as Uxebu’s Apparat.io and Sencha v2, which adds this wrapper functionality to the JavaScript framework. Another example is MoSync Reload, which delivers a greater set of API functionality than PhoneGap. Web-to-native wrappers target web developers who need to convert web apps to native for distribution through an app store, or access native device functionality and optimisations.
Runtimes
A runtime is an execution environment and cross-platform compatibility layer that sits atop the native operating system. A runtime essentially shields the app from differences between underlying platforms. Runtimes vary in size and complexity, and execute code on the device using several different methods – virtualization, interpretation, just-in-time compilation or ahead-of-time compilation.
Java ME, BREW, Flash Lite and Openwave MIDAS were early runtime pioneers. These heavyweight execution environments seemed half way between a browser and a full operating system. They lost popularity in the late 2000s due to their poor developer story (platform fragmentation and no direct route to market), poor handset OEM proposition (integration complexity), and competition with Android, iOS and HTML5 browsers.
Today’s cross-platform runtimes offload complexity from the device software layer to the design-time development tool. Often, part of the cross-platform translation happens at design-time (through translation into bytecode) and part at run-time (by executing that bytecode). Examples of runtimes are Appcelerator, Adobe Flex (and AIR), Corona, AppMobi, Antix and Unity. Runtimes target software developers looking for broad reach across native platforms or across screens (mobile, PCs, games consoles, TVs).
Source Code Translators
These solutions translate (cross-compile) the source code into an intermediary bytecode, native language (e.g., C++, Objective-C, JavaScript) or directly to lower level machine code (assembly language). Source code translators are often used in combination with a runtime element.
For example, Metismo (now Software AG) converts J2ME applications to C++, ActionScript and JavaScript, and compiles for ARM, MIPS, PowerPC and x86 devices. Similarly, Eqela takes an app written in a C-like language and translates the source code to match the target platform: JavaScript for web browsers, Java, C or assembly.
Haxe/NME converts the ActionScript-like “Haxe” source language – which features an API similar to Flash – to either Shockwave or C++ source code with native standard libraries. XMLVM uses Java, .NET or Ruby code compiled to byte code level which is then cross compiled to Javascript, C++ or Objective C. Other examples of tools with an element of source code translation are MoSync and Xamarin’s Mono. They target advanced software developers who need to create cross-platform apps with complex logic and high performance or optimisation requirements.
App requirements should determine tools
After support for the desired target platforms, the most common reason for developers to choose particular tools is that they are familiar with them. All other things being equal, this is an excellent selection criteria because the learning curve for a new tool or language can add significant cost to a project. However, it’s relatively rare that all other things are equal. If the users of an application expect it to have a native user experience then in general that isn’t possible with a runtime, JavaScript framework or a web-to-native wrapper (Appcelerator is an unusual exception in that it uses native UI components wrapped with JavaScript APIs – even so, the resulting user experience is not 100% native feel and performance everywhere). We also still haven’t reached the level of hardware performance and browser support to enable high-performance 3D games using web technologies. Alternatively, if reach and cost are more important than a native user experience or performance then web technologies are ideal. Selecting an inappropriate technology can appear to save on development cost but if the application fails in the market because it doesn’t meet user expectations then much more is lost than was saved.
Looking for a list of cross-platform development tools?
[sectors slugs=’cross-platform-tools,app-factories,hybrid’]
