Cross-platform tools (CPTs) are a class of developer tool that aim to enable a single implementation of application functionality to run across multiple platforms. If that definition seems very broad it’s because the category covers a wide range of use cases, technology approaches and forms of app deployment. In our analysis of this sector from February 2012 we identified over 100 tools across three forms of app deployment (native vs. web vs. hybrid) and five different technology approaches.
Fundamentally the various platforms are not compatible and the use of a third party tool to solve this issue comes at a cost. The effort saved through a CPT often has a financial cost but more often the largest trade-off is against a loss of flexibility, control or performance. Different tools produce different compromises. In many cases what is lost is not required to deliver the desired experience, so it’s worth understanding the different approaches and choosing the right tool for each project.
Anatomy of a cross-platform tool
A cross-platform tool may involve up to five types of component, which correspond to the five stages in the app lifecycle: develop, integrate, publish, deploy and manage.
1. Develop
Cross-platform tools offer a plethora of authoring languages, from entry-level, simplified languages like LiveCode or Lua (e.g., Corona, DragonRad, Moai and Unity), to web languages HTML, CSS and JavaScript (e.g., Appcelerator, Application Craft, Kony, Spot Specific) to mid level languages like Java and C# /.NET (e.g., Xamarin MonoTouch) to more low level languages such as C++ (e.g., Qt, MoSync, Marmalade, Aqua Platform).
Many tools offer a visual drag-and drop environment (e.g., Games Salad, Yo Yo Games Maker, LiveCode, Appcelerator, Spot Specific). Others have only a restrictive template-based app development process (e.g., iBuild App, Wix Mobile). Other tools target developers in specific segments; for example, Impact JS and Lime JS JavaScript frameworks target games developers, while RhoMobile and Worklight target enterprise developers. This gamut of CPT authoring languages caters to the entire spectrum of app developers, from scripters to seasoned web developers, and from creative designers to hardcore software developers.
The trade-off at this stage is to use a familiar or higher-level authoring environment across all platforms at the cost of flexibility in terms of direct access to the platform APIs. Being constrained by the tools vendor’s roadmap is the price for sharing code and not having to learn a new language, or hire people that know it already. In some cases tools try to provide the best of both worlds by enabling developers to create native platform extensions, maximizing shared code whilst retaining flexibility. This approach is not without drawbacks either; mixed language development adds complexity to the application, making it harder to debug and maintain.
The IDE (integrated development environment), emulator and debugger are core parts of the Develop stage. The open source IDE Eclipse is most often used as a basis, as the development environment is cross-platform itself across PC, Mac and Linux. On top of Eclipse, vendors provide additional plugins and emulators. Some vendors offer an install-free, web-based development environment specially designed for enterprise developers or designers working for a brand.
The Develop stage can also involve source control, collaboration and workflow tools. RhoMobile’s RhoHub uses Git repositories to manage source control and collaboration. Unity, Appcelerator and RunRev provide marketplaces where designers and developers can sell components and assets with the aim of helping others to speed up their development cycle with off-the-shelf components. Sencha soft-launched a similar component marketplace in November 2011, while Corona and Marmalade host a template repository and code community, respectively.
2. Integrate
This stage is about integrating with native device capabilities, cloud APIs and enterprise databases.
To integrate with native device capabilities, a popular approach is to use JavaScript alongside the PhoneGap APIs and library, all of which are bundled together in a hybrid-native application. Worklight, AppMobi, Feedhenry and BKrender include PhoneGap functionality within their tools. MoSync and Qt use a similar approach of wrapping native APIs with an abstracted set of platform-independent APIs that the developer can call irrespective of the end platform being targeted.
To integrate with native device capabilities, developers use the set of APIs defined by the tool in the tool’s coding language – for example JavaScript, Lua, LiveCode or C++. Similar functions on each target platform usually share the same tool-level API, allowing for a high level of code reuse for the business logic, although this is not always the case for UI or hardware-specific features. Apps can call the device functionality at runtime, with the call either translated at compilation, or passed through the bridge that the runtime provides to the underlying platform.
Many of the most important trade-offs occur at this stage and it will often be the key decider between tools. The more interfaces are abstracted, the greater the level of code that can be reused but the lower the level of control developers have over the final application. If the UI APIs are abstracted then there is either a smallest common set of components, or the application will not provide a native look and feel on each platform. If hardware-specific features are abstracted then developers cannot take full advantage of the hardware provided on each device. On the other hand, if the APIs are not abstracted then code in these parts of the application cannot be shared. Xamarin sits at one end of this spectrum – their Mono Touch and Mono for Android do not share common APIs for UI, multimedia or hardware-related features, simply wrapping the native platform APIs with a thin language binding. At the other end of the spectrum Corona attempts to provide the same APIs for everything across platforms.
Connecting to cloud APIs is another major part of the integration process. Cloud APIs are turning into a market segment of their own. Social gaming networks have become increasingly important to mobile developers, and this is not just Facebook or LinkedIn. The Apple Game Center, Scoreloop, Skiller, Papaya Mobile and Swarm provide cloud-based APIs for social gaming.
Social APIs are only a small part of the picture. There are over 14 vendors providing in-app billing and virtual goods platforms, including Bango, Social Gold and Paythru; more than 27 selling sales analytics tools such as App Annie, Distimo and Flurry; more than eight offering app diagnostics tools such as Bugsense and Testflight. There are, of course, signs of consolidation. Appcelerator in particular has its own analytics and monetization platform and acquired Cocoafish to integrate social sharing and push messaging features.
Application platforms targeting enterprise (B2B) developers often provide services for managing database connectivity. RhoMobile offer the RhoConnect mobile app integration server, which provides data synchronisation by pushing out updates to the device as they happen on the backend. CPT offered by Antenna, Feedhenry, and Worklight provide similar integration middleware. Other notable cross-platform tools dedicated to enterprise development are Stackmob, Oracle (ADF), Aperra and Sybase (Unwired Platform).
3. Build
The build stage is where the cross-platform “magic” occurs. There are a number of different approaches for building the application. The two most popular are: compiling the code and UI templates directly to native platform binaries; or, packaging code in a native shell and interpreting through a runtime, which could be a ‘naked browser’ packaged with the code, or even the device’s own browser rendering engine.
This stage is where the major performance trade-offs occur. If the code is interpreted then it will run slower than native code, sometimes an order of magnitude slower for the same functionality. However, advances in language runtime performance are being made all the time, particularly for JavaScript. This does not imply that compiling directly to native platform binaries is always better. If the code is compiled then it adds debugging complexity. In most cases, the binary you debug is significantly different from the binary you release, since it has to include extra mapping back to the source code. Most of the time this process works seamlessly but on the rare occasions when a bug occurs in the release version but not the debug version it can be extremely difficult to track down.
Another minor trade-off at this stage is that some vendor companies use it to safeguard their business model. In such cases, you can only build with a connection to the vendor’s servers and a valid license. For most this is only a minor inconvenience, although others will find the inability to work offline an unacceptable compromise. There is also the question of the impact to your business if your tools vendor ceases to offer the product for whatever reason. This concern is much larger than the simple case of being able to complete a build though, whether the tools work offline or not, loss of an upgrade path could be fatal to your products.
4. Publish
Publishing an app involves submitting it to the native app store (e.g., Apple App Store or Android Market) or publishing internally with the option of hosting on a private enterprise app store (e.g., with Feedhenry, Antenna, RhoMobile or Worklight). Many CPT products help to manage the App store publishing process to some degree; these include Sencha 2.0, AppMobi’s PhoneGap XDK, and RhoMobile’s RhoHub. Some vendors such as Appcelerator LiveCode and Corona will showcase apps on their websites, while Unity (with ‘Union’) also provide support for publishing to additional platforms.
There is only a minor trade-off of convenience for control in some cases here. In others the self-publishing option is still available and any assistance is just an added convenience.
5. Manage
“App management” functionality is typically offered by enterprise-targeted CPTs (e.g. Worklight, RhoMobile, Antenna, Feedhenry). It may include push messaging and data flow management, along with remote (un)installation, policy management, and inventory management. Management of commercial apps adds performance tracking (i.e., analytics tools) that may be provided by vendor partners. For example, Appcelerator deeply integrates its own analytics into Titanium, while Ansca Mobile integrates Flurry’s analytics APIs into its own Corona SDK.
Having the CPT vendor manage the application simply adds to the impact of the vendor ceasing to offer the service. It would be an unwise gamble with a small or poorly funded vendor for this type of service.
It’s all about the trade-offs
As we have demonstrated, CPTs cover a wide variety of solutions to the same basic problem. Using a CPT can produce maximum reach or device support with minimum effort. Saving more effort will usually involve making more compromises. At one extreme, some CPTs are simply libraries that help smooth out a few of the quirks between different platforms’ browsers at the cost of a dependency on third party code and possibly a little bloat in the application size. At the other extreme are app factories, where no programming knowledge is required but almost no control over the user experience and features of the resulting app is offered at all. Just about everything between those two extremes is available, although the various offerings can be categorised into five different technology approaches along this spectrum. Understanding the platforms supported by each tool and the trade-offs made in doing so is the key to deciding on the right tool for each app. Understanding how the different technology approaches produce those trade-offs is how you identify the right tool.
Looking for a list of cross-platform development tools?
[sectors slugs=’cross-platform-tools,app-factories,hybrid’]
